You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Jean-Baptiste Onofre <jb...@nanthrax.net> on 2021/01/08 06:30:53 UTC
[PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
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:
<feature name="foo" version="1.0">
<feature>bar</feature>
<bundle>A</bundle>
<bundle>B</bundle>
</feature>
The features service will fully install/start bar feature first, then bundle A, then bundle B.
To use this "simple features services, you just have to replace org.apache.karaf.features.core by org.apache.karaf.features.simple bundle in etc/startup.properties (or custom distribution).
It’s similar to the Karaf 5 extension behavior (I will share complete details about Karaf 5 and its concepts (module, extension, …) very soon, but that’s another thread ;)).
The big advantages of this approach is:
- predictable/deterministic provisioning (if it works fine, it works again)
- faster deployment (I estimated the gain to about 70%)
Thoughts ?
If you agree, I will move forward on both tasks.
Thanks,
Regards
JB
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <gr...@gmail.com> 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 <container> <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
> <gnodet@apache.org <ma...@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 <jb@nanthrax.net <ma...@nanthrax.net>> napisał(a):
>
>> Hi everyone,
>>
>> We got several user feedback, complaining about unexpected and cascaded
>> (unrelated) refresh while installing features.
>>
>> As reminder, a refresh can happen when:
>> - bundle A imports package foo:1 and a bundle provides newer foo package
>> version. In that case, the features service will refresh A to use the
>> newest package version.
>> - bundle A has an optional import to package foo and a bundle provides
>> this package. In that case, the features service will refresh A to actually
>> use the import as it’s a "resolved" optional.
>> - bundle A is wired to bundle B (from a package perspective or
>> requirement) and B is refreshed. In that case, the features service will
>> refresh A as B is itself refreshed (for the previous reasons for instance).
>> This can cause "cascading" refresh.
>>
>> A refresh means that a bundle can be restarted (if the bundle contains an
>> activator or similar (DS component, blueprint bundle)).
>>
>> In this PR https://github.com/apache/karaf/pull/1287 <
>> 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:
>>
>> <feature name="foo" version="1.0">
>> <feature>bar</feature>
>> <bundle>A</bundle>
>> <bundle>B</bundle>
>> </feature>
>>
>> The features service will fully install/start bar feature first, then
>> bundle A, then bundle B.
>> To use this "simple features services, you just have to replace
>> org.apache.karaf.features.core by org.apache.karaf.features.simple bundle
>> in etc/startup.properties (or custom distribution).
>>
>> It’s similar to the Karaf 5 extension behavior (I will share complete
>> details about Karaf 5 and its concepts (module, extension, …) very soon,
>> but that’s another thread ;)).
>>
>> The big advantages of this approach is:
>> - predictable/deterministic provisioning (if it works fine, it works again)
>> - faster deployment (I estimated the gain to about 70%)
>>
>> Thoughts ?
>>
>> If you agree, I will move forward on both tasks.
>>
>> Thanks,
>> Regards
>> JB
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <gr...@gmail.com> 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 <container> <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
> <gnodet@apache.org <ma...@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 <jb@nanthrax.net <ma...@nanthrax.net>> napisał(a):
>
>> Hi everyone,
>>
>> We got several user feedback, complaining about unexpected and cascaded
>> (unrelated) refresh while installing features.
>>
>> As reminder, a refresh can happen when:
>> - bundle A imports package foo:1 and a bundle provides newer foo package
>> version. In that case, the features service will refresh A to use the
>> newest package version.
>> - bundle A has an optional import to package foo and a bundle provides
>> this package. In that case, the features service will refresh A to actually
>> use the import as it’s a "resolved" optional.
>> - bundle A is wired to bundle B (from a package perspective or
>> requirement) and B is refreshed. In that case, the features service will
>> refresh A as B is itself refreshed (for the previous reasons for instance).
>> This can cause "cascading" refresh.
>>
>> A refresh means that a bundle can be restarted (if the bundle contains an
>> activator or similar (DS component, blueprint bundle)).
>>
>> In this PR https://github.com/apache/karaf/pull/1287 <
>> 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:
>>
>> <feature name="foo" version="1.0">
>> <feature>bar</feature>
>> <bundle>A</bundle>
>> <bundle>B</bundle>
>> </feature>
>>
>> The features service will fully install/start bar feature first, then
>> bundle A, then bundle B.
>> To use this "simple features services, you just have to replace
>> org.apache.karaf.features.core by org.apache.karaf.features.simple bundle
>> in etc/startup.properties (or custom distribution).
>>
>> It’s similar to the Karaf 5 extension behavior (I will share complete
>> details about Karaf 5 and its concepts (module, extension, …) very soon,
>> but that’s another thread ;)).
>>
>> The big advantages of this approach is:
>> - predictable/deterministic provisioning (if it works fine, it works again)
>> - faster deployment (I estimated the gain to about 70%)
>>
>> Thoughts ?
>>
>> If you agree, I will move forward on both tasks.
>>
>> Thanks,
>> Regards
>> JB
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <rm...@gmail.com> 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 <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com/> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
> Le ven. 8 janv. 2021 à 11:18, Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> 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 <nite@hq.sk <ma...@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
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <rm...@gmail.com> 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 <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com/> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
> Le ven. 8 janv. 2021 à 11:18, Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> 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 <nite@hq.sk <ma...@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le ven. 8 janv. 2021 à 11:18, Jean-Baptiste Onofre <jb...@nanthrax.net> 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 <ni...@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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le ven. 8 janv. 2021 à 11:18, Jean-Baptiste Onofre <jb...@nanthrax.net> 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 <ni...@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
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <ni...@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
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <ni...@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
Posted by Robert Varga <ni...@hq.sk>.
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
Posted by Francois Papon <fr...@openobject.fr>.
Hi,
+1 to introduce the autorefresh property.
About the default on/off, it's pretty easy to make a custom distribution
with Karaf so users can choose depending on his usage of Karaf.
We just have to add documentation about this if we change the default
value from 4.2.x to 4.3.x.
regards,
François
fpapon@apache.org
Le 08/01/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 <container> <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
> <ma...@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 <jb@nanthrax.net
> <ma...@nanthrax.net>> napisał(a):
>
> Hi everyone,
>
> We got several user feedback, complaining about unexpected and
> cascaded (unrelated) refresh while installing features.
>
> As reminder, a refresh can happen when:
> - bundle A imports package foo:1 and a bundle provides newer foo
> package version. In that case, the features service will refresh A
> to use the newest package version.
> - bundle A has an optional import to package foo and a bundle
> provides this package. In that case, the features service will
> refresh A to actually use the import as it’s a "resolved" optional.
> - bundle A is wired to bundle B (from a package perspective or
> requirement) and B is refreshed. In that case, the features
> service will refresh A as B is itself refreshed (for the previous
> reasons for instance). This can cause "cascading" refresh.
>
> A refresh means that a bundle can be restarted (if the bundle
> contains an activator or similar (DS component, blueprint bundle)).
>
> In this PR https://github.com/apache/karaf/pull/1287
> <https://github.com/apache/karaf/pull/1287>
> <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:
>
> <feature name="foo" version="1.0">
> <feature>bar</feature>
> <bundle>A</bundle>
> <bundle>B</bundle>
> </feature>
>
> The features service will fully install/start bar feature first,
> then bundle A, then bundle B.
> To use this "simple features services, you just have to replace
> org.apache.karaf.features.core by org.apache.karaf.features.simple
> bundle in etc/startup.properties (or custom distribution).
>
> It’s similar to the Karaf 5 extension behavior (I will share
> complete details about Karaf 5 and its concepts (module,
> extension, …) very soon, but that’s another thread ;)).
>
> The big advantages of this approach is:
> - predictable/deterministic provisioning (if it works fine, it
> works again)
> - faster deployment (I estimated the gain to about 70%)
>
> Thoughts ?
>
> If you agree, I will move forward on both tasks.
>
> Thanks,
> Regards
> JB
>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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 <container> <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
<gn...@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 <jb...@nanthrax.net> napisał(a):
> Hi everyone,
>
> We got several user feedback, complaining about unexpected and cascaded
> (unrelated) refresh while installing features.
>
> As reminder, a refresh can happen when:
> - bundle A imports package foo:1 and a bundle provides newer foo package
> version. In that case, the features service will refresh A to use the
> newest package version.
> - bundle A has an optional import to package foo and a bundle provides
> this package. In that case, the features service will refresh A to actually
> use the import as it’s a "resolved" optional.
> - bundle A is wired to bundle B (from a package perspective or
> requirement) and B is refreshed. In that case, the features service will
> refresh A as B is itself refreshed (for the previous reasons for instance).
> This can cause "cascading" refresh.
>
> A refresh means that a bundle can be restarted (if the bundle contains an
> activator or similar (DS component, blueprint bundle)).
>
> In this PR https://github.com/apache/karaf/pull/1287 <
> https://github.com/apache/karaf/pull/1287>, I propose to introduce a new
> property autoRefresh in etc/org.apache.karaf.features.cfg to disable the
> auto refresh by the features service (and let the user decides when he
> wants to trigger refresh with bundle:refresh command for instance).
> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on
> 4.3.x.
>
> Thoughts ?
>
> On the other hand (and to prepare the "path" to Karaf5), I have created a
> new "simple features service" (PR will be open soon) that:
>
> - just take the features definition in order (ignoring start level)
> - ignore requirement/capability (no resolver)
> - no auto refresh
>
> Basically, if you have the following feature definition:
>
> <feature name="foo" version="1.0">
> <feature>bar</feature>
> <bundle>A</bundle>
> <bundle>B</bundle>
> </feature>
>
> The features service will fully install/start bar feature first, then
> bundle A, then bundle B.
> To use this "simple features services, you just have to replace
> org.apache.karaf.features.core by org.apache.karaf.features.simple bundle
> in etc/startup.properties (or custom distribution).
>
> It’s similar to the Karaf 5 extension behavior (I will share complete
> details about Karaf 5 and its concepts (module, extension, …) very soon,
> but that’s another thread ;)).
>
> The big advantages of this approach is:
> - predictable/deterministic provisioning (if it works fine, it works again)
> - faster deployment (I estimated the gain to about 70%)
>
> Thoughts ?
>
> If you agree, I will move forward on both tasks.
>
> Thanks,
> Regards
> JB
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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 <container> <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
<gn...@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 <jb...@nanthrax.net> napisał(a):
> Hi everyone,
>
> We got several user feedback, complaining about unexpected and cascaded
> (unrelated) refresh while installing features.
>
> As reminder, a refresh can happen when:
> - bundle A imports package foo:1 and a bundle provides newer foo package
> version. In that case, the features service will refresh A to use the
> newest package version.
> - bundle A has an optional import to package foo and a bundle provides
> this package. In that case, the features service will refresh A to actually
> use the import as it’s a "resolved" optional.
> - bundle A is wired to bundle B (from a package perspective or
> requirement) and B is refreshed. In that case, the features service will
> refresh A as B is itself refreshed (for the previous reasons for instance).
> This can cause "cascading" refresh.
>
> A refresh means that a bundle can be restarted (if the bundle contains an
> activator or similar (DS component, blueprint bundle)).
>
> In this PR https://github.com/apache/karaf/pull/1287 <
> https://github.com/apache/karaf/pull/1287>, I propose to introduce a new
> property autoRefresh in etc/org.apache.karaf.features.cfg to disable the
> auto refresh by the features service (and let the user decides when he
> wants to trigger refresh with bundle:refresh command for instance).
> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on
> 4.3.x.
>
> Thoughts ?
>
> On the other hand (and to prepare the "path" to Karaf5), I have created a
> new "simple features service" (PR will be open soon) that:
>
> - just take the features definition in order (ignoring start level)
> - ignore requirement/capability (no resolver)
> - no auto refresh
>
> Basically, if you have the following feature definition:
>
> <feature name="foo" version="1.0">
> <feature>bar</feature>
> <bundle>A</bundle>
> <bundle>B</bundle>
> </feature>
>
> The features service will fully install/start bar feature first, then
> bundle A, then bundle B.
> To use this "simple features services, you just have to replace
> org.apache.karaf.features.core by org.apache.karaf.features.simple bundle
> in etc/startup.properties (or custom distribution).
>
> It’s similar to the Karaf 5 extension behavior (I will share complete
> details about Karaf 5 and its concepts (module, extension, …) very soon,
> but that’s another thread ;)).
>
> The big advantages of this approach is:
> - predictable/deterministic provisioning (if it works fine, it works again)
> - faster deployment (I estimated the gain to about 70%)
>
> Thoughts ?
>
> If you agree, I will move forward on both tasks.
>
> Thanks,
> Regards
> JB
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1 for a runtime (or immutable) distribution, makes a lot of sense
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le ven. 8 janv. 2021 à 13:43, Jean-Baptiste Onofre <jb...@nanthrax.net> a
écrit :
> Yes, yes, that’s the "updated" proposal.
>
> autoRefresh didn’t exist before my PR, and, initially, I proposed to
> change it to false on 4.3.x. But according to your valuable comment, I
> think it’s better to introduce the property but keep it to true by default
> (as it is today).
>
> Regards
> JB
>
> > Le 8 janv. 2021 à 09:32, Daniel Las <da...@empirica.io.INVALID> a
> écrit :
> >
> > Hi,
> >
> > Don't we have Karaf version 4.3.0 with autoRefresh=true by default and
> you
> > propose to change autoRefresh=false by default in 4.3.x ?
> >
> > Regards
> >
> > pt., 8 sty 2021 o 08:38 Jean-Baptiste Onofre <jb...@nanthrax.net>
> napisał(a):
> >
> >> Hi,
> >>
> >> I guess you didn’t read fully my message ;)
> >>
> >> My proposal is:
> >>
> >> - introduce the property and keep "true" (as it is today) on Karaf 4.2.x
> >> - introduce the property and set to "false" (change) on Karaf 4.3.x.
> >>
> >> Regards
> >> JB
> >>
> >> Le 8 janv. 2021 à 08:16, Daniel Las <da...@empirica.io> a écrit :
> >>
> >> Hi,
> >>
> >> It looks like some kind of backward incompatible change introduced
> within
> >> patch version change. I personally would like to keep auto refresh "on"
> by
> >> default as this is expected/desired behavior for me.
> >>
> >> Regards
> >>
> >> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
> napisał(a):
> >>
> >>> Hi everyone,
> >>>
> >>> We got several user feedback, complaining about unexpected and cascaded
> >>> (unrelated) refresh while installing features.
> >>>
> >>> As reminder, a refresh can happen when:
> >>> - bundle A imports package foo:1 and a bundle provides newer foo
> package
> >>> version. In that case, the features service will refresh A to use the
> >>> newest package version.
> >>> - bundle A has an optional import to package foo and a bundle provides
> >>> this package. In that case, the features service will refresh A to
> actually
> >>> use the import as it’s a "resolved" optional.
> >>> - bundle A is wired to bundle B (from a package perspective or
> >>> requirement) and B is refreshed. In that case, the features service
> will
> >>> refresh A as B is itself refreshed (for the previous reasons for
> instance).
> >>> This can cause "cascading" refresh.
> >>>
> >>> A refresh means that a bundle can be restarted (if the bundle contains
> an
> >>> activator or similar (DS component, blueprint bundle)).
> >>>
> >>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
> >>> introduce a new property autoRefresh in
> etc/org.apache.karaf.features.cfg
> >>> to disable the auto refresh by the features service (and let the user
> >>> decides when he wants to trigger refresh with bundle:refresh command
> for
> >>> instance).
> >>> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false
> on
> >>> 4.3.x.
> >>>
> >>> Thoughts ?
> >>>
> >>> On the other hand (and to prepare the "path" to Karaf5), I have
> created a
> >>> new "simple features service" (PR will be open soon) that:
> >>>
> >>> - just take the features definition in order (ignoring start level)
> >>> - ignore requirement/capability (no resolver)
> >>> - no auto refresh
> >>>
> >>> Basically, if you have the following feature definition:
> >>>
> >>> <feature name="foo" version="1.0">
> >>> <feature>bar</feature>
> >>> <bundle>A</bundle>
> >>> <bundle>B</bundle>
> >>> </feature>
> >>>
> >>> The features service will fully install/start bar feature first, then
> >>> bundle A, then bundle B.
> >>> To use this "simple features services, you just have to replace
> >>> org.apache.karaf.features.core by org.apache.karaf.features.simple
> bundle
> >>> in etc/startup.properties (or custom distribution).
> >>>
> >>> It’s similar to the Karaf 5 extension behavior (I will share complete
> >>> details about Karaf 5 and its concepts (module, extension, …) very
> soon,
> >>> but that’s another thread ;)).
> >>>
> >>> The big advantages of this approach is:
> >>> - predictable/deterministic provisioning (if it works fine, it works
> >>> again)
> >>> - faster deployment (I estimated the gain to about 70%)
> >>>
> >>> Thoughts ?
> >>>
> >>> If you agree, I will move forward on both tasks.
> >>>
> >>> Thanks,
> >>> Regards
> >>> JB
> >>>
> >>
> >>
> >> --
> >> Daniel Łaś
> >> CTO at Empirica S.A.
> >> +48 695 616181
> >>
> >>
> >>
> >
> > --
> > Daniel Łaś
> > CTO at Empirica S.A.
> > +48 695 616181
>
>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1 for a runtime (or immutable) distribution, makes a lot of sense
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le ven. 8 janv. 2021 à 13:43, Jean-Baptiste Onofre <jb...@nanthrax.net> a
écrit :
> Yes, yes, that’s the "updated" proposal.
>
> autoRefresh didn’t exist before my PR, and, initially, I proposed to
> change it to false on 4.3.x. But according to your valuable comment, I
> think it’s better to introduce the property but keep it to true by default
> (as it is today).
>
> Regards
> JB
>
> > Le 8 janv. 2021 à 09:32, Daniel Las <da...@empirica.io.INVALID> a
> écrit :
> >
> > Hi,
> >
> > Don't we have Karaf version 4.3.0 with autoRefresh=true by default and
> you
> > propose to change autoRefresh=false by default in 4.3.x ?
> >
> > Regards
> >
> > pt., 8 sty 2021 o 08:38 Jean-Baptiste Onofre <jb...@nanthrax.net>
> napisał(a):
> >
> >> Hi,
> >>
> >> I guess you didn’t read fully my message ;)
> >>
> >> My proposal is:
> >>
> >> - introduce the property and keep "true" (as it is today) on Karaf 4.2.x
> >> - introduce the property and set to "false" (change) on Karaf 4.3.x.
> >>
> >> Regards
> >> JB
> >>
> >> Le 8 janv. 2021 à 08:16, Daniel Las <da...@empirica.io> a écrit :
> >>
> >> Hi,
> >>
> >> It looks like some kind of backward incompatible change introduced
> within
> >> patch version change. I personally would like to keep auto refresh "on"
> by
> >> default as this is expected/desired behavior for me.
> >>
> >> Regards
> >>
> >> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
> napisał(a):
> >>
> >>> Hi everyone,
> >>>
> >>> We got several user feedback, complaining about unexpected and cascaded
> >>> (unrelated) refresh while installing features.
> >>>
> >>> As reminder, a refresh can happen when:
> >>> - bundle A imports package foo:1 and a bundle provides newer foo
> package
> >>> version. In that case, the features service will refresh A to use the
> >>> newest package version.
> >>> - bundle A has an optional import to package foo and a bundle provides
> >>> this package. In that case, the features service will refresh A to
> actually
> >>> use the import as it’s a "resolved" optional.
> >>> - bundle A is wired to bundle B (from a package perspective or
> >>> requirement) and B is refreshed. In that case, the features service
> will
> >>> refresh A as B is itself refreshed (for the previous reasons for
> instance).
> >>> This can cause "cascading" refresh.
> >>>
> >>> A refresh means that a bundle can be restarted (if the bundle contains
> an
> >>> activator or similar (DS component, blueprint bundle)).
> >>>
> >>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
> >>> introduce a new property autoRefresh in
> etc/org.apache.karaf.features.cfg
> >>> to disable the auto refresh by the features service (and let the user
> >>> decides when he wants to trigger refresh with bundle:refresh command
> for
> >>> instance).
> >>> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false
> on
> >>> 4.3.x.
> >>>
> >>> Thoughts ?
> >>>
> >>> On the other hand (and to prepare the "path" to Karaf5), I have
> created a
> >>> new "simple features service" (PR will be open soon) that:
> >>>
> >>> - just take the features definition in order (ignoring start level)
> >>> - ignore requirement/capability (no resolver)
> >>> - no auto refresh
> >>>
> >>> Basically, if you have the following feature definition:
> >>>
> >>> <feature name="foo" version="1.0">
> >>> <feature>bar</feature>
> >>> <bundle>A</bundle>
> >>> <bundle>B</bundle>
> >>> </feature>
> >>>
> >>> The features service will fully install/start bar feature first, then
> >>> bundle A, then bundle B.
> >>> To use this "simple features services, you just have to replace
> >>> org.apache.karaf.features.core by org.apache.karaf.features.simple
> bundle
> >>> in etc/startup.properties (or custom distribution).
> >>>
> >>> It’s similar to the Karaf 5 extension behavior (I will share complete
> >>> details about Karaf 5 and its concepts (module, extension, …) very
> soon,
> >>> but that’s another thread ;)).
> >>>
> >>> The big advantages of this approach is:
> >>> - predictable/deterministic provisioning (if it works fine, it works
> >>> again)
> >>> - faster deployment (I estimated the gain to about 70%)
> >>>
> >>> Thoughts ?
> >>>
> >>> If you agree, I will move forward on both tasks.
> >>>
> >>> Thanks,
> >>> Regards
> >>> JB
> >>>
> >>
> >>
> >> --
> >> Daniel Łaś
> >> CTO at Empirica S.A.
> >> +48 695 616181
> >>
> >>
> >>
> >
> > --
> > Daniel Łaś
> > CTO at Empirica S.A.
> > +48 695 616181
>
>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <da...@empirica.io.INVALID> a écrit :
>
> Hi,
>
> Don't we have Karaf version 4.3.0 with autoRefresh=true by default and you
> propose to change autoRefresh=false by default in 4.3.x ?
>
> Regards
>
> pt., 8 sty 2021 o 08:38 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>
>> Hi,
>>
>> I guess you didn’t read fully my message ;)
>>
>> My proposal is:
>>
>> - introduce the property and keep "true" (as it is today) on Karaf 4.2.x
>> - introduce the property and set to "false" (change) on Karaf 4.3.x.
>>
>> Regards
>> JB
>>
>> Le 8 janv. 2021 à 08:16, Daniel Las <da...@empirica.io> a écrit :
>>
>> Hi,
>>
>> It looks like some kind of backward incompatible change introduced within
>> patch version change. I personally would like to keep auto refresh "on" by
>> default as this is expected/desired behavior for me.
>>
>> Regards
>>
>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>>
>>> Hi everyone,
>>>
>>> We got several user feedback, complaining about unexpected and cascaded
>>> (unrelated) refresh while installing features.
>>>
>>> As reminder, a refresh can happen when:
>>> - bundle A imports package foo:1 and a bundle provides newer foo package
>>> version. In that case, the features service will refresh A to use the
>>> newest package version.
>>> - bundle A has an optional import to package foo and a bundle provides
>>> this package. In that case, the features service will refresh A to actually
>>> use the import as it’s a "resolved" optional.
>>> - bundle A is wired to bundle B (from a package perspective or
>>> requirement) and B is refreshed. In that case, the features service will
>>> refresh A as B is itself refreshed (for the previous reasons for instance).
>>> This can cause "cascading" refresh.
>>>
>>> A refresh means that a bundle can be restarted (if the bundle contains an
>>> activator or similar (DS component, blueprint bundle)).
>>>
>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
>>> introduce a new property autoRefresh in etc/org.apache.karaf.features.cfg
>>> to disable the auto refresh by the features service (and let the user
>>> decides when he wants to trigger refresh with bundle:refresh command for
>>> instance).
>>> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on
>>> 4.3.x.
>>>
>>> Thoughts ?
>>>
>>> On the other hand (and to prepare the "path" to Karaf5), I have created a
>>> new "simple features service" (PR will be open soon) that:
>>>
>>> - just take the features definition in order (ignoring start level)
>>> - ignore requirement/capability (no resolver)
>>> - no auto refresh
>>>
>>> Basically, if you have the following feature definition:
>>>
>>> <feature name="foo" version="1.0">
>>> <feature>bar</feature>
>>> <bundle>A</bundle>
>>> <bundle>B</bundle>
>>> </feature>
>>>
>>> The features service will fully install/start bar feature first, then
>>> bundle A, then bundle B.
>>> To use this "simple features services, you just have to replace
>>> org.apache.karaf.features.core by org.apache.karaf.features.simple bundle
>>> in etc/startup.properties (or custom distribution).
>>>
>>> It’s similar to the Karaf 5 extension behavior (I will share complete
>>> details about Karaf 5 and its concepts (module, extension, …) very soon,
>>> but that’s another thread ;)).
>>>
>>> The big advantages of this approach is:
>>> - predictable/deterministic provisioning (if it works fine, it works
>>> again)
>>> - faster deployment (I estimated the gain to about 70%)
>>>
>>> Thoughts ?
>>>
>>> If you agree, I will move forward on both tasks.
>>>
>>> Thanks,
>>> Regards
>>> JB
>>>
>>
>>
>> --
>> Daniel Łaś
>> CTO at Empirica S.A.
>> +48 695 616181
>>
>>
>>
>
> --
> Daniel Łaś
> CTO at Empirica S.A.
> +48 695 616181
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <da...@empirica.io> 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 <jb@nanthrax.net <ma...@nanthrax.net>> napisał(a):
> Hi,
>
> I guess you didn’t read fully my message ;)
>
> My proposal is:
>
> - introduce the property and keep "true" (as it is today) on Karaf 4.2.x
> - introduce the property and set to "false" (change) on Karaf 4.3.x.
>
> Regards
> JB
>
>> Le 8 janv. 2021 à 08:16, Daniel Las <daniel.las@empirica.io <ma...@empirica.io>> a écrit :
>>
>> Hi,
>>
>> It looks like some kind of backward incompatible change introduced within patch version change. I personally would like to keep auto refresh "on" by default as this is expected/desired behavior for me.
>>
>> Regards
>>
>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> napisał(a):
>> Hi everyone,
>>
>> We got several user feedback, complaining about unexpected and cascaded (unrelated) refresh while installing features.
>>
>> As reminder, a refresh can happen when:
>> - bundle A imports package foo:1 and a bundle provides newer foo package version. In that case, the features service will refresh A to use the newest package version.
>> - bundle A has an optional import to package foo and a bundle provides this package. In that case, the features service will refresh A to actually use the import as it’s a "resolved" optional.
>> - bundle A is wired to bundle B (from a package perspective or requirement) and B is refreshed. In that case, the features service will refresh A as B is itself refreshed (for the previous reasons for instance). This can cause "cascading" refresh.
>>
>> A refresh means that a bundle can be restarted (if the bundle contains an activator or similar (DS component, blueprint bundle)).
>>
>> In this PR https://github.com/apache/karaf/pull/1287 <https://github.com/apache/karaf/pull/1287>, I propose to introduce a new property autoRefresh in etc/org.apache.karaf.features.cfg to disable the auto refresh by the features service (and let the user decides when he wants to trigger refresh with bundle:refresh command for instance).
>> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on 4.3.x.
>>
>> Thoughts ?
>>
>> On the other hand (and to prepare the "path" to Karaf5), I have created a new "simple features service" (PR will be open soon) that:
>>
>> - just take the features definition in order (ignoring start level)
>> - ignore requirement/capability (no resolver)
>> - no auto refresh
>>
>> Basically, if you have the following feature definition:
>>
>> <feature name="foo" version="1.0">
>> <feature>bar</feature>
>> <bundle>A</bundle>
>> <bundle>B</bundle>
>> </feature>
>>
>> The features service will fully install/start bar feature first, then bundle A, then bundle B.
>> To use this "simple features services, you just have to replace org.apache.karaf.features.core by org.apache.karaf.features.simple bundle in etc/startup.properties (or custom distribution).
>>
>> It’s similar to the Karaf 5 extension behavior (I will share complete details about Karaf 5 and its concepts (module, extension, …) very soon, but that’s another thread ;)).
>>
>> The big advantages of this approach is:
>> - predictable/deterministic provisioning (if it works fine, it works again)
>> - faster deployment (I estimated the gain to about 70%)
>>
>> Thoughts ?
>>
>> If you agree, I will move forward on both tasks.
>>
>> Thanks,
>> Regards
>> JB
>>
>>
>> --
>> Daniel Łaś
>> CTO at Empirica S.A.
>> +48 695 616181
>
>
>
> --
> Daniel Łaś
> CTO at Empirica S.A.
> +48 695 616181
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <da...@empirica.io> 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 <jb@nanthrax.net <ma...@nanthrax.net>> napisał(a):
> Hi,
>
> I guess you didn’t read fully my message ;)
>
> My proposal is:
>
> - introduce the property and keep "true" (as it is today) on Karaf 4.2.x
> - introduce the property and set to "false" (change) on Karaf 4.3.x.
>
> Regards
> JB
>
>> Le 8 janv. 2021 à 08:16, Daniel Las <daniel.las@empirica.io <ma...@empirica.io>> a écrit :
>>
>> Hi,
>>
>> It looks like some kind of backward incompatible change introduced within patch version change. I personally would like to keep auto refresh "on" by default as this is expected/desired behavior for me.
>>
>> Regards
>>
>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> napisał(a):
>> Hi everyone,
>>
>> We got several user feedback, complaining about unexpected and cascaded (unrelated) refresh while installing features.
>>
>> As reminder, a refresh can happen when:
>> - bundle A imports package foo:1 and a bundle provides newer foo package version. In that case, the features service will refresh A to use the newest package version.
>> - bundle A has an optional import to package foo and a bundle provides this package. In that case, the features service will refresh A to actually use the import as it’s a "resolved" optional.
>> - bundle A is wired to bundle B (from a package perspective or requirement) and B is refreshed. In that case, the features service will refresh A as B is itself refreshed (for the previous reasons for instance). This can cause "cascading" refresh.
>>
>> A refresh means that a bundle can be restarted (if the bundle contains an activator or similar (DS component, blueprint bundle)).
>>
>> In this PR https://github.com/apache/karaf/pull/1287 <https://github.com/apache/karaf/pull/1287>, I propose to introduce a new property autoRefresh in etc/org.apache.karaf.features.cfg to disable the auto refresh by the features service (and let the user decides when he wants to trigger refresh with bundle:refresh command for instance).
>> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on 4.3.x.
>>
>> Thoughts ?
>>
>> On the other hand (and to prepare the "path" to Karaf5), I have created a new "simple features service" (PR will be open soon) that:
>>
>> - just take the features definition in order (ignoring start level)
>> - ignore requirement/capability (no resolver)
>> - no auto refresh
>>
>> Basically, if you have the following feature definition:
>>
>> <feature name="foo" version="1.0">
>> <feature>bar</feature>
>> <bundle>A</bundle>
>> <bundle>B</bundle>
>> </feature>
>>
>> The features service will fully install/start bar feature first, then bundle A, then bundle B.
>> To use this "simple features services, you just have to replace org.apache.karaf.features.core by org.apache.karaf.features.simple bundle in etc/startup.properties (or custom distribution).
>>
>> It’s similar to the Karaf 5 extension behavior (I will share complete details about Karaf 5 and its concepts (module, extension, …) very soon, but that’s another thread ;)).
>>
>> The big advantages of this approach is:
>> - predictable/deterministic provisioning (if it works fine, it works again)
>> - faster deployment (I estimated the gain to about 70%)
>>
>> Thoughts ?
>>
>> If you agree, I will move forward on both tasks.
>>
>> Thanks,
>> Regards
>> JB
>>
>>
>> --
>> Daniel Łaś
>> CTO at Empirica S.A.
>> +48 695 616181
>
>
>
> --
> Daniel Łaś
> CTO at Empirica S.A.
> +48 695 616181
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <da...@empirica.io.INVALID> a écrit :
>
> Hi,
>
> Don't we have Karaf version 4.3.0 with autoRefresh=true by default and you
> propose to change autoRefresh=false by default in 4.3.x ?
>
> Regards
>
> pt., 8 sty 2021 o 08:38 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>
>> Hi,
>>
>> I guess you didn’t read fully my message ;)
>>
>> My proposal is:
>>
>> - introduce the property and keep "true" (as it is today) on Karaf 4.2.x
>> - introduce the property and set to "false" (change) on Karaf 4.3.x.
>>
>> Regards
>> JB
>>
>> Le 8 janv. 2021 à 08:16, Daniel Las <da...@empirica.io> a écrit :
>>
>> Hi,
>>
>> It looks like some kind of backward incompatible change introduced within
>> patch version change. I personally would like to keep auto refresh "on" by
>> default as this is expected/desired behavior for me.
>>
>> Regards
>>
>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>>
>>> Hi everyone,
>>>
>>> We got several user feedback, complaining about unexpected and cascaded
>>> (unrelated) refresh while installing features.
>>>
>>> As reminder, a refresh can happen when:
>>> - bundle A imports package foo:1 and a bundle provides newer foo package
>>> version. In that case, the features service will refresh A to use the
>>> newest package version.
>>> - bundle A has an optional import to package foo and a bundle provides
>>> this package. In that case, the features service will refresh A to actually
>>> use the import as it’s a "resolved" optional.
>>> - bundle A is wired to bundle B (from a package perspective or
>>> requirement) and B is refreshed. In that case, the features service will
>>> refresh A as B is itself refreshed (for the previous reasons for instance).
>>> This can cause "cascading" refresh.
>>>
>>> A refresh means that a bundle can be restarted (if the bundle contains an
>>> activator or similar (DS component, blueprint bundle)).
>>>
>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
>>> introduce a new property autoRefresh in etc/org.apache.karaf.features.cfg
>>> to disable the auto refresh by the features service (and let the user
>>> decides when he wants to trigger refresh with bundle:refresh command for
>>> instance).
>>> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on
>>> 4.3.x.
>>>
>>> Thoughts ?
>>>
>>> On the other hand (and to prepare the "path" to Karaf5), I have created a
>>> new "simple features service" (PR will be open soon) that:
>>>
>>> - just take the features definition in order (ignoring start level)
>>> - ignore requirement/capability (no resolver)
>>> - no auto refresh
>>>
>>> Basically, if you have the following feature definition:
>>>
>>> <feature name="foo" version="1.0">
>>> <feature>bar</feature>
>>> <bundle>A</bundle>
>>> <bundle>B</bundle>
>>> </feature>
>>>
>>> The features service will fully install/start bar feature first, then
>>> bundle A, then bundle B.
>>> To use this "simple features services, you just have to replace
>>> org.apache.karaf.features.core by org.apache.karaf.features.simple bundle
>>> in etc/startup.properties (or custom distribution).
>>>
>>> It’s similar to the Karaf 5 extension behavior (I will share complete
>>> details about Karaf 5 and its concepts (module, extension, …) very soon,
>>> but that’s another thread ;)).
>>>
>>> The big advantages of this approach is:
>>> - predictable/deterministic provisioning (if it works fine, it works
>>> again)
>>> - faster deployment (I estimated the gain to about 70%)
>>>
>>> Thoughts ?
>>>
>>> If you agree, I will move forward on both tasks.
>>>
>>> Thanks,
>>> Regards
>>> JB
>>>
>>
>>
>> --
>> Daniel Łaś
>> CTO at Empirica S.A.
>> +48 695 616181
>>
>>
>>
>
> --
> Daniel Łaś
> CTO at Empirica S.A.
> +48 695 616181
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Daniel Las <da...@empirica.io.INVALID>.
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 <jb...@nanthrax.net> napisał(a):
> Hi,
>
> I guess you didn’t read fully my message ;)
>
> My proposal is:
>
> - introduce the property and keep "true" (as it is today) on Karaf 4.2.x
> - introduce the property and set to "false" (change) on Karaf 4.3.x.
>
> Regards
> JB
>
> Le 8 janv. 2021 à 08:16, Daniel Las <da...@empirica.io> a écrit :
>
> Hi,
>
> It looks like some kind of backward incompatible change introduced within
> patch version change. I personally would like to keep auto refresh "on" by
> default as this is expected/desired behavior for me.
>
> Regards
>
> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>
>> Hi everyone,
>>
>> We got several user feedback, complaining about unexpected and cascaded
>> (unrelated) refresh while installing features.
>>
>> As reminder, a refresh can happen when:
>> - bundle A imports package foo:1 and a bundle provides newer foo package
>> version. In that case, the features service will refresh A to use the
>> newest package version.
>> - bundle A has an optional import to package foo and a bundle provides
>> this package. In that case, the features service will refresh A to actually
>> use the import as it’s a "resolved" optional.
>> - bundle A is wired to bundle B (from a package perspective or
>> requirement) and B is refreshed. In that case, the features service will
>> refresh A as B is itself refreshed (for the previous reasons for instance).
>> This can cause "cascading" refresh.
>>
>> A refresh means that a bundle can be restarted (if the bundle contains an
>> activator or similar (DS component, blueprint bundle)).
>>
>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
>> introduce a new property autoRefresh in etc/org.apache.karaf.features.cfg
>> to disable the auto refresh by the features service (and let the user
>> decides when he wants to trigger refresh with bundle:refresh command for
>> instance).
>> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on
>> 4.3.x.
>>
>> Thoughts ?
>>
>> On the other hand (and to prepare the "path" to Karaf5), I have created a
>> new "simple features service" (PR will be open soon) that:
>>
>> - just take the features definition in order (ignoring start level)
>> - ignore requirement/capability (no resolver)
>> - no auto refresh
>>
>> Basically, if you have the following feature definition:
>>
>> <feature name="foo" version="1.0">
>> <feature>bar</feature>
>> <bundle>A</bundle>
>> <bundle>B</bundle>
>> </feature>
>>
>> The features service will fully install/start bar feature first, then
>> bundle A, then bundle B.
>> To use this "simple features services, you just have to replace
>> org.apache.karaf.features.core by org.apache.karaf.features.simple bundle
>> in etc/startup.properties (or custom distribution).
>>
>> It’s similar to the Karaf 5 extension behavior (I will share complete
>> details about Karaf 5 and its concepts (module, extension, …) very soon,
>> but that’s another thread ;)).
>>
>> The big advantages of this approach is:
>> - predictable/deterministic provisioning (if it works fine, it works
>> again)
>> - faster deployment (I estimated the gain to about 70%)
>>
>> Thoughts ?
>>
>> If you agree, I will move forward on both tasks.
>>
>> Thanks,
>> Regards
>> JB
>>
>
>
> --
> Daniel Łaś
> CTO at Empirica S.A.
> +48 695 616181
>
>
>
--
Daniel Łaś
CTO at Empirica S.A.
+48 695 616181
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Daniel Las <da...@empirica.io>.
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 <jb...@nanthrax.net> napisał(a):
> Hi,
>
> I guess you didn’t read fully my message ;)
>
> My proposal is:
>
> - introduce the property and keep "true" (as it is today) on Karaf 4.2.x
> - introduce the property and set to "false" (change) on Karaf 4.3.x.
>
> Regards
> JB
>
> Le 8 janv. 2021 à 08:16, Daniel Las <da...@empirica.io> a écrit :
>
> Hi,
>
> It looks like some kind of backward incompatible change introduced within
> patch version change. I personally would like to keep auto refresh "on" by
> default as this is expected/desired behavior for me.
>
> Regards
>
> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>
>> Hi everyone,
>>
>> We got several user feedback, complaining about unexpected and cascaded
>> (unrelated) refresh while installing features.
>>
>> As reminder, a refresh can happen when:
>> - bundle A imports package foo:1 and a bundle provides newer foo package
>> version. In that case, the features service will refresh A to use the
>> newest package version.
>> - bundle A has an optional import to package foo and a bundle provides
>> this package. In that case, the features service will refresh A to actually
>> use the import as it’s a "resolved" optional.
>> - bundle A is wired to bundle B (from a package perspective or
>> requirement) and B is refreshed. In that case, the features service will
>> refresh A as B is itself refreshed (for the previous reasons for instance).
>> This can cause "cascading" refresh.
>>
>> A refresh means that a bundle can be restarted (if the bundle contains an
>> activator or similar (DS component, blueprint bundle)).
>>
>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
>> introduce a new property autoRefresh in etc/org.apache.karaf.features.cfg
>> to disable the auto refresh by the features service (and let the user
>> decides when he wants to trigger refresh with bundle:refresh command for
>> instance).
>> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on
>> 4.3.x.
>>
>> Thoughts ?
>>
>> On the other hand (and to prepare the "path" to Karaf5), I have created a
>> new "simple features service" (PR will be open soon) that:
>>
>> - just take the features definition in order (ignoring start level)
>> - ignore requirement/capability (no resolver)
>> - no auto refresh
>>
>> Basically, if you have the following feature definition:
>>
>> <feature name="foo" version="1.0">
>> <feature>bar</feature>
>> <bundle>A</bundle>
>> <bundle>B</bundle>
>> </feature>
>>
>> The features service will fully install/start bar feature first, then
>> bundle A, then bundle B.
>> To use this "simple features services, you just have to replace
>> org.apache.karaf.features.core by org.apache.karaf.features.simple bundle
>> in etc/startup.properties (or custom distribution).
>>
>> It’s similar to the Karaf 5 extension behavior (I will share complete
>> details about Karaf 5 and its concepts (module, extension, …) very soon,
>> but that’s another thread ;)).
>>
>> The big advantages of this approach is:
>> - predictable/deterministic provisioning (if it works fine, it works
>> again)
>> - faster deployment (I estimated the gain to about 70%)
>>
>> Thoughts ?
>>
>> If you agree, I will move forward on both tasks.
>>
>> Thanks,
>> Regards
>> JB
>>
>
>
> --
> Daniel Łaś
> CTO at Empirica S.A.
> +48 695 616181
>
>
>
--
Daniel Łaś
CTO at Empirica S.A.
+48 695 616181
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <da...@empirica.io> a écrit :
>
> Hi,
>
> It looks like some kind of backward incompatible change introduced within patch version change. I personally would like to keep auto refresh "on" by default as this is expected/desired behavior for me.
>
> Regards
>
> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> napisał(a):
> Hi everyone,
>
> We got several user feedback, complaining about unexpected and cascaded (unrelated) refresh while installing features.
>
> As reminder, a refresh can happen when:
> - bundle A imports package foo:1 and a bundle provides newer foo package version. In that case, the features service will refresh A to use the newest package version.
> - bundle A has an optional import to package foo and a bundle provides this package. In that case, the features service will refresh A to actually use the import as it’s a "resolved" optional.
> - bundle A is wired to bundle B (from a package perspective or requirement) and B is refreshed. In that case, the features service will refresh A as B is itself refreshed (for the previous reasons for instance). This can cause "cascading" refresh.
>
> A refresh means that a bundle can be restarted (if the bundle contains an activator or similar (DS component, blueprint bundle)).
>
> In this PR https://github.com/apache/karaf/pull/1287 <https://github.com/apache/karaf/pull/1287>, I propose to introduce a new property autoRefresh in etc/org.apache.karaf.features.cfg to disable the auto refresh by the features service (and let the user decides when he wants to trigger refresh with bundle:refresh command for instance).
> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on 4.3.x.
>
> Thoughts ?
>
> On the other hand (and to prepare the "path" to Karaf5), I have created a new "simple features service" (PR will be open soon) that:
>
> - just take the features definition in order (ignoring start level)
> - ignore requirement/capability (no resolver)
> - no auto refresh
>
> Basically, if you have the following feature definition:
>
> <feature name="foo" version="1.0">
> <feature>bar</feature>
> <bundle>A</bundle>
> <bundle>B</bundle>
> </feature>
>
> The features service will fully install/start bar feature first, then bundle A, then bundle B.
> To use this "simple features services, you just have to replace org.apache.karaf.features.core by org.apache.karaf.features.simple bundle in etc/startup.properties (or custom distribution).
>
> It’s similar to the Karaf 5 extension behavior (I will share complete details about Karaf 5 and its concepts (module, extension, …) very soon, but that’s another thread ;)).
>
> The big advantages of this approach is:
> - predictable/deterministic provisioning (if it works fine, it works again)
> - faster deployment (I estimated the gain to about 70%)
>
> Thoughts ?
>
> If you agree, I will move forward on both tasks.
>
> Thanks,
> Regards
> JB
>
>
> --
> Daniel Łaś
> CTO at Empirica S.A.
> +48 695 616181
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
You mean including Karaf 4.3.x or just 4.2.x ?
> Le 8 janv. 2021 à 08:16, Daniel Las <da...@empirica.io> a écrit :
>
> Hi,
>
> It looks like some kind of backward incompatible change introduced within patch version change. I personally would like to keep auto refresh "on" by default as this is expected/desired behavior for me.
>
> Regards
>
> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> napisał(a):
> Hi everyone,
>
> We got several user feedback, complaining about unexpected and cascaded (unrelated) refresh while installing features.
>
> As reminder, a refresh can happen when:
> - bundle A imports package foo:1 and a bundle provides newer foo package version. In that case, the features service will refresh A to use the newest package version.
> - bundle A has an optional import to package foo and a bundle provides this package. In that case, the features service will refresh A to actually use the import as it’s a "resolved" optional.
> - bundle A is wired to bundle B (from a package perspective or requirement) and B is refreshed. In that case, the features service will refresh A as B is itself refreshed (for the previous reasons for instance). This can cause "cascading" refresh.
>
> A refresh means that a bundle can be restarted (if the bundle contains an activator or similar (DS component, blueprint bundle)).
>
> In this PR https://github.com/apache/karaf/pull/1287 <https://github.com/apache/karaf/pull/1287>, I propose to introduce a new property autoRefresh in etc/org.apache.karaf.features.cfg to disable the auto refresh by the features service (and let the user decides when he wants to trigger refresh with bundle:refresh command for instance).
> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on 4.3.x.
>
> Thoughts ?
>
> On the other hand (and to prepare the "path" to Karaf5), I have created a new "simple features service" (PR will be open soon) that:
>
> - just take the features definition in order (ignoring start level)
> - ignore requirement/capability (no resolver)
> - no auto refresh
>
> Basically, if you have the following feature definition:
>
> <feature name="foo" version="1.0">
> <feature>bar</feature>
> <bundle>A</bundle>
> <bundle>B</bundle>
> </feature>
>
> The features service will fully install/start bar feature first, then bundle A, then bundle B.
> To use this "simple features services, you just have to replace org.apache.karaf.features.core by org.apache.karaf.features.simple bundle in etc/startup.properties (or custom distribution).
>
> It’s similar to the Karaf 5 extension behavior (I will share complete details about Karaf 5 and its concepts (module, extension, …) very soon, but that’s another thread ;)).
>
> The big advantages of this approach is:
> - predictable/deterministic provisioning (if it works fine, it works again)
> - faster deployment (I estimated the gain to about 70%)
>
> Thoughts ?
>
> If you agree, I will move forward on both tasks.
>
> Thanks,
> Regards
> JB
>
>
> --
> Daniel Łaś
> CTO at Empirica S.A.
> +48 695 616181
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <gr...@gmail.com> a écrit :
>
> śr., 19 maj 2021 o 08:59 Jean-Baptiste Onofre <jb...@nanthrax.net> 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 <gr...@gmail.com> a écrit
>> :
>>>
>>> śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre <jb@nanthrax.net <mailto:
>> jb@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 <gr...@gmail.com> a
>> écrit
>>>> :
>>>>>
>>>>> Hello
>>>>>
>>>>> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>> napisał(a):
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Regarding recent comments from users and lot of refresh
>> issues/questions
>>>>>> we have in the past, I moved forward with a new simple features
>> service
>>>>>> that doesn’t use the resolver. It basically reads the features repo
>>>>>> definition and just install what’s define in there statically.
>>>>>>
>>>>>> I will prepare a distribution using it by default.
>>>>>>
>>>>>
>>>>> Will it be configurable? I know about refresh problems - but the
>> resolver
>>>>> did a good job showing you what's wrong with the set of
>> features/bundles
>>>>> you're installing.
>>>>> Do you plan to switch to resolverless features service in micro release
>>>> of
>>>>> Karaf? Or will it be Karaf 4.4 / 5?
>>>>>
>>>>> regards
>>>>> Grzegorz Grzybek
>>>>>
>>>>>
>>>>>>
>>>>>> I will share some details soon.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre <jb...@nanthrax.net> a
>>>>>> écrit :
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> It doesn’t really break, it just don’t use it.
>>>>>>>
>>>>>>> It’s up to you to install all feature/bundle requirements.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>>> Le 11 janv. 2021 à 21:09, Markus Rathgeb <ma...@gmail.com> a
>>>> écrit
>>>>>> :
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>> - ignore requirement/capability (no resolver)
>>>>>>>>
>>>>>>>> did I get it right that this breaks the dependency=true feature that
>>>>>>>> installs bundles / features only if a requirement is not fullfilled
>>>> yet?
>>>>>>>>
>>>>>>>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
>>>>>>>> patriquelegault@gmail.com>:
>>>>>>>>
>>>>>>>>> Same here,
>>>>>>>>>
>>>>>>>>> This is behaviour that has been expected for some time now,
>> reversing
>>>>>> it
>>>>>>>>> could cause damage to systems that upgrade to the latest Karaf. I
>>>> would
>>>>>>>>> make it something that users opt into vs having to opt-out of.
>>>>>>>>>
>>>>>>>>> On Fri, 8 Jan 2021 at 08:42, Daniel Las <daniel.las@empirica.io
>>>>>> .invalid>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> It looks like some kind of backward incompatible change introduced
>>>>>> within
>>>>>>>>>> patch version change. I personally would like to keep auto refresh
>>>>>> "on"
>>>>>>>>> by
>>>>>>>>>> default as this is expected/desired behavior for me.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>>
>>>>>>>>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>>>>>>> napisał(a):
>>>>>>>>>>
>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>
>>>>>>>>>>> We got several user feedback, complaining about unexpected and
>>>>>> cascaded
>>>>>>>>>>> (unrelated) refresh while installing features.
>>>>>>>>>>>
>>>>>>>>>>> As reminder, a refresh can happen when:
>>>>>>>>>>> - bundle A imports package foo:1 and a bundle provides newer foo
>>>>>>>>> package
>>>>>>>>>>> version. In that case, the features service will refresh A to use
>>>> the
>>>>>>>>>>> newest package version.
>>>>>>>>>>> - bundle A has an optional import to package foo and a bundle
>>>>>> provides
>>>>>>>>>>> this package. In that case, the features service will refresh A
>> to
>>>>>>>>>> actually
>>>>>>>>>>> use the import as it’s a "resolved" optional.
>>>>>>>>>>> - bundle A is wired to bundle B (from a package perspective or
>>>>>>>>>>> requirement) and B is refreshed. In that case, the features
>> service
>>>>>>>>> will
>>>>>>>>>>> refresh A as B is itself refreshed (for the previous reasons for
>>>>>>>>>> instance).
>>>>>>>>>>> This can cause "cascading" refresh.
>>>>>>>>>>>
>>>>>>>>>>> A refresh means that a bundle can be restarted (if the bundle
>>>>>> contains
>>>>>>>>> an
>>>>>>>>>>> activator or similar (DS component, blueprint bundle)).
>>>>>>>>>>>
>>>>>>>>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose
>> to
>>>>>>>>>>> introduce a new property autoRefresh in
>>>>>>>>> etc/org.apache.karaf.features.cfg
>>>>>>>>>>> to disable the auto refresh by the features service (and let the
>>>> user
>>>>>>>>>>> decides when he wants to trigger refresh with bundle:refresh
>>>> command
>>>>>>>>> for
>>>>>>>>>>> instance).
>>>>>>>>>>> I propose to keep autoRefresh=true on 4.2.x and turn
>>>>>> autoRefresh=false
>>>>>>>>> on
>>>>>>>>>>> 4.3.x.
>>>>>>>>>>>
>>>>>>>>>>> Thoughts ?
>>>>>>>>>>>
>>>>>>>>>>> On the other hand (and to prepare the "path" to Karaf5), I have
>>>>>>>>> created a
>>>>>>>>>>> new "simple features service" (PR will be open soon) that:
>>>>>>>>>>>
>>>>>>>>>>> - just take the features definition in order (ignoring start
>> level)
>>>>>>>>>>> - ignore requirement/capability (no resolver)
>>>>>>>>>>> - no auto refresh
>>>>>>>>>>>
>>>>>>>>>>> Basically, if you have the following feature definition:
>>>>>>>>>>>
>>>>>>>>>>> <feature name="foo" version="1.0">
>>>>>>>>>>> <feature>bar</feature>
>>>>>>>>>>> <bundle>A</bundle>
>>>>>>>>>>> <bundle>B</bundle>
>>>>>>>>>>> </feature>
>>>>>>>>>>>
>>>>>>>>>>> The features service will fully install/start bar feature first,
>>>> then
>>>>>>>>>>> bundle A, then bundle B.
>>>>>>>>>>> To use this "simple features services, you just have to replace
>>>>>>>>>>> org.apache.karaf.features.core by
>> org.apache.karaf.features.simple
>>>>>>>>> bundle
>>>>>>>>>>> in etc/startup.properties (or custom distribution).
>>>>>>>>>>>
>>>>>>>>>>> It’s similar to the Karaf 5 extension behavior (I will share
>>>> complete
>>>>>>>>>>> details about Karaf 5 and its concepts (module, extension, …)
>> very
>>>>>>>>> soon,
>>>>>>>>>>> but that’s another thread ;)).
>>>>>>>>>>>
>>>>>>>>>>> The big advantages of this approach is:
>>>>>>>>>>> - predictable/deterministic provisioning (if it works fine, it
>>>> works
>>>>>>>>>> again)
>>>>>>>>>>> - faster deployment (I estimated the gain to about 70%)
>>>>>>>>>>>
>>>>>>>>>>> Thoughts ?
>>>>>>>>>>>
>>>>>>>>>>> If you agree, I will move forward on both tasks.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Regards
>>>>>>>>>>> JB
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Daniel Łaś
>>>>>>>>>> CTO at Empirica S.A.
>>>>>>>>>> +48 695 616181
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Patrique Legault*
>>
>>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Grzegorz Grzybek <gr...@gmail.com>.
śr., 19 maj 2021 o 08:59 Jean-Baptiste Onofre <jb...@nanthrax.net> 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 <gr...@gmail.com> a écrit
> :
> >
> > śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre <jb@nanthrax.net <mailto:
> jb@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 <gr...@gmail.com> a
> écrit
> >> :
> >>>
> >>> Hello
> >>>
> >>> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre <jb...@nanthrax.net>
> >> napisał(a):
> >>>
> >>>> Hi,
> >>>>
> >>>> Regarding recent comments from users and lot of refresh
> issues/questions
> >>>> we have in the past, I moved forward with a new simple features
> service
> >>>> that doesn’t use the resolver. It basically reads the features repo
> >>>> definition and just install what’s define in there statically.
> >>>>
> >>>> I will prepare a distribution using it by default.
> >>>>
> >>>
> >>> Will it be configurable? I know about refresh problems - but the
> resolver
> >>> did a good job showing you what's wrong with the set of
> features/bundles
> >>> you're installing.
> >>> Do you plan to switch to resolverless features service in micro release
> >> of
> >>> Karaf? Or will it be Karaf 4.4 / 5?
> >>>
> >>> regards
> >>> Grzegorz Grzybek
> >>>
> >>>
> >>>>
> >>>> I will share some details soon.
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre <jb...@nanthrax.net> a
> >>>> écrit :
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> It doesn’t really break, it just don’t use it.
> >>>>>
> >>>>> It’s up to you to install all feature/bundle requirements.
> >>>>>
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>>> Le 11 janv. 2021 à 21:09, Markus Rathgeb <ma...@gmail.com> a
> >> écrit
> >>>> :
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>>> - ignore requirement/capability (no resolver)
> >>>>>>
> >>>>>> did I get it right that this breaks the dependency=true feature that
> >>>>>> installs bundles / features only if a requirement is not fullfilled
> >> yet?
> >>>>>>
> >>>>>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
> >>>>>> patriquelegault@gmail.com>:
> >>>>>>
> >>>>>>> Same here,
> >>>>>>>
> >>>>>>> This is behaviour that has been expected for some time now,
> reversing
> >>>> it
> >>>>>>> could cause damage to systems that upgrade to the latest Karaf. I
> >> would
> >>>>>>> make it something that users opt into vs having to opt-out of.
> >>>>>>>
> >>>>>>> On Fri, 8 Jan 2021 at 08:42, Daniel Las <daniel.las@empirica.io
> >>>> .invalid>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> It looks like some kind of backward incompatible change introduced
> >>>> within
> >>>>>>>> patch version change. I personally would like to keep auto refresh
> >>>> "on"
> >>>>>>> by
> >>>>>>>> default as this is expected/desired behavior for me.
> >>>>>>>>
> >>>>>>>> Regards
> >>>>>>>>
> >>>>>>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
> >>>>>>> napisał(a):
> >>>>>>>>
> >>>>>>>>> Hi everyone,
> >>>>>>>>>
> >>>>>>>>> We got several user feedback, complaining about unexpected and
> >>>> cascaded
> >>>>>>>>> (unrelated) refresh while installing features.
> >>>>>>>>>
> >>>>>>>>> As reminder, a refresh can happen when:
> >>>>>>>>> - bundle A imports package foo:1 and a bundle provides newer foo
> >>>>>>> package
> >>>>>>>>> version. In that case, the features service will refresh A to use
> >> the
> >>>>>>>>> newest package version.
> >>>>>>>>> - bundle A has an optional import to package foo and a bundle
> >>>> provides
> >>>>>>>>> this package. In that case, the features service will refresh A
> to
> >>>>>>>> actually
> >>>>>>>>> use the import as it’s a "resolved" optional.
> >>>>>>>>> - bundle A is wired to bundle B (from a package perspective or
> >>>>>>>>> requirement) and B is refreshed. In that case, the features
> service
> >>>>>>> will
> >>>>>>>>> refresh A as B is itself refreshed (for the previous reasons for
> >>>>>>>> instance).
> >>>>>>>>> This can cause "cascading" refresh.
> >>>>>>>>>
> >>>>>>>>> A refresh means that a bundle can be restarted (if the bundle
> >>>> contains
> >>>>>>> an
> >>>>>>>>> activator or similar (DS component, blueprint bundle)).
> >>>>>>>>>
> >>>>>>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose
> to
> >>>>>>>>> introduce a new property autoRefresh in
> >>>>>>> etc/org.apache.karaf.features.cfg
> >>>>>>>>> to disable the auto refresh by the features service (and let the
> >> user
> >>>>>>>>> decides when he wants to trigger refresh with bundle:refresh
> >> command
> >>>>>>> for
> >>>>>>>>> instance).
> >>>>>>>>> I propose to keep autoRefresh=true on 4.2.x and turn
> >>>> autoRefresh=false
> >>>>>>> on
> >>>>>>>>> 4.3.x.
> >>>>>>>>>
> >>>>>>>>> Thoughts ?
> >>>>>>>>>
> >>>>>>>>> On the other hand (and to prepare the "path" to Karaf5), I have
> >>>>>>> created a
> >>>>>>>>> new "simple features service" (PR will be open soon) that:
> >>>>>>>>>
> >>>>>>>>> - just take the features definition in order (ignoring start
> level)
> >>>>>>>>> - ignore requirement/capability (no resolver)
> >>>>>>>>> - no auto refresh
> >>>>>>>>>
> >>>>>>>>> Basically, if you have the following feature definition:
> >>>>>>>>>
> >>>>>>>>> <feature name="foo" version="1.0">
> >>>>>>>>> <feature>bar</feature>
> >>>>>>>>> <bundle>A</bundle>
> >>>>>>>>> <bundle>B</bundle>
> >>>>>>>>> </feature>
> >>>>>>>>>
> >>>>>>>>> The features service will fully install/start bar feature first,
> >> then
> >>>>>>>>> bundle A, then bundle B.
> >>>>>>>>> To use this "simple features services, you just have to replace
> >>>>>>>>> org.apache.karaf.features.core by
> org.apache.karaf.features.simple
> >>>>>>> bundle
> >>>>>>>>> in etc/startup.properties (or custom distribution).
> >>>>>>>>>
> >>>>>>>>> It’s similar to the Karaf 5 extension behavior (I will share
> >> complete
> >>>>>>>>> details about Karaf 5 and its concepts (module, extension, …)
> very
> >>>>>>> soon,
> >>>>>>>>> but that’s another thread ;)).
> >>>>>>>>>
> >>>>>>>>> The big advantages of this approach is:
> >>>>>>>>> - predictable/deterministic provisioning (if it works fine, it
> >> works
> >>>>>>>> again)
> >>>>>>>>> - faster deployment (I estimated the gain to about 70%)
> >>>>>>>>>
> >>>>>>>>> Thoughts ?
> >>>>>>>>>
> >>>>>>>>> If you agree, I will move forward on both tasks.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Regards
> >>>>>>>>> JB
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Daniel Łaś
> >>>>>>>> CTO at Empirica S.A.
> >>>>>>>> +48 695 616181
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> *Patrique Legault*
>
>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <gr...@gmail.com> a écrit :
>
> śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre <jb@nanthrax.net <ma...@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 <gr...@gmail.com> a écrit
>> :
>>>
>>> Hello
>>>
>>> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre <jb...@nanthrax.net>
>> napisał(a):
>>>
>>>> Hi,
>>>>
>>>> Regarding recent comments from users and lot of refresh issues/questions
>>>> we have in the past, I moved forward with a new simple features service
>>>> that doesn’t use the resolver. It basically reads the features repo
>>>> definition and just install what’s define in there statically.
>>>>
>>>> I will prepare a distribution using it by default.
>>>>
>>>
>>> Will it be configurable? I know about refresh problems - but the resolver
>>> did a good job showing you what's wrong with the set of features/bundles
>>> you're installing.
>>> Do you plan to switch to resolverless features service in micro release
>> of
>>> Karaf? Or will it be Karaf 4.4 / 5?
>>>
>>> regards
>>> Grzegorz Grzybek
>>>
>>>
>>>>
>>>> I will share some details soon.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre <jb...@nanthrax.net> a
>>>> écrit :
>>>>>
>>>>> Hi,
>>>>>
>>>>> It doesn’t really break, it just don’t use it.
>>>>>
>>>>> It’s up to you to install all feature/bundle requirements.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>> Le 11 janv. 2021 à 21:09, Markus Rathgeb <ma...@gmail.com> a
>> écrit
>>>> :
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> - ignore requirement/capability (no resolver)
>>>>>>
>>>>>> did I get it right that this breaks the dependency=true feature that
>>>>>> installs bundles / features only if a requirement is not fullfilled
>> yet?
>>>>>>
>>>>>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
>>>>>> patriquelegault@gmail.com>:
>>>>>>
>>>>>>> Same here,
>>>>>>>
>>>>>>> This is behaviour that has been expected for some time now, reversing
>>>> it
>>>>>>> could cause damage to systems that upgrade to the latest Karaf. I
>> would
>>>>>>> make it something that users opt into vs having to opt-out of.
>>>>>>>
>>>>>>> On Fri, 8 Jan 2021 at 08:42, Daniel Las <daniel.las@empirica.io
>>>> .invalid>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> It looks like some kind of backward incompatible change introduced
>>>> within
>>>>>>>> patch version change. I personally would like to keep auto refresh
>>>> "on"
>>>>>>> by
>>>>>>>> default as this is expected/desired behavior for me.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>>>>> napisał(a):
>>>>>>>>
>>>>>>>>> Hi everyone,
>>>>>>>>>
>>>>>>>>> We got several user feedback, complaining about unexpected and
>>>> cascaded
>>>>>>>>> (unrelated) refresh while installing features.
>>>>>>>>>
>>>>>>>>> As reminder, a refresh can happen when:
>>>>>>>>> - bundle A imports package foo:1 and a bundle provides newer foo
>>>>>>> package
>>>>>>>>> version. In that case, the features service will refresh A to use
>> the
>>>>>>>>> newest package version.
>>>>>>>>> - bundle A has an optional import to package foo and a bundle
>>>> provides
>>>>>>>>> this package. In that case, the features service will refresh A to
>>>>>>>> actually
>>>>>>>>> use the import as it’s a "resolved" optional.
>>>>>>>>> - bundle A is wired to bundle B (from a package perspective or
>>>>>>>>> requirement) and B is refreshed. In that case, the features service
>>>>>>> will
>>>>>>>>> refresh A as B is itself refreshed (for the previous reasons for
>>>>>>>> instance).
>>>>>>>>> This can cause "cascading" refresh.
>>>>>>>>>
>>>>>>>>> A refresh means that a bundle can be restarted (if the bundle
>>>> contains
>>>>>>> an
>>>>>>>>> activator or similar (DS component, blueprint bundle)).
>>>>>>>>>
>>>>>>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
>>>>>>>>> introduce a new property autoRefresh in
>>>>>>> etc/org.apache.karaf.features.cfg
>>>>>>>>> to disable the auto refresh by the features service (and let the
>> user
>>>>>>>>> decides when he wants to trigger refresh with bundle:refresh
>> command
>>>>>>> for
>>>>>>>>> instance).
>>>>>>>>> I propose to keep autoRefresh=true on 4.2.x and turn
>>>> autoRefresh=false
>>>>>>> on
>>>>>>>>> 4.3.x.
>>>>>>>>>
>>>>>>>>> Thoughts ?
>>>>>>>>>
>>>>>>>>> On the other hand (and to prepare the "path" to Karaf5), I have
>>>>>>> created a
>>>>>>>>> new "simple features service" (PR will be open soon) that:
>>>>>>>>>
>>>>>>>>> - just take the features definition in order (ignoring start level)
>>>>>>>>> - ignore requirement/capability (no resolver)
>>>>>>>>> - no auto refresh
>>>>>>>>>
>>>>>>>>> Basically, if you have the following feature definition:
>>>>>>>>>
>>>>>>>>> <feature name="foo" version="1.0">
>>>>>>>>> <feature>bar</feature>
>>>>>>>>> <bundle>A</bundle>
>>>>>>>>> <bundle>B</bundle>
>>>>>>>>> </feature>
>>>>>>>>>
>>>>>>>>> The features service will fully install/start bar feature first,
>> then
>>>>>>>>> bundle A, then bundle B.
>>>>>>>>> To use this "simple features services, you just have to replace
>>>>>>>>> org.apache.karaf.features.core by org.apache.karaf.features.simple
>>>>>>> bundle
>>>>>>>>> in etc/startup.properties (or custom distribution).
>>>>>>>>>
>>>>>>>>> It’s similar to the Karaf 5 extension behavior (I will share
>> complete
>>>>>>>>> details about Karaf 5 and its concepts (module, extension, …) very
>>>>>>> soon,
>>>>>>>>> but that’s another thread ;)).
>>>>>>>>>
>>>>>>>>> The big advantages of this approach is:
>>>>>>>>> - predictable/deterministic provisioning (if it works fine, it
>> works
>>>>>>>> again)
>>>>>>>>> - faster deployment (I estimated the gain to about 70%)
>>>>>>>>>
>>>>>>>>> Thoughts ?
>>>>>>>>>
>>>>>>>>> If you agree, I will move forward on both tasks.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Daniel Łaś
>>>>>>>> CTO at Empirica S.A.
>>>>>>>> +48 695 616181
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Patrique Legault*
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Grzegorz Grzybek <gr...@gmail.com>.
śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre <jb...@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 <gr...@gmail.com> a écrit
> :
> >
> > Hello
> >
> > śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre <jb...@nanthrax.net>
> napisał(a):
> >
> >> Hi,
> >>
> >> Regarding recent comments from users and lot of refresh issues/questions
> >> we have in the past, I moved forward with a new simple features service
> >> that doesn’t use the resolver. It basically reads the features repo
> >> definition and just install what’s define in there statically.
> >>
> >> I will prepare a distribution using it by default.
> >>
> >
> > Will it be configurable? I know about refresh problems - but the resolver
> > did a good job showing you what's wrong with the set of features/bundles
> > you're installing.
> > Do you plan to switch to resolverless features service in micro release
> of
> > Karaf? Or will it be Karaf 4.4 / 5?
> >
> > regards
> > Grzegorz Grzybek
> >
> >
> >>
> >> I will share some details soon.
> >>
> >> Regards
> >> JB
> >>
> >>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre <jb...@nanthrax.net> a
> >> écrit :
> >>>
> >>> Hi,
> >>>
> >>> It doesn’t really break, it just don’t use it.
> >>>
> >>> It’s up to you to install all feature/bundle requirements.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>> Le 11 janv. 2021 à 21:09, Markus Rathgeb <ma...@gmail.com> a
> écrit
> >> :
> >>>>
> >>>> Hi,
> >>>>
> >>>>> - ignore requirement/capability (no resolver)
> >>>>
> >>>> did I get it right that this breaks the dependency=true feature that
> >>>> installs bundles / features only if a requirement is not fullfilled
> yet?
> >>>>
> >>>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
> >>>> patriquelegault@gmail.com>:
> >>>>
> >>>>> Same here,
> >>>>>
> >>>>> This is behaviour that has been expected for some time now, reversing
> >> it
> >>>>> could cause damage to systems that upgrade to the latest Karaf. I
> would
> >>>>> make it something that users opt into vs having to opt-out of.
> >>>>>
> >>>>> On Fri, 8 Jan 2021 at 08:42, Daniel Las <daniel.las@empirica.io
> >> .invalid>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> It looks like some kind of backward incompatible change introduced
> >> within
> >>>>>> patch version change. I personally would like to keep auto refresh
> >> "on"
> >>>>> by
> >>>>>> default as this is expected/desired behavior for me.
> >>>>>>
> >>>>>> Regards
> >>>>>>
> >>>>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
> >>>>> napisał(a):
> >>>>>>
> >>>>>>> Hi everyone,
> >>>>>>>
> >>>>>>> We got several user feedback, complaining about unexpected and
> >> cascaded
> >>>>>>> (unrelated) refresh while installing features.
> >>>>>>>
> >>>>>>> As reminder, a refresh can happen when:
> >>>>>>> - bundle A imports package foo:1 and a bundle provides newer foo
> >>>>> package
> >>>>>>> version. In that case, the features service will refresh A to use
> the
> >>>>>>> newest package version.
> >>>>>>> - bundle A has an optional import to package foo and a bundle
> >> provides
> >>>>>>> this package. In that case, the features service will refresh A to
> >>>>>> actually
> >>>>>>> use the import as it’s a "resolved" optional.
> >>>>>>> - bundle A is wired to bundle B (from a package perspective or
> >>>>>>> requirement) and B is refreshed. In that case, the features service
> >>>>> will
> >>>>>>> refresh A as B is itself refreshed (for the previous reasons for
> >>>>>> instance).
> >>>>>>> This can cause "cascading" refresh.
> >>>>>>>
> >>>>>>> A refresh means that a bundle can be restarted (if the bundle
> >> contains
> >>>>> an
> >>>>>>> activator or similar (DS component, blueprint bundle)).
> >>>>>>>
> >>>>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
> >>>>>>> introduce a new property autoRefresh in
> >>>>> etc/org.apache.karaf.features.cfg
> >>>>>>> to disable the auto refresh by the features service (and let the
> user
> >>>>>>> decides when he wants to trigger refresh with bundle:refresh
> command
> >>>>> for
> >>>>>>> instance).
> >>>>>>> I propose to keep autoRefresh=true on 4.2.x and turn
> >> autoRefresh=false
> >>>>> on
> >>>>>>> 4.3.x.
> >>>>>>>
> >>>>>>> Thoughts ?
> >>>>>>>
> >>>>>>> On the other hand (and to prepare the "path" to Karaf5), I have
> >>>>> created a
> >>>>>>> new "simple features service" (PR will be open soon) that:
> >>>>>>>
> >>>>>>> - just take the features definition in order (ignoring start level)
> >>>>>>> - ignore requirement/capability (no resolver)
> >>>>>>> - no auto refresh
> >>>>>>>
> >>>>>>> Basically, if you have the following feature definition:
> >>>>>>>
> >>>>>>> <feature name="foo" version="1.0">
> >>>>>>> <feature>bar</feature>
> >>>>>>> <bundle>A</bundle>
> >>>>>>> <bundle>B</bundle>
> >>>>>>> </feature>
> >>>>>>>
> >>>>>>> The features service will fully install/start bar feature first,
> then
> >>>>>>> bundle A, then bundle B.
> >>>>>>> To use this "simple features services, you just have to replace
> >>>>>>> org.apache.karaf.features.core by org.apache.karaf.features.simple
> >>>>> bundle
> >>>>>>> in etc/startup.properties (or custom distribution).
> >>>>>>>
> >>>>>>> It’s similar to the Karaf 5 extension behavior (I will share
> complete
> >>>>>>> details about Karaf 5 and its concepts (module, extension, …) very
> >>>>> soon,
> >>>>>>> but that’s another thread ;)).
> >>>>>>>
> >>>>>>> The big advantages of this approach is:
> >>>>>>> - predictable/deterministic provisioning (if it works fine, it
> works
> >>>>>> again)
> >>>>>>> - faster deployment (I estimated the gain to about 70%)
> >>>>>>>
> >>>>>>> Thoughts ?
> >>>>>>>
> >>>>>>> If you agree, I will move forward on both tasks.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Regards
> >>>>>>> JB
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Daniel Łaś
> >>>>>> CTO at Empirica S.A.
> >>>>>> +48 695 616181
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> *Patrique Legault*
> >>>>>
> >>>
> >>
> >>
>
>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <gr...@gmail.com> a écrit :
>
> Hello
>
> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>
>> Hi,
>>
>> Regarding recent comments from users and lot of refresh issues/questions
>> we have in the past, I moved forward with a new simple features service
>> that doesn’t use the resolver. It basically reads the features repo
>> definition and just install what’s define in there statically.
>>
>> I will prepare a distribution using it by default.
>>
>
> Will it be configurable? I know about refresh problems - but the resolver
> did a good job showing you what's wrong with the set of features/bundles
> you're installing.
> Do you plan to switch to resolverless features service in micro release of
> Karaf? Or will it be Karaf 4.4 / 5?
>
> regards
> Grzegorz Grzybek
>
>
>>
>> I will share some details soon.
>>
>> Regards
>> JB
>>
>>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre <jb...@nanthrax.net> a
>> écrit :
>>>
>>> Hi,
>>>
>>> It doesn’t really break, it just don’t use it.
>>>
>>> It’s up to you to install all feature/bundle requirements.
>>>
>>> Regards
>>> JB
>>>
>>>> Le 11 janv. 2021 à 21:09, Markus Rathgeb <ma...@gmail.com> a écrit
>> :
>>>>
>>>> Hi,
>>>>
>>>>> - ignore requirement/capability (no resolver)
>>>>
>>>> did I get it right that this breaks the dependency=true feature that
>>>> installs bundles / features only if a requirement is not fullfilled yet?
>>>>
>>>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
>>>> patriquelegault@gmail.com>:
>>>>
>>>>> Same here,
>>>>>
>>>>> This is behaviour that has been expected for some time now, reversing
>> it
>>>>> could cause damage to systems that upgrade to the latest Karaf. I would
>>>>> make it something that users opt into vs having to opt-out of.
>>>>>
>>>>> On Fri, 8 Jan 2021 at 08:42, Daniel Las <daniel.las@empirica.io
>> .invalid>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It looks like some kind of backward incompatible change introduced
>> within
>>>>>> patch version change. I personally would like to keep auto refresh
>> "on"
>>>>> by
>>>>>> default as this is expected/desired behavior for me.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>>> napisał(a):
>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> We got several user feedback, complaining about unexpected and
>> cascaded
>>>>>>> (unrelated) refresh while installing features.
>>>>>>>
>>>>>>> As reminder, a refresh can happen when:
>>>>>>> - bundle A imports package foo:1 and a bundle provides newer foo
>>>>> package
>>>>>>> version. In that case, the features service will refresh A to use the
>>>>>>> newest package version.
>>>>>>> - bundle A has an optional import to package foo and a bundle
>> provides
>>>>>>> this package. In that case, the features service will refresh A to
>>>>>> actually
>>>>>>> use the import as it’s a "resolved" optional.
>>>>>>> - bundle A is wired to bundle B (from a package perspective or
>>>>>>> requirement) and B is refreshed. In that case, the features service
>>>>> will
>>>>>>> refresh A as B is itself refreshed (for the previous reasons for
>>>>>> instance).
>>>>>>> This can cause "cascading" refresh.
>>>>>>>
>>>>>>> A refresh means that a bundle can be restarted (if the bundle
>> contains
>>>>> an
>>>>>>> activator or similar (DS component, blueprint bundle)).
>>>>>>>
>>>>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
>>>>>>> introduce a new property autoRefresh in
>>>>> etc/org.apache.karaf.features.cfg
>>>>>>> to disable the auto refresh by the features service (and let the user
>>>>>>> decides when he wants to trigger refresh with bundle:refresh command
>>>>> for
>>>>>>> instance).
>>>>>>> I propose to keep autoRefresh=true on 4.2.x and turn
>> autoRefresh=false
>>>>> on
>>>>>>> 4.3.x.
>>>>>>>
>>>>>>> Thoughts ?
>>>>>>>
>>>>>>> On the other hand (and to prepare the "path" to Karaf5), I have
>>>>> created a
>>>>>>> new "simple features service" (PR will be open soon) that:
>>>>>>>
>>>>>>> - just take the features definition in order (ignoring start level)
>>>>>>> - ignore requirement/capability (no resolver)
>>>>>>> - no auto refresh
>>>>>>>
>>>>>>> Basically, if you have the following feature definition:
>>>>>>>
>>>>>>> <feature name="foo" version="1.0">
>>>>>>> <feature>bar</feature>
>>>>>>> <bundle>A</bundle>
>>>>>>> <bundle>B</bundle>
>>>>>>> </feature>
>>>>>>>
>>>>>>> The features service will fully install/start bar feature first, then
>>>>>>> bundle A, then bundle B.
>>>>>>> To use this "simple features services, you just have to replace
>>>>>>> org.apache.karaf.features.core by org.apache.karaf.features.simple
>>>>> bundle
>>>>>>> in etc/startup.properties (or custom distribution).
>>>>>>>
>>>>>>> It’s similar to the Karaf 5 extension behavior (I will share complete
>>>>>>> details about Karaf 5 and its concepts (module, extension, …) very
>>>>> soon,
>>>>>>> but that’s another thread ;)).
>>>>>>>
>>>>>>> The big advantages of this approach is:
>>>>>>> - predictable/deterministic provisioning (if it works fine, it works
>>>>>> again)
>>>>>>> - faster deployment (I estimated the gain to about 70%)
>>>>>>>
>>>>>>> Thoughts ?
>>>>>>>
>>>>>>> If you agree, I will move forward on both tasks.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Daniel Łaś
>>>>>> CTO at Empirica S.A.
>>>>>> +48 695 616181
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Patrique Legault*
>>>>>
>>>
>>
>>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Hello
śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
> Hi,
>
> Regarding recent comments from users and lot of refresh issues/questions
> we have in the past, I moved forward with a new simple features service
> that doesn’t use the resolver. It basically reads the features repo
> definition and just install what’s define in there statically.
>
> I will prepare a distribution using it by default.
>
Will it be configurable? I know about refresh problems - but the resolver
did a good job showing you what's wrong with the set of features/bundles
you're installing.
Do you plan to switch to resolverless features service in micro release of
Karaf? Or will it be Karaf 4.4 / 5?
regards
Grzegorz Grzybek
>
> I will share some details soon.
>
> Regards
> JB
>
> > Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre <jb...@nanthrax.net> a
> écrit :
> >
> > Hi,
> >
> > It doesn’t really break, it just don’t use it.
> >
> > It’s up to you to install all feature/bundle requirements.
> >
> > Regards
> > JB
> >
> >> Le 11 janv. 2021 à 21:09, Markus Rathgeb <ma...@gmail.com> a écrit
> :
> >>
> >> Hi,
> >>
> >>> - ignore requirement/capability (no resolver)
> >>
> >> did I get it right that this breaks the dependency=true feature that
> >> installs bundles / features only if a requirement is not fullfilled yet?
> >>
> >> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
> >> patriquelegault@gmail.com>:
> >>
> >>> Same here,
> >>>
> >>> This is behaviour that has been expected for some time now, reversing
> it
> >>> could cause damage to systems that upgrade to the latest Karaf. I would
> >>> make it something that users opt into vs having to opt-out of.
> >>>
> >>> On Fri, 8 Jan 2021 at 08:42, Daniel Las <daniel.las@empirica.io
> .invalid>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> It looks like some kind of backward incompatible change introduced
> within
> >>>> patch version change. I personally would like to keep auto refresh
> "on"
> >>> by
> >>>> default as this is expected/desired behavior for me.
> >>>>
> >>>> Regards
> >>>>
> >>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
> >>> napisał(a):
> >>>>
> >>>>> Hi everyone,
> >>>>>
> >>>>> We got several user feedback, complaining about unexpected and
> cascaded
> >>>>> (unrelated) refresh while installing features.
> >>>>>
> >>>>> As reminder, a refresh can happen when:
> >>>>> - bundle A imports package foo:1 and a bundle provides newer foo
> >>> package
> >>>>> version. In that case, the features service will refresh A to use the
> >>>>> newest package version.
> >>>>> - bundle A has an optional import to package foo and a bundle
> provides
> >>>>> this package. In that case, the features service will refresh A to
> >>>> actually
> >>>>> use the import as it’s a "resolved" optional.
> >>>>> - bundle A is wired to bundle B (from a package perspective or
> >>>>> requirement) and B is refreshed. In that case, the features service
> >>> will
> >>>>> refresh A as B is itself refreshed (for the previous reasons for
> >>>> instance).
> >>>>> This can cause "cascading" refresh.
> >>>>>
> >>>>> A refresh means that a bundle can be restarted (if the bundle
> contains
> >>> an
> >>>>> activator or similar (DS component, blueprint bundle)).
> >>>>>
> >>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
> >>>>> introduce a new property autoRefresh in
> >>> etc/org.apache.karaf.features.cfg
> >>>>> to disable the auto refresh by the features service (and let the user
> >>>>> decides when he wants to trigger refresh with bundle:refresh command
> >>> for
> >>>>> instance).
> >>>>> I propose to keep autoRefresh=true on 4.2.x and turn
> autoRefresh=false
> >>> on
> >>>>> 4.3.x.
> >>>>>
> >>>>> Thoughts ?
> >>>>>
> >>>>> On the other hand (and to prepare the "path" to Karaf5), I have
> >>> created a
> >>>>> new "simple features service" (PR will be open soon) that:
> >>>>>
> >>>>> - just take the features definition in order (ignoring start level)
> >>>>> - ignore requirement/capability (no resolver)
> >>>>> - no auto refresh
> >>>>>
> >>>>> Basically, if you have the following feature definition:
> >>>>>
> >>>>> <feature name="foo" version="1.0">
> >>>>> <feature>bar</feature>
> >>>>> <bundle>A</bundle>
> >>>>> <bundle>B</bundle>
> >>>>> </feature>
> >>>>>
> >>>>> The features service will fully install/start bar feature first, then
> >>>>> bundle A, then bundle B.
> >>>>> To use this "simple features services, you just have to replace
> >>>>> org.apache.karaf.features.core by org.apache.karaf.features.simple
> >>> bundle
> >>>>> in etc/startup.properties (or custom distribution).
> >>>>>
> >>>>> It’s similar to the Karaf 5 extension behavior (I will share complete
> >>>>> details about Karaf 5 and its concepts (module, extension, …) very
> >>> soon,
> >>>>> but that’s another thread ;)).
> >>>>>
> >>>>> The big advantages of this approach is:
> >>>>> - predictable/deterministic provisioning (if it works fine, it works
> >>>> again)
> >>>>> - faster deployment (I estimated the gain to about 70%)
> >>>>>
> >>>>> Thoughts ?
> >>>>>
> >>>>> If you agree, I will move forward on both tasks.
> >>>>>
> >>>>> Thanks,
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Daniel Łaś
> >>>> CTO at Empirica S.A.
> >>>> +48 695 616181
> >>>>
> >>>
> >>>
> >>> --
> >>> *Patrique Legault*
> >>>
> >
>
>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <jb...@nanthrax.net> a écrit :
>
> Hi,
>
> It doesn’t really break, it just don’t use it.
>
> It’s up to you to install all feature/bundle requirements.
>
> Regards
> JB
>
>> Le 11 janv. 2021 à 21:09, Markus Rathgeb <ma...@gmail.com> a écrit :
>>
>> Hi,
>>
>>> - ignore requirement/capability (no resolver)
>>
>> did I get it right that this breaks the dependency=true feature that
>> installs bundles / features only if a requirement is not fullfilled yet?
>>
>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
>> patriquelegault@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 <da...@empirica.io.invalid>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> It looks like some kind of backward incompatible change introduced within
>>>> patch version change. I personally would like to keep auto refresh "on"
>>> by
>>>> default as this is expected/desired behavior for me.
>>>>
>>>> Regards
>>>>
>>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
>>> napisał(a):
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> We got several user feedback, complaining about unexpected and cascaded
>>>>> (unrelated) refresh while installing features.
>>>>>
>>>>> As reminder, a refresh can happen when:
>>>>> - bundle A imports package foo:1 and a bundle provides newer foo
>>> package
>>>>> version. In that case, the features service will refresh A to use the
>>>>> newest package version.
>>>>> - bundle A has an optional import to package foo and a bundle provides
>>>>> this package. In that case, the features service will refresh A to
>>>> actually
>>>>> use the import as it’s a "resolved" optional.
>>>>> - bundle A is wired to bundle B (from a package perspective or
>>>>> requirement) and B is refreshed. In that case, the features service
>>> will
>>>>> refresh A as B is itself refreshed (for the previous reasons for
>>>> instance).
>>>>> This can cause "cascading" refresh.
>>>>>
>>>>> A refresh means that a bundle can be restarted (if the bundle contains
>>> an
>>>>> activator or similar (DS component, blueprint bundle)).
>>>>>
>>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
>>>>> introduce a new property autoRefresh in
>>> etc/org.apache.karaf.features.cfg
>>>>> to disable the auto refresh by the features service (and let the user
>>>>> decides when he wants to trigger refresh with bundle:refresh command
>>> for
>>>>> instance).
>>>>> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false
>>> on
>>>>> 4.3.x.
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>> On the other hand (and to prepare the "path" to Karaf5), I have
>>> created a
>>>>> new "simple features service" (PR will be open soon) that:
>>>>>
>>>>> - just take the features definition in order (ignoring start level)
>>>>> - ignore requirement/capability (no resolver)
>>>>> - no auto refresh
>>>>>
>>>>> Basically, if you have the following feature definition:
>>>>>
>>>>> <feature name="foo" version="1.0">
>>>>> <feature>bar</feature>
>>>>> <bundle>A</bundle>
>>>>> <bundle>B</bundle>
>>>>> </feature>
>>>>>
>>>>> The features service will fully install/start bar feature first, then
>>>>> bundle A, then bundle B.
>>>>> To use this "simple features services, you just have to replace
>>>>> org.apache.karaf.features.core by org.apache.karaf.features.simple
>>> bundle
>>>>> in etc/startup.properties (or custom distribution).
>>>>>
>>>>> It’s similar to the Karaf 5 extension behavior (I will share complete
>>>>> details about Karaf 5 and its concepts (module, extension, …) very
>>> soon,
>>>>> but that’s another thread ;)).
>>>>>
>>>>> The big advantages of this approach is:
>>>>> - predictable/deterministic provisioning (if it works fine, it works
>>>> again)
>>>>> - faster deployment (I estimated the gain to about 70%)
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>> If you agree, I will move forward on both tasks.
>>>>>
>>>>> Thanks,
>>>>> Regards
>>>>> JB
>>>>>
>>>>
>>>>
>>>> --
>>>> Daniel Łaś
>>>> CTO at Empirica S.A.
>>>> +48 695 616181
>>>>
>>>
>>>
>>> --
>>> *Patrique Legault*
>>>
>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <ma...@gmail.com> a écrit :
>
> Hi,
>
>> - ignore requirement/capability (no resolver)
>
> did I get it right that this breaks the dependency=true feature that
> installs bundles / features only if a requirement is not fullfilled yet?
>
> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
> patriquelegault@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 <da...@empirica.io.invalid>
>> wrote:
>>
>>> Hi,
>>>
>>> It looks like some kind of backward incompatible change introduced within
>>> patch version change. I personally would like to keep auto refresh "on"
>> by
>>> default as this is expected/desired behavior for me.
>>>
>>> Regards
>>>
>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
>> napisał(a):
>>>
>>>> Hi everyone,
>>>>
>>>> We got several user feedback, complaining about unexpected and cascaded
>>>> (unrelated) refresh while installing features.
>>>>
>>>> As reminder, a refresh can happen when:
>>>> - bundle A imports package foo:1 and a bundle provides newer foo
>> package
>>>> version. In that case, the features service will refresh A to use the
>>>> newest package version.
>>>> - bundle A has an optional import to package foo and a bundle provides
>>>> this package. In that case, the features service will refresh A to
>>> actually
>>>> use the import as it’s a "resolved" optional.
>>>> - bundle A is wired to bundle B (from a package perspective or
>>>> requirement) and B is refreshed. In that case, the features service
>> will
>>>> refresh A as B is itself refreshed (for the previous reasons for
>>> instance).
>>>> This can cause "cascading" refresh.
>>>>
>>>> A refresh means that a bundle can be restarted (if the bundle contains
>> an
>>>> activator or similar (DS component, blueprint bundle)).
>>>>
>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
>>>> introduce a new property autoRefresh in
>> etc/org.apache.karaf.features.cfg
>>>> to disable the auto refresh by the features service (and let the user
>>>> decides when he wants to trigger refresh with bundle:refresh command
>> for
>>>> instance).
>>>> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false
>> on
>>>> 4.3.x.
>>>>
>>>> Thoughts ?
>>>>
>>>> On the other hand (and to prepare the "path" to Karaf5), I have
>> created a
>>>> new "simple features service" (PR will be open soon) that:
>>>>
>>>> - just take the features definition in order (ignoring start level)
>>>> - ignore requirement/capability (no resolver)
>>>> - no auto refresh
>>>>
>>>> Basically, if you have the following feature definition:
>>>>
>>>> <feature name="foo" version="1.0">
>>>> <feature>bar</feature>
>>>> <bundle>A</bundle>
>>>> <bundle>B</bundle>
>>>> </feature>
>>>>
>>>> The features service will fully install/start bar feature first, then
>>>> bundle A, then bundle B.
>>>> To use this "simple features services, you just have to replace
>>>> org.apache.karaf.features.core by org.apache.karaf.features.simple
>> bundle
>>>> in etc/startup.properties (or custom distribution).
>>>>
>>>> It’s similar to the Karaf 5 extension behavior (I will share complete
>>>> details about Karaf 5 and its concepts (module, extension, …) very
>> soon,
>>>> but that’s another thread ;)).
>>>>
>>>> The big advantages of this approach is:
>>>> - predictable/deterministic provisioning (if it works fine, it works
>>> again)
>>>> - faster deployment (I estimated the gain to about 70%)
>>>>
>>>> Thoughts ?
>>>>
>>>> If you agree, I will move forward on both tasks.
>>>>
>>>> Thanks,
>>>> Regards
>>>> JB
>>>>
>>>
>>>
>>> --
>>> Daniel Łaś
>>> CTO at Empirica S.A.
>>> +48 695 616181
>>>
>>
>>
>> --
>> *Patrique Legault*
>>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Markus Rathgeb <ma...@gmail.com>.
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 <
patriquelegault@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 <da...@empirica.io.invalid>
> wrote:
>
> > Hi,
> >
> > It looks like some kind of backward incompatible change introduced within
> > patch version change. I personally would like to keep auto refresh "on"
> by
> > default as this is expected/desired behavior for me.
> >
> > Regards
> >
> > pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net>
> napisał(a):
> >
> > > Hi everyone,
> > >
> > > We got several user feedback, complaining about unexpected and cascaded
> > > (unrelated) refresh while installing features.
> > >
> > > As reminder, a refresh can happen when:
> > > - bundle A imports package foo:1 and a bundle provides newer foo
> package
> > > version. In that case, the features service will refresh A to use the
> > > newest package version.
> > > - bundle A has an optional import to package foo and a bundle provides
> > > this package. In that case, the features service will refresh A to
> > actually
> > > use the import as it’s a "resolved" optional.
> > > - bundle A is wired to bundle B (from a package perspective or
> > > requirement) and B is refreshed. In that case, the features service
> will
> > > refresh A as B is itself refreshed (for the previous reasons for
> > instance).
> > > This can cause "cascading" refresh.
> > >
> > > A refresh means that a bundle can be restarted (if the bundle contains
> an
> > > activator or similar (DS component, blueprint bundle)).
> > >
> > > In this PR https://github.com/apache/karaf/pull/1287, I propose to
> > > introduce a new property autoRefresh in
> etc/org.apache.karaf.features.cfg
> > > to disable the auto refresh by the features service (and let the user
> > > decides when he wants to trigger refresh with bundle:refresh command
> for
> > > instance).
> > > I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false
> on
> > > 4.3.x.
> > >
> > > Thoughts ?
> > >
> > > On the other hand (and to prepare the "path" to Karaf5), I have
> created a
> > > new "simple features service" (PR will be open soon) that:
> > >
> > > - just take the features definition in order (ignoring start level)
> > > - ignore requirement/capability (no resolver)
> > > - no auto refresh
> > >
> > > Basically, if you have the following feature definition:
> > >
> > > <feature name="foo" version="1.0">
> > > <feature>bar</feature>
> > > <bundle>A</bundle>
> > > <bundle>B</bundle>
> > > </feature>
> > >
> > > The features service will fully install/start bar feature first, then
> > > bundle A, then bundle B.
> > > To use this "simple features services, you just have to replace
> > > org.apache.karaf.features.core by org.apache.karaf.features.simple
> bundle
> > > in etc/startup.properties (or custom distribution).
> > >
> > > It’s similar to the Karaf 5 extension behavior (I will share complete
> > > details about Karaf 5 and its concepts (module, extension, …) very
> soon,
> > > but that’s another thread ;)).
> > >
> > > The big advantages of this approach is:
> > > - predictable/deterministic provisioning (if it works fine, it works
> > again)
> > > - faster deployment (I estimated the gain to about 70%)
> > >
> > > Thoughts ?
> > >
> > > If you agree, I will move forward on both tasks.
> > >
> > > Thanks,
> > > Regards
> > > JB
> > >
> >
> >
> > --
> > Daniel Łaś
> > CTO at Empirica S.A.
> > +48 695 616181
> >
>
>
> --
> *Patrique Legault*
>
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Patrique Legault <pa...@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 <da...@empirica.io.invalid>
wrote:
> Hi,
>
> It looks like some kind of backward incompatible change introduced within
> patch version change. I personally would like to keep auto refresh "on" by
> default as this is expected/desired behavior for me.
>
> Regards
>
> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
>
> > Hi everyone,
> >
> > We got several user feedback, complaining about unexpected and cascaded
> > (unrelated) refresh while installing features.
> >
> > As reminder, a refresh can happen when:
> > - bundle A imports package foo:1 and a bundle provides newer foo package
> > version. In that case, the features service will refresh A to use the
> > newest package version.
> > - bundle A has an optional import to package foo and a bundle provides
> > this package. In that case, the features service will refresh A to
> actually
> > use the import as it’s a "resolved" optional.
> > - bundle A is wired to bundle B (from a package perspective or
> > requirement) and B is refreshed. In that case, the features service will
> > refresh A as B is itself refreshed (for the previous reasons for
> instance).
> > This can cause "cascading" refresh.
> >
> > A refresh means that a bundle can be restarted (if the bundle contains an
> > activator or similar (DS component, blueprint bundle)).
> >
> > In this PR https://github.com/apache/karaf/pull/1287, I propose to
> > introduce a new property autoRefresh in etc/org.apache.karaf.features.cfg
> > to disable the auto refresh by the features service (and let the user
> > decides when he wants to trigger refresh with bundle:refresh command for
> > instance).
> > I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on
> > 4.3.x.
> >
> > Thoughts ?
> >
> > On the other hand (and to prepare the "path" to Karaf5), I have created a
> > new "simple features service" (PR will be open soon) that:
> >
> > - just take the features definition in order (ignoring start level)
> > - ignore requirement/capability (no resolver)
> > - no auto refresh
> >
> > Basically, if you have the following feature definition:
> >
> > <feature name="foo" version="1.0">
> > <feature>bar</feature>
> > <bundle>A</bundle>
> > <bundle>B</bundle>
> > </feature>
> >
> > The features service will fully install/start bar feature first, then
> > bundle A, then bundle B.
> > To use this "simple features services, you just have to replace
> > org.apache.karaf.features.core by org.apache.karaf.features.simple bundle
> > in etc/startup.properties (or custom distribution).
> >
> > It’s similar to the Karaf 5 extension behavior (I will share complete
> > details about Karaf 5 and its concepts (module, extension, …) very soon,
> > but that’s another thread ;)).
> >
> > The big advantages of this approach is:
> > - predictable/deterministic provisioning (if it works fine, it works
> again)
> > - faster deployment (I estimated the gain to about 70%)
> >
> > Thoughts ?
> >
> > If you agree, I will move forward on both tasks.
> >
> > Thanks,
> > Regards
> > JB
> >
>
>
> --
> Daniel Łaś
> CTO at Empirica S.A.
> +48 695 616181
>
--
*Patrique Legault*
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
You mean including Karaf 4.3.x or just 4.2.x ?
> Le 8 janv. 2021 à 08:16, Daniel Las <da...@empirica.io> a écrit :
>
> Hi,
>
> It looks like some kind of backward incompatible change introduced within patch version change. I personally would like to keep auto refresh "on" by default as this is expected/desired behavior for me.
>
> Regards
>
> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> napisał(a):
> Hi everyone,
>
> We got several user feedback, complaining about unexpected and cascaded (unrelated) refresh while installing features.
>
> As reminder, a refresh can happen when:
> - bundle A imports package foo:1 and a bundle provides newer foo package version. In that case, the features service will refresh A to use the newest package version.
> - bundle A has an optional import to package foo and a bundle provides this package. In that case, the features service will refresh A to actually use the import as it’s a "resolved" optional.
> - bundle A is wired to bundle B (from a package perspective or requirement) and B is refreshed. In that case, the features service will refresh A as B is itself refreshed (for the previous reasons for instance). This can cause "cascading" refresh.
>
> A refresh means that a bundle can be restarted (if the bundle contains an activator or similar (DS component, blueprint bundle)).
>
> In this PR https://github.com/apache/karaf/pull/1287 <https://github.com/apache/karaf/pull/1287>, I propose to introduce a new property autoRefresh in etc/org.apache.karaf.features.cfg to disable the auto refresh by the features service (and let the user decides when he wants to trigger refresh with bundle:refresh command for instance).
> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on 4.3.x.
>
> Thoughts ?
>
> On the other hand (and to prepare the "path" to Karaf5), I have created a new "simple features service" (PR will be open soon) that:
>
> - just take the features definition in order (ignoring start level)
> - ignore requirement/capability (no resolver)
> - no auto refresh
>
> Basically, if you have the following feature definition:
>
> <feature name="foo" version="1.0">
> <feature>bar</feature>
> <bundle>A</bundle>
> <bundle>B</bundle>
> </feature>
>
> The features service will fully install/start bar feature first, then bundle A, then bundle B.
> To use this "simple features services, you just have to replace org.apache.karaf.features.core by org.apache.karaf.features.simple bundle in etc/startup.properties (or custom distribution).
>
> It’s similar to the Karaf 5 extension behavior (I will share complete details about Karaf 5 and its concepts (module, extension, …) very soon, but that’s another thread ;)).
>
> The big advantages of this approach is:
> - predictable/deterministic provisioning (if it works fine, it works again)
> - faster deployment (I estimated the gain to about 70%)
>
> Thoughts ?
>
> If you agree, I will move forward on both tasks.
>
> Thanks,
> Regards
> JB
>
>
> --
> Daniel Łaś
> CTO at Empirica S.A.
> +48 695 616181
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <da...@empirica.io> a écrit :
>
> Hi,
>
> It looks like some kind of backward incompatible change introduced within patch version change. I personally would like to keep auto refresh "on" by default as this is expected/desired behavior for me.
>
> Regards
>
> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> napisał(a):
> Hi everyone,
>
> We got several user feedback, complaining about unexpected and cascaded (unrelated) refresh while installing features.
>
> As reminder, a refresh can happen when:
> - bundle A imports package foo:1 and a bundle provides newer foo package version. In that case, the features service will refresh A to use the newest package version.
> - bundle A has an optional import to package foo and a bundle provides this package. In that case, the features service will refresh A to actually use the import as it’s a "resolved" optional.
> - bundle A is wired to bundle B (from a package perspective or requirement) and B is refreshed. In that case, the features service will refresh A as B is itself refreshed (for the previous reasons for instance). This can cause "cascading" refresh.
>
> A refresh means that a bundle can be restarted (if the bundle contains an activator or similar (DS component, blueprint bundle)).
>
> In this PR https://github.com/apache/karaf/pull/1287 <https://github.com/apache/karaf/pull/1287>, I propose to introduce a new property autoRefresh in etc/org.apache.karaf.features.cfg to disable the auto refresh by the features service (and let the user decides when he wants to trigger refresh with bundle:refresh command for instance).
> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on 4.3.x.
>
> Thoughts ?
>
> On the other hand (and to prepare the "path" to Karaf5), I have created a new "simple features service" (PR will be open soon) that:
>
> - just take the features definition in order (ignoring start level)
> - ignore requirement/capability (no resolver)
> - no auto refresh
>
> Basically, if you have the following feature definition:
>
> <feature name="foo" version="1.0">
> <feature>bar</feature>
> <bundle>A</bundle>
> <bundle>B</bundle>
> </feature>
>
> The features service will fully install/start bar feature first, then bundle A, then bundle B.
> To use this "simple features services, you just have to replace org.apache.karaf.features.core by org.apache.karaf.features.simple bundle in etc/startup.properties (or custom distribution).
>
> It’s similar to the Karaf 5 extension behavior (I will share complete details about Karaf 5 and its concepts (module, extension, …) very soon, but that’s another thread ;)).
>
> The big advantages of this approach is:
> - predictable/deterministic provisioning (if it works fine, it works again)
> - faster deployment (I estimated the gain to about 70%)
>
> Thoughts ?
>
> If you agree, I will move forward on both tasks.
>
> Thanks,
> Regards
> JB
>
>
> --
> Daniel Łaś
> CTO at Empirica S.A.
> +48 695 616181
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Daniel Las <da...@empirica.io>.
Hi,
It looks like some kind of backward incompatible change introduced within
patch version change. I personally would like to keep auto refresh "on" by
default as this is expected/desired behavior for me.
Regards
pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
> Hi everyone,
>
> We got several user feedback, complaining about unexpected and cascaded
> (unrelated) refresh while installing features.
>
> As reminder, a refresh can happen when:
> - bundle A imports package foo:1 and a bundle provides newer foo package
> version. In that case, the features service will refresh A to use the
> newest package version.
> - bundle A has an optional import to package foo and a bundle provides
> this package. In that case, the features service will refresh A to actually
> use the import as it’s a "resolved" optional.
> - bundle A is wired to bundle B (from a package perspective or
> requirement) and B is refreshed. In that case, the features service will
> refresh A as B is itself refreshed (for the previous reasons for instance).
> This can cause "cascading" refresh.
>
> A refresh means that a bundle can be restarted (if the bundle contains an
> activator or similar (DS component, blueprint bundle)).
>
> In this PR https://github.com/apache/karaf/pull/1287, I propose to
> introduce a new property autoRefresh in etc/org.apache.karaf.features.cfg
> to disable the auto refresh by the features service (and let the user
> decides when he wants to trigger refresh with bundle:refresh command for
> instance).
> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on
> 4.3.x.
>
> Thoughts ?
>
> On the other hand (and to prepare the "path" to Karaf5), I have created a
> new "simple features service" (PR will be open soon) that:
>
> - just take the features definition in order (ignoring start level)
> - ignore requirement/capability (no resolver)
> - no auto refresh
>
> Basically, if you have the following feature definition:
>
> <feature name="foo" version="1.0">
> <feature>bar</feature>
> <bundle>A</bundle>
> <bundle>B</bundle>
> </feature>
>
> The features service will fully install/start bar feature first, then
> bundle A, then bundle B.
> To use this "simple features services, you just have to replace
> org.apache.karaf.features.core by org.apache.karaf.features.simple bundle
> in etc/startup.properties (or custom distribution).
>
> It’s similar to the Karaf 5 extension behavior (I will share complete
> details about Karaf 5 and its concepts (module, extension, …) very soon,
> but that’s another thread ;)).
>
> The big advantages of this approach is:
> - predictable/deterministic provisioning (if it works fine, it works again)
> - faster deployment (I estimated the gain to about 70%)
>
> Thoughts ?
>
> If you agree, I will move forward on both tasks.
>
> Thanks,
> Regards
> JB
>
--
Daniel Łaś
CTO at Empirica S.A.
+48 695 616181
Re: [PROPOSAL] Disable autoRefresh on features service by default and
simple optional features service
Posted by Daniel Las <da...@empirica.io.INVALID>.
Hi,
It looks like some kind of backward incompatible change introduced within
patch version change. I personally would like to keep auto refresh "on" by
default as this is expected/desired behavior for me.
Regards
pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <jb...@nanthrax.net> napisał(a):
> Hi everyone,
>
> We got several user feedback, complaining about unexpected and cascaded
> (unrelated) refresh while installing features.
>
> As reminder, a refresh can happen when:
> - bundle A imports package foo:1 and a bundle provides newer foo package
> version. In that case, the features service will refresh A to use the
> newest package version.
> - bundle A has an optional import to package foo and a bundle provides
> this package. In that case, the features service will refresh A to actually
> use the import as it’s a "resolved" optional.
> - bundle A is wired to bundle B (from a package perspective or
> requirement) and B is refreshed. In that case, the features service will
> refresh A as B is itself refreshed (for the previous reasons for instance).
> This can cause "cascading" refresh.
>
> A refresh means that a bundle can be restarted (if the bundle contains an
> activator or similar (DS component, blueprint bundle)).
>
> In this PR https://github.com/apache/karaf/pull/1287, I propose to
> introduce a new property autoRefresh in etc/org.apache.karaf.features.cfg
> to disable the auto refresh by the features service (and let the user
> decides when he wants to trigger refresh with bundle:refresh command for
> instance).
> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false on
> 4.3.x.
>
> Thoughts ?
>
> On the other hand (and to prepare the "path" to Karaf5), I have created a
> new "simple features service" (PR will be open soon) that:
>
> - just take the features definition in order (ignoring start level)
> - ignore requirement/capability (no resolver)
> - no auto refresh
>
> Basically, if you have the following feature definition:
>
> <feature name="foo" version="1.0">
> <feature>bar</feature>
> <bundle>A</bundle>
> <bundle>B</bundle>
> </feature>
>
> The features service will fully install/start bar feature first, then
> bundle A, then bundle B.
> To use this "simple features services, you just have to replace
> org.apache.karaf.features.core by org.apache.karaf.features.simple bundle
> in etc/startup.properties (or custom distribution).
>
> It’s similar to the Karaf 5 extension behavior (I will share complete
> details about Karaf 5 and its concepts (module, extension, …) very soon,
> but that’s another thread ;)).
>
> The big advantages of this approach is:
> - predictable/deterministic provisioning (if it works fine, it works again)
> - faster deployment (I estimated the gain to about 70%)
>
> Thoughts ?
>
> If you agree, I will move forward on both tasks.
>
> Thanks,
> Regards
> JB
>
--
Daniel Łaś
CTO at Empirica S.A.
+48 695 616181