Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

Same for me ;)

So, let me refactor and remove "my" feature.simple bundle to include in 
features.core.

I will create the PR soon.

Regards
JB

> Le 19 mai 2021 à 09:21, Grzegorz Grzybek  a écrit :
> 
> śr., 19 maj 2021 o 08:59 Jean-Baptiste Onofre  napisał(a):
> 
>> Yes, both are possible.
>> 
>> Maybe keeping all in org.apache.karaf.features.core with a configuration
>> to use a different deploy/approach is better than a complete new features
>> bundle.
>> It’s not a problem to me to refactor what I did.
>> 
>> Thoughts ?
>> 
> 
> Personally I'm 65% for keeping single features.core + configuration option
> and 35% for features.simple ;)
> 
> regards
> Grzegorz Grzybek
> 
> 
>> 
>> Regards
>> JB
>> 
>>> Le 19 mai 2021 à 08:01, Grzegorz Grzybek  a écrit
>> :
>>> 
>>> śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre > j...@nanthrax.net>> napisał(a):
>>> 
 Hi,
 
 Actually, it’s a complete separated bundle.
 
 So, in the Karaf standard distribution, you will have
 org.apache.karaf.features.core in etc/startup.properties: that’s the
 regular/current one with the resolver.
 
 Alternatively, you will have another distribution (I have to think about
 the name), where you will have org.apache.karaf.features.simple in
 etc/startup.properties: it doesn’t use the resolver, just loading the
 features model and executing what’s in there.
 
>>> 
>>> Another, different, "non-canonical" distribution is fine ;)
>>> 
>>> 
 
 Another possible approach is a configuration in
 etc/org.apache.karaf.features.cfg where we use a different/pluggable
 deployer.
 
>>> 
>>> This can still be done in standard, "canonical" distro, but as
>>> commented-out configuration option.
>>> 
>>> regards
>>> Grzegorz Grzybek
>>> 
>>> 
>>> 
 
 Thoughts ?
 
 Regards
 JB
 
> Le 19 mai 2021 à 07:41, Grzegorz Grzybek  a
>> écrit
 :
> 
> Hello
> 
> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre 
 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  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  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 > .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 
> 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

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Grzegorz Grzybek]

śr., 19 maj 2021 o 08:59 Jean-Baptiste Onofre  napisał(a):

> Yes, both are possible.
>
> Maybe keeping all in org.apache.karaf.features.core with a configuration
> to use a different deploy/approach is better than a complete new features
> bundle.
> It’s not a problem to me to refactor what I did.
>
> Thoughts ?
>

Personally I'm 65% for keeping single features.core + configuration option
and 35% for features.simple ;)

regards
Grzegorz Grzybek


>
> Regards
> JB
>
> > Le 19 mai 2021 à 08:01, Grzegorz Grzybek  a écrit
> :
> >
> > śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre  j...@nanthrax.net>> napisał(a):
> >
> >> Hi,
> >>
> >> Actually, it’s a complete separated bundle.
> >>
> >> So, in the Karaf standard distribution, you will have
> >> org.apache.karaf.features.core in etc/startup.properties: that’s the
> >> regular/current one with the resolver.
> >>
> >> Alternatively, you will have another distribution (I have to think about
> >> the name), where you will have org.apache.karaf.features.simple in
> >> etc/startup.properties: it doesn’t use the resolver, just loading the
> >> features model and executing what’s in there.
> >>
> >
> > Another, different, "non-canonical" distribution is fine ;)
> >
> >
> >>
> >> Another possible approach is a configuration in
> >> etc/org.apache.karaf.features.cfg where we use a different/pluggable
> >> deployer.
> >>
> >
> > This can still be done in standard, "canonical" distro, but as
> > commented-out configuration option.
> >
> > regards
> > Grzegorz Grzybek
> >
> >
> >
> >>
> >> Thoughts ?
> >>
> >> Regards
> >> JB
> >>
> >>> Le 19 mai 2021 à 07:41, Grzegorz Grzybek  a
> écrit
> >> :
> >>>
> >>> Hello
> >>>
> >>> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre 
> >> 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  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  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   .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 
> >>> 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 

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

Yes, both are possible.

