Community
Participate
Working Groups
Build Identifier: 3.5.2 The system bundle is put in ACTIVE state just before the bundles are started, and a FrameworkEvent.STARTED is fired after starting these bundles. According to the OSGi spec, the system bundle should be put in ACTIVE state after the bundles are started - just before firing the event FrameworkEvent.STARTED. The exact code is in the method StartLevelManager.doSetStartLevel(…). There is a comment in the code, that putting the bundle in ACTIVE state “should be done just before firing the STARTED event for the system bundle” but is done earlier, because “some depend on the system bundle being in the ACTIVE state when they are starting”. For us this is a problem, because we are implementing logic which depends on the system bundle being put in ACTIVE state after all bundles, which should be running, are started. In some cases listening for the FrameworkEvent.STARTED can be used, but only if we are sure that we listen for this event when it is fired. If the code, which listens for it, is executed after the framework is started, then it will never get the event. This happens in an Activator of a bundle – it may be executed during the initial start of the framework, or after the framework is started (for example on the first start of the bundle after installing it). Therefore we need to be able to check the framework state in one and the same way in both cases. Reproducible: Always
Created attachment 164939 [details] Proposition for a patch for the problem. A proposed patch for the problem - it moves the code for putting the system bundle in ACTIVE state just before the code for firing FrameworkEvent.STARTED.
I found a case where some code was making the invalid assumption that the system bundle is in the ACTIVE state while setting the beginning start-level. See bug 309374. I worry that there may be others. But that one at least needs to be fixed before this patch can be released.
(In reply to comment #0) > For us this is a problem, because we are implementing logic which depends on > the system bundle being put in ACTIVE state after all bundles, which should be > running, are started. In some cases listening for the FrameworkEvent.STARTED > can be used, but only if we are sure that we listen for this event when it is > fired. If the code, which listens for it, is executed after the framework is > started, then it will never get the event. This happens in an Activator of a > bundle – it may be executed during the initial start of the framework, or after > the framework is started (for example on the first start of the bundle after > installing it). Therefore we need to be able to check the framework state in > one and the same way in both cases. > I am not arguing against the change to Equinox to set the system bundle state to ACTIVE after incrementing the start-level to the beginning start-level and just before firing the BundleEvent.STARTED and FrameworkEvent.STARTED for the system bundle. But the assumption above still has some timing issues that need to be handled carefully. In order to make this work correctly (after applying the attached framework patch) you must make sure you add your FrameworkListener (listening for FrameworkEvent.STARTED) before checking the state of the system bundle. If you only add your FrameworkListener after checking (systemBundle.getState() == STARTING) then you will have a small window where the system bundle state could change to ACTIVE and the event FrameworkEvent.STARTED could get fired before you add your listener and you will miss the event. Something like the following is needed: myContext.addFrameworkListener(myListener); if (systemBundle.getState() != Bundle.STARTING) myContext.removeFrameworkListener(myListener);
(In reply to comment #3) > I am not arguing against the change to Equinox to set the system bundle state > to ACTIVE after incrementing the start-level to the beginning start-level and > just before firing the BundleEvent.STARTED and FrameworkEvent.STARTED for the > system bundle. But the assumption above still has some timing issues that need > to be handled carefully. > > In order to make this work correctly (after applying the attached framework > patch) you must make sure you add your FrameworkListener (listening for > FrameworkEvent.STARTED) before checking the state of the system bundle. If you > only add your FrameworkListener after checking (systemBundle.getState() == > STARTING) then you will have a small window where the system bundle state could > change to ACTIVE and the event FrameworkEvent.STARTED could get fired before > you add your listener and you will miss the event. Something like the > following is needed: > > myContext.addFrameworkListener(myListener); > if (systemBundle.getState() != Bundle.STARTING) > myContext.removeFrameworkListener(myListener); Thanks for the patch for bug 309374. As for the timing issue, you are absolutely right in general. But in our particular use case if we can count on a correct state of the system bundle, it will be enough to check the state when starting and we will not have to register a listener for the FrameworkEvent.STARTED at all.
Patch released. Thanks Lazar!
Comment on attachment 164939 [details] Proposition for a patch for the problem. Marking for iplog.
