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.grzy...@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 > <gno...@apache.org <mailto:gno...@apache.org>> ) or splitting > pax-logging-log4j2 into a bundle + > fragment (done by JBO). In Fuse we were carefully influencing > etc/startup.properties and rewriting many features to be more consistent > and less vulnerable to unnecessary refreshes. > > But summarizing, I'd keep autoRefresh=true in all the scenarios, where > Karaf is used as "application server" and switch it to autoRefresh=false in > µservices / custom distro / single start mode. And looking forward Karaf 5 > and new feature mechanism, I'd rather turn autoRefresh off in Karaf 5... > > regards > Grzegorz Grzybek > > pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre <j...@nanthrax.net > <mailto:j...@nanthrax.net>> napisał(a): > >> Hi everyone, >> >> We got several user feedback, complaining about unexpected and cascaded >> (unrelated) refresh while installing features. >> >> As reminder, a refresh can happen when: >> - bundle A imports package foo:1 and a bundle provides newer foo package >> version. In that case, the features service will refresh A to use the >> newest package version. >> - bundle A has an optional import to package foo and a bundle provides >> this package. In that case, the features service will refresh A to actually >> use the import as it’s a "resolved" optional. >> - bundle A is wired to bundle B (from a package perspective or >> requirement) and B is refreshed. In that case, the features service will >> refresh A as B is itself refreshed (for the previous reasons for instance). >> This can cause "cascading" refresh. >> >> A refresh means that a bundle can be restarted (if the bundle contains an >> activator or similar (DS component, blueprint bundle)). >> >> In this PR https://github.com/apache/karaf/pull/1287 < >> 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