Maybe keeping all in org.apache.karaf.features.core with a configuration to use 
a different deploy/approach is better than a complete new features bundle.
It’s not a problem to me to refactor what I did.

Thoughts ?

Regards
JB

> Le 19 mai 2021 à 08:01, Grzegorz Grzybek  a écrit :
> 
> śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre  > napisał(a):
> 
>> Hi,
>> 
>> Actually, it’s a complete separated bundle.
>> 
>> So, in the Karaf standard distribution, you will have
>> org.apache.karaf.features.core in etc/startup.properties: that’s the
>> regular/current one with the resolver.
>> 
>> Alternatively, you will have another distribution (I have to think about
>> the name), where you will have org.apache.karaf.features.simple in
>> etc/startup.properties: it doesn’t use the resolver, just loading the
>> features model and executing what’s in there.
>> 
> 
> Another, different, "non-canonical" distribution is fine ;)
> 
> 
>> 
>> Another possible approach is a configuration in
>> etc/org.apache.karaf.features.cfg where we use a different/pluggable
>> deployer.
>> 
> 
> This can still be done in standard, "canonical" distro, but as
> commented-out configuration option.
> 
> regards
> Grzegorz Grzybek
> 
> 
> 
>> 
>> Thoughts ?
>> 
>> Regards
>> JB
>> 
>>> Le 19 mai 2021 à 07:41, Grzegorz Grzybek  a écrit
>> :
>>> 
>>> Hello
>>> 
>>> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre 
>> 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  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  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 >>> .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 
>>> 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 

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Grzegorz Grzybek]

śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre  napisał(a):

> Hi,
>
> Actually, it’s a complete separated bundle.
>
> So, in the Karaf standard distribution, you will have
> org.apache.karaf.features.core in etc/startup.properties: that’s the
> regular/current one with the resolver.
>
> Alternatively, you will have another distribution (I have to think about
> the name), where you will have org.apache.karaf.features.simple in
> etc/startup.properties: it doesn’t use the resolver, just loading the
> features model and executing what’s in there.
>

Another, different, "non-canonical" distribution is fine ;)


>
> Another possible approach is a configuration in
> etc/org.apache.karaf.features.cfg where we use a different/pluggable
> deployer.
>

This can still be done in standard, "canonical" distro, but as
commented-out configuration option.

regards
Grzegorz Grzybek



>
> Thoughts ?
>
> Regards
> JB
>
> > Le 19 mai 2021 à 07:41, Grzegorz Grzybek  a écrit
> :
> >
> > Hello
> >
> > śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre 
> 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  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  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  >> .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 
> > 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 

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

Hi,

Actually, it’s a complete separated bundle.

So, in the Karaf standard distribution, you will have 
org.apache.karaf.features.core in etc/startup.properties: that’s the 
regular/current one with the resolver.

Alternatively, you will have another distribution (I have to think about the 
name), where you will have org.apache.karaf.features.simple in 
etc/startup.properties: it doesn’t use the resolver, just loading the features 
model and executing what’s in there.

Another possible approach is a configuration in 
etc/org.apache.karaf.features.cfg where we use a different/pluggable deployer.

Thoughts ?

Regards
JB

> Le 19 mai 2021 à 07:41, Grzegorz Grzybek  a écrit :
> 
> Hello
> 
> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre  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  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  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 > .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 
> 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:
>>> 
>>> 
>>> bar
>>> A
>>> B
>>> 
>>> 
>>> The features service will fully install/start bar feature first, then

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Grzegorz Grzybek]

Hello

śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre  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  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  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  .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 
> >>> 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:
> >
> > 
> > bar
> > A
> > B
> > 
> >
> > 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.
> >
> 

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

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.

I will share some details soon.

Regards
JB

> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre  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  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 
>>> 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 
>>> 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:
> 
> 
> bar
> A
> B
> 
> 
> 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*
>>> 
> 

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

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  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 
>> 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 
>> 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:
 
 
  bar
 A
 B
 
 
 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*
>> 

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Markus Rathgeb]

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 
> 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 
> 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:
> > >
> > > 
> > >   bar
> > >  A
> > >  B
> > > 
> > >
> > > 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*
>

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Patrique Legault]

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 
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  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:
> >
> > 
> >   bar
> >  A
> >  B
> > 
> >
> > 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*

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Daniel Las]

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  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:
>
> 
>   bar
>  A
>  B
> 
>
> 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

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Romain Manni-Bucau]

