You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "Holly Cummins (JIRA)" <ji...@apache.org> on 2010/04/01 00:22:27 UTC
[jira] Created: (ARIES-272) BundleTrackerCustomizers will not
recurse on bundles added to a CompositeBundle before the composite bundle
is started
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
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.
[jira] Updated: (ARIES-272) BundleTrackerCustomizers will not
recurse on bundles added to a CompositeBundle before the composite bundle
is started
Posted by "Holly Cummins (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Holly Cummins updated ARIES-272:
--------------------------------
Attachment: aries272.patch
Hi Lin, that's exactly right about the STARTED and INSTALLED events. It's sometimes necessary to trap the bundle's INSTALLED and RESOLVED events in order to do things like manipulating a bundle's meta information.
I've attached my patch. I was hoping to run it through the itests on a clean checkout but in the end I didn't because the builds aren't really building so well at the moment. :) However, I've tested it locally and it all works as expected. It does two things. The first is to tidy up the bundle tracking mechanisms and eliminate redundant code. I've consolidated the bundle trackers so that they all share the same strategy for tracking bundles recursively. I've also changed the level we trigger the recursion at so that it's INSTALLED instead of STARTING.
For reasons I don't fully understand my patch just empties out the files I've deleted using 'svn delete' instead of removing them, but the intent should be clear. :)
> 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
>
> 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
[jira] Updated: (ARIES-272) BundleTrackerCustomizers will not
recurse on bundles added to a CompositeBundle before the composite bundle
is started
Posted by "Holly Cummins (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Holly Cummins updated ARIES-272:
--------------------------------
Comment: was deleted
(was: 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-revised.patch, 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.
[jira] Updated: (ARIES-272) BundleTrackerCustomizers will not
recurse on bundles added to a CompositeBundle before the composite bundle
is started
Posted by "Holly Cummins (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Holly Cummins updated ARIES-272:
--------------------------------
Attachment: aries272-revised.patch
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-revised.patch, 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.
[jira] Commented: (ARIES-272) BundleTrackerCustomizers will not
recurse on bundles added to a CompositeBundle before the composite bundle
is started
Posted by "Lin Sun (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857531#action_12857531 ]
Lin Sun commented on ARIES-272:
-------------------------------
Hi Holly
Thanks. I tried to apply your patch, but when I ran the blueprint itest, one test has consistently failed.
Running org.apache.aries.blueprint.itests.BlueprintContainer2BTCustomizerTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 10.587 sec <<< FAILURE!
Can you please try it now that trunk is build-able?
Thx
Lin
> 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
[jira] Commented: (ARIES-272) BundleTrackerCustomizers will not
recurse on bundles added to a CompositeBundle before the composite bundle
is started
Posted by "Timothy Ward (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852193#action_12852193 ]
Timothy Ward commented on ARIES-272:
------------------------------------
I agree that the BundleTrackerCustomizer code is complicated and could probably be improved, but I'm not sure that what you're suggesting is possible.
The Composite aware bundle tracker needs access to the BundleContext of the System bundle inside the Composite, this is what we use to track bundles inside the Composite. This BundleContext only exists for bundles in the STARTING, ACTIVE and STOPPING states, which is why we trap the STARTING event to begin tracking.
I am not certain if there is a specified lifecycle for bundles within a composite, but I believe that the current behaviour means bundles in the Composite are only installed once the Composite bundle is STARTED (and has a BundleContext that can be used to install the isolated bundles. In this case the Composite aware Tracker that we already have will provide INSTALLED and RESOLVED events for bundles inside the Composite.
As such I think this item is only a tidy up, and not a feature enhancement
> 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.
[jira] Commented: (ARIES-272) BundleTrackerCustomizers will not
recurse on bundles added to a CompositeBundle before the composite bundle
is started
Posted by "Holly Cummins (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (ARIES-272) BundleTrackerCustomizers will not
recurse on bundles added to a CompositeBundle before the composite bundle
is started
Posted by "Lin Sun (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856970#action_12856970 ]
Lin Sun commented on ARIES-272:
-------------------------------
Hi Holly
Thanks! I have the one comment -
where is the code for InternalRecursiveBundleTracker? I don't see it in the patch
Did I miss the source code for it?
Lin
> 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
>
> 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
[jira] Commented: (ARIES-272) BundleTrackerCustomizers will not
recurse on bundles added to a CompositeBundle before the composite bundle
is started
Posted by "Holly Cummins (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (ARIES-272) BundleTrackerCustomizers will not
recurse on bundles added to a CompositeBundle before the composite bundle
is started
Posted by "Lin Sun (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852458#action_12852458 ]
Lin Sun commented on ARIES-272:
-------------------------------
Hi Holly
I think in your example where the bundles are added to the nested framework before the composite bundle is started, the bundle tracker should still be able to recognize them, whenever their status is changed to STARTING (and I assume the composite bundle has to change to starting first). My guess is that you would see them in addingBundle. You would miss the INSTALLED event but do we really care about it?
Anyway look forward to seeing your patch
Lin
> 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.
[jira] Updated: (ARIES-272) BundleTrackerCustomizers will not
recurse on bundles added to a CompositeBundle before the composite bundle
is started
Posted by "Holly Cummins (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (ARIES-272) BundleTrackerCustomizers will not
recurse on bundles added to a CompositeBundle before the composite bundle
is started
Posted by "Holly Cummins (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (ARIES-272) BundleTrackerCustomizers will not
recurse on bundles added to a CompositeBundle before the composite bundle
is started
Posted by "Lin Sun (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857341#action_12857341 ]
Lin Sun commented on ARIES-272:
-------------------------------
Hi Holly
Thanks for the file. I have only one comment -
In the InternalRecursiveBundleTracker, in customizedProcessBundle line 123, the code calls opentracker when bundle states is installed or starting. In the case of bundle state installed, in line 149, the code has
BundleContext compositeBundleContext = cb.getCompositeFramework().getBundleContext();
Would you be able to get a valid compositeBundleContext here when the composite is installed but not starting or started yet?
Lin
> 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
[jira] Resolved: (ARIES-272) BundleTrackerCustomizers will not
recurse on bundles added to a CompositeBundle before the composite bundle
is started
Posted by "Lin Sun (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lin Sun resolved ARIES-272.
---------------------------
Assignee: Lin Sun
Resolution: Fixed
Patch integrated in rev 941776. Thanks Holly!
> 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
> Assignee: Lin Sun
> Attachments: aries272-revised.patch, 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.