You mean including Karaf 4.3.x or just 4.2.x ?
> Le 8 janv. 2021 à 08:16, Daniel Las <daniel....@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 <j...@nanthrax.net
> <mailto:j...@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
> <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
