+1 for a runtime (or immutable) distribution, makes a lot of sense Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le ven. 8 janv. 2021 à 13:43, Jean-Baptiste Onofre <j...@nanthrax.net> a écrit : > 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 > >