+1 for a runtime (or immutable) distribution, makes a lot of sense

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 8 janv. 2021 à 13:43, Jean-Baptiste Onofre  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  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 
> 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  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 
> 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:
> >>>
> >>> 
> >>>  bar
> >>> A
> >>> B
> >>> 
> >>>
> >>> 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
>
>

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

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  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  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  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  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:
>>> 
>>> 
>>>  bar
>>> A
>>> B
>>> 
>>> 
>>> 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

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

That’s a good idea, but instead of the config, I would create a "runtime" 
distribution with the "simple" features service (instead of the current one).

So the update proposal is:

1. Introduce autoRefresh property in etc/org.apache.karaf.features.cfg for 
Karaf 4.2.x and 4.3.x standard distribution
2. Introduce runtime distribution in Karaf 4.3.x using the "simple" features 
service (I will create a PR about that for discussion).

Good idea Romain !

Regards
JB

> Le 8 janv. 2021 à 12:02, Romain Manni-Bucau  a écrit :
> 
> Hi all,
> 
> What about creating a new karaf distro with the new configs?
> Not sure of the naming but idea is to have a "karaf-future" default setup, 
> this way you get less surprises when it becomes the default.
> For all dev driven flow it will fit more (whereas the backward compatible 
> default option fits better ops IMHO).
> Can't it enable to get the best of both worlds somehow?
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | Book 
> 
> 
> Le ven. 8 janv. 2021 à 11:18, Jean-Baptiste Onofre  > a écrit :
> Understood, and it makes sense.
> 
> So, autoRefresh property will be present on 4.2.x and 4.3.x but still "true" 
> by default.
> 
> And focus on Karaf 5 for some "conceptual" changes ;)
> 
> Regards
> JB
> 
> > Le 8 janv. 2021 à 10:57, Robert Varga mailto:n...@hq.sk>> a 
> > écrit :
> > 
> > On 08/01/2021 09:07, Grzegorz Grzybek wrote:
> >> But summarizing, I'd keep autoRefresh=true in all the scenarios, where
> >> Karaf is used as "application server" and switch it to autoRefresh=false in
> >> µservices / custom distro / single start mode. And looking forward Karaf 5
> >> and new feature mechanism, I'd rather turn autoRefresh off in Karaf 5...
> > 
> > +1.
> > 
> > I would advise against changing behavior of 4.3.x -- it is exactly these
> > sorts of changes which make even minor Karaf bumps a major uncertainty
> > -- and have historically inflicted more frustration than I care to
> > remember :(
> > 
> > Regards,
> > Robert
> > 
> 

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Daniel Las]

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  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  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  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:
>>
>> 
>>   bar
>>  A
>>  B
>> 
>>
>> 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

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Romain Manni-Bucau]

Hi all,

What about creating a new karaf distro with the new configs?
Not sure of the naming but idea is to have a "karaf-future" default setup,
this way you get less surprises when it becomes the default.
For all dev driven flow it will fit more (whereas the backward compatible
default option fits better ops IMHO).
Can't it enable to get the best of both worlds somehow?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 8 janv. 2021 à 11:18, Jean-Baptiste Onofre  a
écrit :

> Understood, and it makes sense.
>
> So, autoRefresh property will be present on 4.2.x and 4.3.x but still
> "true" by default.
>
> And focus on Karaf 5 for some "conceptual" changes ;)
>
> Regards
> JB
>
> > Le 8 janv. 2021 à 10:57, Robert Varga  a écrit :
> >
> > On 08/01/2021 09:07, Grzegorz Grzybek wrote:
> >> But summarizing, I'd keep autoRefresh=true in all the scenarios, where
> >> Karaf is used as "application server" and switch it to
> autoRefresh=false in
> >> µservices / custom distro / single start mode. And looking forward
> Karaf 5
> >> and new feature mechanism, I'd rather turn autoRefresh off in Karaf 5...
> >
> > +1.
> >
> > I would advise against changing behavior of 4.3.x -- it is exactly these
> > sorts of changes which make even minor Karaf bumps a major uncertainty
> > -- and have historically inflicted more frustration than I care to
> > remember :(
> >
> > Regards,
> > Robert
> >
>
>

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

Understood, and it makes sense.

So, autoRefresh property will be present on 4.2.x and 4.3.x but still "true" by 
default.

And focus on Karaf 5 for some "conceptual" changes ;)

