Re: Wrap protocol support for Java 11 jars

[Jean-Baptiste Onofre]

Hi Bob,

I will update bnd version in pax-url (I did it smoothly on Karaf) and cut the 
release to update in Karaf.

It should not be a problem, I will keep you posted.

Regards
JB

> Le 9 janv. 2021 à 04:19, Bob Paulin  a écrit :
> 
> Hi,
> 
> I recently submitted an issue relate to a camel-karaf feature that uses the 
> karaf wrap command [1].  Karaf delegates this work to the pax-url-wrap 
> library which uses a older version of bndtools (2.3.0).  Trying to think of a 
> way forward since the pax ecosystem as a whole is mostly on bndtools 2.3.0.  
> Does it make sense to wait for pax to upgrade bndtools or might it be 
> possible to move the wrap code into Karaf?  Not sure if anyone else is 
> looking at this and has other ideas.  This is going to become more of a 
> problem as more jars are complied on more recent versions of Java.  Already 
> starting to see this pop up in other places [2] [3].  I think it would be 
> good start discussing a path forward.  Thanks!
> 
> - Bob
> 
> [1] https://issues.apache.org/jira/browse/KARAF-6988
> 
> [2] https://issues.apache.org/jira/browse/CAMEL-15662
> 
> [3] 
> https://stackoverflow.com/questions/57808832/apache-karaf-startup-arrayindexoutofboundsexception-19
> 

Wrap protocol support for Java 11 jars

[Bob Paulin]

Hi,

I recently submitted an issue relate to a camel-karaf feature that uses 
the karaf wrap command [1].  Karaf delegates this work to the 
pax-url-wrap library which uses a older version of bndtools (2.3.0).  
Trying to think of a way forward since the pax ecosystem as a whole is 
mostly on bndtools 2.3.0.  Does it make sense to wait for pax to upgrade 
bndtools or might it be possible to move the wrap code into Karaf?  Not 
sure if anyone else is looking at this and has other ideas.  This is 
going to become more of a problem as more jars are complied on more 
recent versions of Java.  Already starting to see this pop up in other 
places [2] [3].  I think it would be good start discussing a path 
forward.  Thanks!


- Bob

[1] https://issues.apache.org/jira/browse/KARAF-6988

[2] https://issues.apache.org/jira/browse/CAMEL-15662

[3] 
https://stackoverflow.com/questions/57808832/apache-karaf-startup-arrayindexoutofboundsexception-19

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