Community
Participate
Working Groups
Build Identifier: org.eclipse.osgi_3.7.0.v20101022.jar When you create a CompositeBundle the bundle enters RESOLVED state. There is also a framework inside the CompositeBundle and this framework starts off in the INSTALLED state. This can be started. Once started, or initialized, the framework has a BundleContext. If you restart the framework you would usually expect the framework in the CompositeBundle to be in the state it was when the parent framework was shutdown. Instead the framework reverts to the INSTALLED state. I suspect the state of the child framework is not cached. Reproducible: Always Steps to Reproduce: 1.Create CompositeBundle 2.Start CompositeBundle 3.Restart the framework 4.Attempt to get the composite bundle frameworks BundleContext.
investigate for M6.
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.
My previous comment was incorrect. The composite has to be persistently started. Simply having it resolved is not good enough.
(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?
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.
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.
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.
(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
(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.
(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.
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.
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.