Regards
JB

> Le 8 janv. 2021 à 10:57, Robert Varga  a écrit :
> 
> On 08/01/2021 09:07, Grzegorz Grzybek wrote:
>> But summarizing, I'd keep autoRefresh=true in all the scenarios, where
>> Karaf is used as "application server" and switch it to autoRefresh=false in
>> µservices / custom distro / single start mode. And looking forward Karaf 5
>> and new feature mechanism, I'd rather turn autoRefresh off in Karaf 5...
> 
> +1.
> 
> I would advise against changing behavior of 4.3.x -- it is exactly these
> sorts of changes which make even minor Karaf bumps a major uncertainty
> -- and have historically inflicted more frustration than I care to
> remember :(
> 
> Regards,
> Robert
> 

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Robert Varga]

On 08/01/2021 09:07, Grzegorz Grzybek wrote:
> But summarizing, I'd keep autoRefresh=true in all the scenarios, where
> Karaf is used as "application server" and switch it to autoRefresh=false in
> µservices / custom distro / single start mode. And looking forward Karaf 5
> and new feature mechanism, I'd rather turn autoRefresh off in Karaf 5...

+1.

I would advise against changing behavior of 4.3.x -- it is exactly these
sorts of changes which make even minor Karaf bumps a major uncertainty
-- and have historically inflicted more frustration than I care to
remember :(

Regards,
Robert



OpenPGP_signature
Description: OpenPGP digital signature

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

Yes, that’s my original  proposal as we had only one 4.3.0 release.

Regards
JB

> Le 8 janv. 2021 à 09:32, Daniel Las  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  > 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 > > 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 > > 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:
>> 
>> 
>>   bar
>>  A
>>  B
>> 
>> 
>> 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

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

Thanks Greg for your feedback

So, we can introduce autoRefresh and let enabled by default (as it is today), 
and users can change it by configuration or in their custom distribution.

We don’t change the default behavior but we give the flexibility to do so.

I’m moving forward on the "simple features service" anyway.

Regards
JB

> Le 8 janv. 2021 à 09:07, Grzegorz Grzybek  a écrit :
> 
> Hello
> 
> Thanks JBO for the proposal, which concerns very important "feature, not a
> problem" of OSGi...
> 
> To be honest I don't have clear statement about when to disable autorefresh
> (4.3 or 5.x), but let me share my view on it.
> 
> We (Red Hat Fuse team) have been struggling with "unnecessary refreshes"
> for long time in Fuse 6, which is based on Karaf 2.4, but with Karaf 4.x
> resolver and In Fuse 7 (based on Karaf 4). Fuse 6 in fabric mode is
> something more complex than pure Karaf, as it has the concept of "profiles"
> which allow to collect features + bundles (+ bunch of other stuff) in
> single entity to be assigned to a container. And a container may have many
> profiles (thus many sets of features + bundles) assigned.
> What (from user point of view) was a simple operation like:
> `container-add-profile  `, may end up with few minutes
> of Maven downloading and a cycle of bundle refreshes.
> 
> Putting Fuse 6/Fabric8 aside, Karaf feature was indeed (as JBO explained) a
> way to install many bundles in "a transaction" without a need to go through
> all existing bundles and refreshing them as needed. So my first hesitation
> is - how many `feature:install` commands (with autoRefresh = false) will
> have to be followed by explicit `osgi:refresh`?
> 
> On the other hand, when we stop treating Karaf as very-long running
> application server, how many times will we even perform `feature:install`?
> We'll rather have a custom distro, where all necessary bundles are
> installed/available from start. Here, autoRefresh=false is indeed more
> natural.
> 
> Another thing to remember is that Karaf resolver may "reach out" to bundles
> that have to be refreshed upon feature installation, if there are relevant
> "wires" between the bundles. We've seen many times that refreshing a bundle
> (we had this with ActiveMQ + Camel) doesn't necessary lead to refresh of
> all the bundles, because there was no wire between the bundles - because
> maven-bundle-plugin didn't generate one, because the ONLY link between a
> blueprint bundle with Camel context and ActiveMQ bundle was
> «from="failover:xxx"» Camel declaration, which wasn't recognized by
> maven-bundle-plugin plugins.
> 
> Over the time, I've been personally involved in "fixing unnecessary
> refreshes" bugs many times - like splitting pax-logging into
> pax-logging-api + pax-logging-service (done by +Guillaume Nodet
> mailto:gno...@apache.org>> ) or splitting 
> pax-logging-log4j2 into a bundle +
> fragment (done by JBO). In Fuse we were carefully influencing
> etc/startup.properties and rewriting many features to be more consistent
> and less vulnerable to unnecessary refreshes.
> 
> But summarizing, I'd keep autoRefresh=true in all the scenarios, where
> Karaf is used as "application server" and switch it to autoRefresh=false in
> µservices / custom distro / single start mode. And looking forward Karaf 5
> and new feature mechanism, I'd rather turn autoRefresh off in Karaf 5...
> 
> regards
> Grzegorz Grzybek
> 
> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre  > 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 <
>> 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 

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Grzegorz Grzybek]

