aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Holly Cummins (JIRA)" <>
Subject [jira] Commented: (ARIES-272) BundleTrackerCustomizers will not recurse on bundles added to a CompositeBundle before the composite bundle is started
Date Wed, 28 Apr 2010 17:23:48 GMT


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:
>             Project: Aries
>          Issue Type: Improvement
>            Reporter: Holly Cummins
>         Attachments: aries272.patch,
>   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.

View raw message