Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: aries-dev@incubator.apache.org
Message-ID: <5744474.140811271340410531.JavaMail.jira@thor>
Date: Thu, 15 Apr 2010 10:06:50 -0400 (EDT)
From: "Holly Cummins (JIRA)" <jira@apache.org>
To: aries-dev@incubator.apache.org
Subject: [jira] Updated: (ARIES-272) BundleTrackerCustomizers will not
 recurse on bundles added to a CompositeBundle before the composite bundle
 is started
In-Reply-To: <151886202.617871270074147323.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/ARIES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Holly Cummins updated ARIES-272:
--------------------------------

    Attachment: InternalRecursiveBundleTracker.java

Hi Lin, 

You're quite right, it's missing. Sorry about that. It must have escaped my best attempts with svn add, move, and delete. It's pretty similar to the previous InternalBundleTracker which was an inner class in MultiBundleTracker. The RecursiveBundleTracker logic which is that it uses the presence of a service to decide if the CompositeBundle API is likely to be available, and only delegates to the recursing path if the API is available.

> 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