karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofre ...@nanthrax.net>
Subject Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service
Date Fri, 08 Jan 2021 12:43:43 GMT
Yes, yes, that’s the "updated" proposal.

autoRefresh didn’t exist before my PR, and, initially, I proposed to change it to false
on 4.3.x. But according to your valuable comment, I think it’s better to introduce the property
but keep it to true by default (as it is today).

Regards
JB

> Le 8 janv. 2021 à 09:32, Daniel Las <daniel.las@empirica.io.INVALID> a écrit
:
> 
> Hi,
> 
> Don't we have Karaf version 4.3.0 with autoRefresh=true by default and you
> propose to change autoRefresh=false by default in 4.3.x ?
> 
> Regards
> 
> pt., 8 sty 2021 o 08:38 Jean-Baptiste Onofre <jb@nanthrax.net> napisał(a):
> 
>> Hi,
>> 
>> I guess you didn’t read fully my message ;)
>> 
>> My proposal is:
>> 
>> - introduce the property and keep "true" (as it is today) on Karaf 4.2.x
>> - introduce the property and set to "false" (change) on Karaf 4.3.x.
>> 
>> Regards
>> JB
>> 
>> Le 8 janv. 2021 à 08:16, Daniel Las <daniel.las@empirica.io> a écrit :
>> 
>> Hi,
>> 
>> It looks like some kind of backward incompatible change introduced within
>> patch version change. I personally would like to keep auto refresh "on" by
>> default as this is expected/desired behavior for me.
>> 
>> Regards
>> 
>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb@nanthrax.net> napisał(a):
>> 
>>> Hi everyone,
>>> 
>>> We got several user feedback, complaining about unexpected and cascaded
>>> (unrelated) refresh while installing features.
>>> 
>>> As reminder, a refresh can happen when:
>>> - bundle A imports package foo:1 and a bundle provides newer foo package
>>> version. In that case, the features service will refresh A to use the
>>> newest package version.
>>> - bundle A has an optional import to package foo and a bundle provides
>>> this package. In that case, the features service will refresh A to actually
>>> use the import as it’s a "resolved" optional.
>>> - bundle A is wired to bundle B (from a package perspective or
>>> requirement) and B is refreshed. In that case, the features service will
>>> refresh A as B is itself refreshed (for the previous reasons for instance).
>>> This can cause "cascading" refresh.
>>> 
>>> A refresh means that a bundle can be restarted (if the bundle contains an
>>> activator or similar (DS component, blueprint bundle)).
>>> 
>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
>>> introduce a new property autoRefresh in etc/org.apache.karaf.features.cfg
>>> to disable the auto refresh by the features service (and let the user
>>> decides when he wants to trigger refresh with bundle:refresh command for
>>> instance).
>>> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on
>>> 4.3.x.
>>> 
>>> Thoughts ?
>>> 
>>> On the other hand (and to prepare the "path" to Karaf5), I have created a
>>> new "simple features service" (PR will be open soon) that:
>>> 
>>> - just take the features definition in order (ignoring start level)
>>> - ignore requirement/capability (no resolver)
>>> - no auto refresh
>>> 
>>> Basically, if you have the following feature definition:
>>> 
>>> <feature name="foo" version="1.0">
>>>  <feature>bar</feature>
>>> <bundle>A</bundle>
>>> <bundle>B</bundle>
>>> </feature>
>>> 
>>> The features service will fully install/start bar feature first, then
>>> bundle A, then bundle B.
>>> To use this "simple features services, you just have to replace
>>> org.apache.karaf.features.core by org.apache.karaf.features.simple bundle
>>> in etc/startup.properties (or custom distribution).
>>> 
>>> It’s similar to the Karaf 5 extension behavior (I will share complete
>>> details about Karaf 5 and its concepts (module, extension, …) very soon,
>>> but that’s another thread ;)).
>>> 
>>> The big advantages of this approach is:
>>> - predictable/deterministic provisioning (if it works fine, it works
>>> again)
>>> - faster deployment (I estimated the gain to about 70%)
>>> 
>>> Thoughts ?
>>> 
>>> If you agree, I will move forward on both tasks.
>>> 
>>> Thanks,
>>> Regards
>>> JB
>>> 
>> 
>> 
>> --
>> Daniel Łaś
>> CTO at Empirica S.A.
>> +48 695 616181
>> 
>> 
>> 
> 
> -- 
> Daniel Łaś
> CTO at Empirica S.A.
> +48 695 616181


Mime
View raw message