[
https://issues.apache.org/jira/browse/ARIES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861848#action_12861848
]
Holly Cummins commented on ARIES-272:
-------------------------------------
Hi Lin,
You're quite right - I was able to reproduce that failure. I had been building
against a local branch which had that test disabled (not by me!), which is why
I'd never noticed the problem.
The reason for the failure is that the test is testing what happens if the test
bundle is installed before blueprint gets started. Previously, we'd recurse on
any pre-existing ACTIVE bundles, but in the first patch, I'd changed that so we
only recursed on pre-existing INSTALLED or STARTING bundles and miss the ones
which had got all the way through the lifecycle. I've now made it so that it
recurses on any remotely-alive pre-existing bundles:
if (cb.getState() == Bundle.INSTALLED || cb.getState() ==
Bundle.RESOLVED || cb.getState() == Bundle.STARTING || cb.getState() ==
Bundle.ACTIVE) {
In the course of working out the problem, I also noticed that my patch was a
bit incomplete - half of the changes to PersistenceBundleManager had escaped
making it into the patch.
I've had tests run clean against revision 936235. I did have an intermittent
failure in FrameworkMBeanTest and ServiceStateMBeanTest but I saw similar
failures on a fresh checkout. I've attached a revised patch with the
corrections (and the missing files from the first patch.)
> 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.
-
You can reply to this email to add a comment to the issue online.
