Hi, Thanks for the clarification.
Am Donnerstag, den 10.02.2011, 14:27 +0000 schrieb Richard S. Hall: > > On 2/10/11 2:02, Felix Meschberger wrote: > > Hi Richard, > > > > This confuses me (and maybe I just don't know enough). > > > > So what you essentially say, is that after Framework.stop(), the system > > bundle is essentially in the RESOLVED state just like after an initial > > Framework.init() call ? Thus a call to init() after stop() processing > > completed has no effect ? > > > > This seems to be kind contradictory to the Framework.stop() > > documentation, which includes: > > > >> After being stopped, this Framework may be discarded, initialized or > >> started. > > It does not contradict the documentation, consider 4.2.3 which states: > > stop – Move the framework into the RESOLVED state via the STOPPING > state. This will return a Framework STOPPED event from the > waitForStop method. The Framework's Bundle Context is no longer > valid. The framework must be initialized again to get a new, valid > BundleContext. The stop method can be called on the framework or on > the system bundle. > > So, this is what I am saying. Stopping the framework does NOT move it > back to the INSTALLED state, it moves it back to the RESOLVED state. > > > Here is why I am asking: In Sling we do the following for an initial > > startup : > > > > * Create Framework instance > > * call Framework.init() > > * install a bunch of bundles > > * check whether one of the bundles is a framework extension bundle > > * if so: > > - call Framework.stop() > > - call Framework.init() (once stop completed) > > I believe with the currently released framework, this could lead to NPEs > as described in the issue. Although, if you are not ever seeing them, I > am not sure why. Also note that you should not need to stop the > framework unless you are updating a framework extension bundle. > Installing a framework extension bundle should take effect immediately. This makes my case simpler because I can just install/update and continue... But take some more care for updates. Regards Felix > > > * otherwise: > > - continue with next step > > * start the framework with Framework.start() > > > > The idea of calling stop()-init() is to make sure the system bundle can > > have the newly installed system extension fragments attached. > > > > From your comment I would assume, this to not be possible and I would > > have to create a new Framework instance for that ? Would not be a big > > deal, but I would need to know ;-) > > I'll let Karl comment on the specifics here, since he implemented this > part. However, system bundle fragments are handled differently than > normal bundles. When you stop the framework, all bundles should be > refreshed if needed (i.e., if you updated any). When you restart, all > bundles are reinstalled including framework extensions, which should be > available immediately. Still, if you've loaded classes from previously > attached framework extensions, these classes cannot go away until you > completely throw away the class loader that loaded the framework, if I > understand correctly. > > Karl? > > In short, though, nothing I've done will prevent you from stopping a > framework and restarting it...or at least it shouldn't. > > -> richard > > > Regards > > Felix > > > > > > > > Am Mittwoch, den 09.02.2011, 22:51 +0000 schrieb Richard S. Hall > > (JIRA): > >> [ > >> https://issues.apache.org/jira/browse/FELIX-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > >> ] > >> > >> Richard S. Hall closed FELIX-2822. > >> ---------------------------------- > >> > >> Resolution: Fixed > >> > >> After thinking about it, I realize that the system bundle should be > >> handled differently than other bundles when the framework is stopped. > >> Normal bundles are unresolved and effectively discarded. The system bundle > >> was being treated the same way, but this was causing a problem since the > >> framework instance can be reused. > >> > >> To avoid this situation, since Felix extends BundleImpl, I just overrode > >> BundleImpl.close() to do nothing. Thus, when the framework stops all > >> bundles except the system bundle are thrown away. This means that once the > >> framework is started, the system bundle continues to exist and stays in > >> the RESOLVED state forever, even after the framework stops. > >> > >> This makes sense, because if you reuse the framework instance then the > >> system bundle doesn't need to be resolved again since it configuration > >> cannot change from one run to the next. > >> > >>> [Framework] System bundle module's state not reset when framework > >>> restarted leading to NPE > >>> ------------------------------------------------------------------------------------------ > >>> > >>> Key: FELIX-2822 > >>> URL: https://issues.apache.org/jira/browse/FELIX-2822 > >>> Project: Felix > >>> Issue Type: Bug > >>> Components: Framework > >>> Affects Versions: framework-3.0.8 > >>> Reporter: Richard S. Hall > >>> Assignee: Richard S. Hall > >>> Priority: Minor > >>> Fix For: framework-3.2.0 > >>> > >>> > >>> Normally when a bundle is refreshed, we throw away its module and then > >>> recreate it, so we are always starting with a fresh module. For the > >>> system bundle, when we stop and restart the framework, the system bundle > >>> module is reused. When the framework is restarted, the system bundle > >>> module state is still resolved, so when we re-resolve it in > >>> Framework.init(), it doesn't get empty wires injected into it since the > >>> resolver thinks it's resolved. This leads to subsequent NPEs when the > >>> resolver tries to wire later modules to the system bundle. > >
