karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrique Legault <patriquelega...@gmail.com>
Subject Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service
Date Fri, 08 Jan 2021 14:01:10 GMT
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.las@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 <jb@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*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message