Hello

Thanks JBO for the proposal, which concerns very important "feature, not a
problem" of OSGi...

To be honest I don't have clear statement about when to disable autorefresh
(4.3 or 5.x), but let me share my view on it.

We (Red Hat Fuse team) have been struggling with "unnecessary refreshes"
for long time in Fuse 6, which is based on Karaf 2.4, but with Karaf 4.x
resolver and In Fuse 7 (based on Karaf 4). Fuse 6 in fabric mode is
something more complex than pure Karaf, as it has the concept of "profiles"
which allow to collect features + bundles (+ bunch of other stuff) in
single entity to be assigned to a container. And a container may have many
profiles (thus many sets of features + bundles) assigned.
What (from user point of view) was a simple operation like:
`container-add-profile  `, may end up with few minutes
of Maven downloading and a cycle of bundle refreshes.

Putting Fuse 6/Fabric8 aside, Karaf feature was indeed (as JBO explained) a
way to install many bundles in "a transaction" without a need to go through
all existing bundles and refreshing them as needed. So my first hesitation
is - how many `feature:install` commands (with autoRefresh = false) will
have to be followed by explicit `osgi:refresh`?

On the other hand, when we stop treating Karaf as very-long running
application server, how many times will we even perform `feature:install`?
We'll rather have a custom distro, where all necessary bundles are
installed/available from start. Here, autoRefresh=false is indeed more
natural.

Another thing to remember is that Karaf resolver may "reach out" to bundles
that have to be refreshed upon feature installation, if there are relevant
"wires" between the bundles. We've seen many times that refreshing a bundle
(we had this with ActiveMQ + Camel) doesn't necessary lead to refresh of
all the bundles, because there was no wire between the bundles - because
maven-bundle-plugin didn't generate one, because the ONLY link between a
blueprint bundle with Camel context and ActiveMQ bundle was
«from="failover:xxx"» Camel declaration, which wasn't recognized by
maven-bundle-plugin plugins.

Over the time, I've been personally involved in "fixing unnecessary
refreshes" bugs many times - like splitting pax-logging into
pax-logging-api + pax-logging-service (done by +Guillaume Nodet
 ) or splitting pax-logging-log4j2 into a bundle +
fragment (done by JBO). In Fuse we were carefully influencing
etc/startup.properties and rewriting many features to be more consistent
and less vulnerable to unnecessary refreshes.

But summarizing, I'd keep autoRefresh=true in all the scenarios, where
Karaf is used as "application server" and switch it to autoRefresh=false in
µservices / custom distro / single start mode. And looking forward Karaf 5
and new feature mechanism, I'd rather turn autoRefresh off in Karaf 5...

regards
Grzegorz Grzybek

pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre  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 <
> 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:
>
> 
>   bar
>  A
>  B
> 
>
> 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 

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

You mean including Karaf 4.3.x or just 4.2.x ?

> Le 8 janv. 2021 à 08:16, Daniel Las  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  > 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:
> 
> 
>   bar
>  A
>  B
> 
> 
> 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

[PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

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:


  bar
 A
 B


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