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....@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
