[
https://issues.apache.org/jira/browse/ARIES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857407#action_12857407
]
Holly Cummins commented on ARIES-272:
-------------------------------------
Hi Lin,
That's certainly what I observed in my testing. I had to think about it a bit
to be sure I understood what was going on, but I concluded the logic is that
applications may be installed into the composite bundle as soon as it's
installed itself. Therefore the composite bundle must have a valid framework
into which these bundles can be installed. For that reason, the framework can
return a bundle context. There is a method to start the framework of the
composite bundle before starting the whole composite framework, and my
suspicion is that this gets invoked as soon as the bundle is installed.
However, there are other limitations to what can be done with a composite
bundle which is only INSTALLED. For example, the surrogate bundle in the the
composite framework won't be started and won't have access to the composite
bundle context. In general playing around with the composite bundles when
they're only INSTALLED is more fragile than waiting until they hit STARTING.
I'm also not sure how dependent this behaviour of starting the framework on
install is on the current version of equinox. It may be we'd want to control
whether we recursed on INSTALLED or STARTING with some sort of global property
so that we can switch back and forth between the more robust mode and the less
robust mode which supports the use case of being able to both trap bundle
INSTALLED events and support composite bundles with exports. Would it be useful
if I added that kind of switch to the InternalRecursiveBundleTracker?
> 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
> Attachments: aries272.patch, InternalRecursiveBundleTracker.java
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
