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