Hello śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre <j...@nanthrax.net> napisał(a):
> Hi, > > Regarding recent comments from users and lot of refresh issues/questions > we have in the past, I moved forward with a new simple features service > that doesn’t use the resolver. It basically reads the features repo > definition and just install what’s define in there statically. > > I will prepare a distribution using it by default. > Will it be configurable? I know about refresh problems - but the resolver did a good job showing you what's wrong with the set of features/bundles you're installing. Do you plan to switch to resolverless features service in micro release of Karaf? Or will it be Karaf 4.4 / 5? regards Grzegorz Grzybek > > I will share some details soon. > > Regards > JB > > > Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre <j...@nanthrax.net> a > écrit : > > > > Hi, > > > > It doesn’t really break, it just don’t use it. > > > > It’s up to you to install all feature/bundle requirements. > > > > Regards > > JB > > > >> Le 11 janv. 2021 à 21:09, Markus Rathgeb <maggu2...@gmail.com> a écrit > : > >> > >> Hi, > >> > >>> - ignore requirement/capability (no resolver) > >> > >> did I get it right that this breaks the dependency=true feature that > >> installs bundles / features only if a requirement is not fullfilled yet? > >> > >> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault < > >> patriquelega...@gmail.com>: > >> > >>> Same here, > >>> > >>> This is behaviour that has been expected for some time now, reversing > it > >>> could cause damage to systems that upgrade to the latest Karaf. I would > >>> make it something that users opt into vs having to opt-out of. > >>> > >>> On Fri, 8 Jan 2021 at 08:42, Daniel Las <daniel....@empirica.io > .invalid> > >>> wrote: > >>> > >>>> 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 > >>>> > >>> > >>> > >>> -- > >>> *Patrique Legault* > >>> > > > >
