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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
