karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Las <daniel....@empirica.io.INVALID>
Subject Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service
Date Fri, 08 Jan 2021 08:32:47 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message