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
|