Hi Stephen,
I think there's two questions:
1. Why does a refresh happen ?
A refresh can happen for instance when an optional import is resolved (when
installing a feature or a bundle) or when a new package version is installed
matching a version range.
So, especially in the case of optional import, you should check the import of
your bundle.
2. Why does your bundle not able to refresh ?
That's probably the most important. Maybe, you keep the bundle context as member
of a class and so it becomes invalid after the refresh.
Before dealing with dependency or prerequisite, I would start to address those
points.
The dependency flag is not a "complete" inner feature, so it's normal that the
feature is not installed if another one already provides the corresponding
capabilities.
Regards
JB
On 06/13/2017 10:35 AM, Stephen Kitt wrote:
Hi,
As we continue to try to migrate OpenDaylight to Karaf 4, it’s become
very clear that we need to understand exactly what feature dependencies
entail. (And yes, I’ll submit documentation patches once we’ve done
so.)
OpenDaylight (ODL) defines lots and lots of features, some of which
contain bundles which survive refreshes, many of which don’t. In
real-world deployments, the Karaf distributions which are built tend to
use boot features to start the features they’re interested in. We make
extensive use of feature dependencies of course, e.g.
<feature name='odl-ttp-model-rest' version='${project.version}'>
<feature version='${project.version}'>odl-ttp-model</feature>
<feature version='${restconf.version}'>odl-mdsal-apidocs</feature>
<feature version='${restconf.version}'>odl-restconf</feature>
<feature version='${controller.version}'>odl-mdsal-broker</feature>
</feature>
In Karaf 3 all this works fine.
In Karaf 4 we’re having lots of issues related to bundle refreshes, so
we’ve been trying to figure out how to avoid them. Of course,
“feature:install --no-auto-refresh” works, but that’s not ideal (at
least, I don’t think it is). We thought perhaps using the dependency or
prerequisite attributes might help.
As we understand things (and this is the main point I would like to
clarify), in Karaf 4, based on the feature declaration above:
* (re)starting odl-ttp-model-rest would restart odl-ttp-model,
odl-mdsal-apidocs etc. (which is a problem because e.g.
odl-mdsal-broker is very likely to already be running when we install
another feature)
* adding “dependency="true"” would disable this
* adding “prerequisite="true"” would also disable this, and ensure that
the corresponding feature is started before odl-ttp-model-rest
We hoped the second option would solve our problems, but in our
experimentation it seems that declaring features in this way means they
aren’t necessarily installed. (I’m hoping I can still dig up examples.)
As in,
<feature name="a">
<feature name="b" dependency="true"/>
</feature>
results in a distribution where
feature:install a
doesn’t necessarily install b. Is that supposed to be the case?
We also thought that declaring prerequisites would work too, especially
since our feature dependencies are acyclic and so it is actually
possible to initialise all our features in a given order. But when we
tried this we ran into stack overflows. (I’ll do it again and file
bugs.)
Does this make any sense at all?
Regards,
Stephen
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
