[
https://issues.apache.org/jira/browse/ARIES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852397#action_12852397
]
Holly Cummins commented on ARIES-272:
-------------------------------------
I'm fairly sure using the INSTALLED state to track bundles inside composite
bundles is possible. Whether it's wise or desirable is another question, of
course. I've got a patch which uses INSTALLED instead of STARTING successfully.
It's able to work because the composite bundles get a functional framework as
soon as they're installed. CompositeBundle.getCompositeFramework() allows
access to it. Some care is required in using the framework before the composite
bundle is started; for example, the surrogate bundle is present but not active
until the composite bundle itself is started, so calling getBundleContext() on
the surrogate bundle will fail.
The motivation for the change is that requiring the composite bundle to be
started before any bundles are installed into it is pretty restrictive. For
example, if the composite bundle declares exported packages, it will fail to
start until it can satisfy those exports, and satisfying the exports requires
that the child bundles be installed into the parent. In other words, the child
bundles have to be installed before the parent composite bundle is started (but
after it is installed). Code which needs early access to these bundles would
need to trap INSTALLED instead of STARTING composite bundle events.
> BundleTrackerCustomizers will not recurse on bundles added to a
> CompositeBundle before the composite bundle is started
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: ARIES-272
> URL: https://issues.apache.org/jira/browse/ARIES-272
> Project: Aries
> Issue Type: Improvement
> Reporter: Holly Cummins
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> At the moment the AbstractBundleTrackerCustomizer and its descendents trap
> Bundle.STARTING events. If the originator is a composite bundle they add
> themselves as a tracker to the composite bundle's context so that they are
> notified of bundle events in the child framework. This model assumes that the
> child bundles are added to the composite bundle *after* it is started. It
> would be better to trap Bundle.INSTALLED events, since child bundles can be
> added any time after the composite bundle is installed. For example, if the
> composite bundle has exports, its children have to be added *before* it is
> started so that it can satisfy the exports.
> There is also quite a lot of redunant and duplicate code in the area of the
> bundle tracker customizers which should be cleaned up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
