Bug 337228

Comment 1 Thomas Watson 2011-02-15 11:26:54 EST

investigate for M6.

Comment 2 Thomas Watson 2011-02-15 15:06:56 EST

I reproduced the issue.  It is only reproduced if you never cause the composite bundle to resolve.  Causing the composite to resolve by using PackageAdmin.resolveBundles or starting the composite will force it to resolve.  On restart if the composite bundle is resolved then the composite bundle will be initialized properly.

Comment 3 Thomas Watson 2011-02-15 15:19:36 EST

My previous comment was incorrect.  The composite has to be persistently started.  Simply having it resolved is not good enough.

Comment 4 Alasdair Nottingham 2011-02-15 15:22:26 EST

(In reply to comment #3)
> My previous comment was incorrect.  The composite has to be persistently
> started.  Simply having it resolved is not good enough.

My CompositeBundle reaches ACTIVE state prior to the restart. We appear to call start(Bundle.START_ACTIVATION_POLICY). Is this a persistent start?

Comment 5 Thomas Watson 2011-02-15 15:33:21 EST

Created attachment 189042 [details]
patch

Here is a simple fix that ensures the composite framework is initialized on restart no matter what the state of the CompositeBundle is in.  The drawback to this is that all composite frameworks will now need to be aggressively initialized which may be a hit on performance.

Comment 6 Thomas Watson 2011-02-15 15:35:27 EST

A possible workaround is to always call CompositeBundle.getCompositeFramework().init() before getting the context.  Calling init() on an already initialized framework should be a no-op.

Comment 7 Thomas Watson 2011-02-17 15:06:50 EST

Given the fact that CompositeBundle is dead, there is a workaround, and I am unsure of the impacts of early initialization of the child frameworks: I think the best thing to do here is nothing.

Comment 8 Alasdair Nottingham 2011-02-18 05:49:40 EST

(In reply to comment #6)
> A possible workaround is to always call
> CompositeBundle.getCompositeFramework().init() before getting the context. 
> Calling init() on an already initialized framework should be a no-op.

This is a hugely invasive change to make and is likely to be very error prone

Comment 9 Thomas Watson 2011-02-21 14:04:22 EST

(In reply to comment #8)
> (In reply to comment #6)
> > A possible workaround is to always call
> > CompositeBundle.getCompositeFramework().init() before getting the context. 
> > Calling init() on an already initialized framework should be a no-op.
> 
> This is a hugely invasive change to make and is likely to be very error prone

I am wondering if this is an inflated claim.  I hope you don't have 100s of lines of code that all call CompositeBundle.getCompositeFramework().getBundleContext() I was really hoping it was a very isolated piece of code that dealt with the composite framework.

(In reply to comment #4)
> (In reply to comment #3)
> > My previous comment was incorrect.  The composite has to be persistently
> > started.  Simply having it resolved is not good enough.
> 
> My CompositeBundle reaches ACTIVE state prior to the restart. We appear to call
> start(Bundle.START_ACTIVATION_POLICY). Is this a persistent start?

I missed this comment.  Reopening bug to investigate.  Yes this should be persistent.  In my testing if the composite bundle was started after a restart then the composite framework got a valid context.

Comment 10 Thomas Watson 2011-02-21 14:40:19 EST

(In reply to comment #9)
> > My CompositeBundle reaches ACTIVE state prior to the restart. We appear to call
> > start(Bundle.START_ACTIVATION_POLICY). Is this a persistent start?
> 
> I missed this comment.  Reopening bug to investigate.  Yes this should be
> persistent.  In my testing if the composite bundle was started after a restart
> then the composite framework got a valid context.

Is the start-level of your composite bundle higher than the bundle attempting to get the composite framework's bundle context?  If so that explains it because we currently only initialize the composite framework once the composite is activated.

Comment 11 Thomas Watson 2011-02-21 15:52:35 EST

Created attachment 189443 [details]
patch

Alternate patch.  This patch moves the init of the composite to the getCompositeFramework().  This allows for some laziness but it still can be problematic if you get and hold onto the composite Framework object and the composite is persistently stopped.  In this case the Framework object will be stopped and is not re-initialized.

Comment 12 Thomas Watson 2011-02-21 15:54:42 EST

I went ahead with the last patch.  Please test this out.  There are few left that I know are still using composites and testing is limited.