Neil, no argument here, but on the Equinox development mailing list my assumption is that the framework used is Equinox.
Unless you have created your own launcher (which not many people do I suppose), you may want to know why following the advice did not resolve your problem. At least, this is what I experienced after I asked the very same question in this forum before and got the same response ;-) Tim. "It is a simple task to make things complex, but a complex task to make them simple." -- Fortune Cookie On Mar 12, 2010, at 8:53 AM, Neil Bartlett wrote: > Tim, > > I agree but it's a matter of who is responsible for doing this. The > launcher code that created the framework and started it should be > responsible for shutting down the VM, after calling > Framework.waitForStop(). If a bundle calls System.exit() then it is > assuming too much about the environment in which it is deployed. > > Neil > > On Fri, Mar 12, 2010 at 4:47 PM, Tim Diekmann <[email protected]> wrote: >> Hi, >> >> while calling stop() on the system bundle is the correct and recommended >> approach, it is not always sufficient in production environments. >> >> The framework will only end if the main() method that started it runs out or >> someone calls System.exit(). However, for the main method to end, all >> non-daemon threads have to be ended first. Bundles may have started >> non-daemon threads. If you have started Equinox with the console enabled >> that would be difficult and you continue to have a process lingering around >> and no OSGi framework. >> >> System.exit() is the safest choice to ensure that the process has died. >> >> Keep in mind that on shutdown Equinox is persisting its state and a call to >> System.exit() during that phase may cause cache corruption. >> >> Tim. >> >> "It is a simple task to make things complex, but a complex task to make them >> simple." >> -- Fortune Cookie >> >> On Mar 12, 2010, at 2:34 AM, Neil Bartlett wrote: >> >>> Daniel, >>> >>> Stopping bundle zero is not a hack; this is the normal way to >>> programmatically shutdown OSGi. However: >>> >>> 1) There is no need to check that the bundle is active first. Calling >>> stop() on an already stopped bundle simply has no effect (likewise >>> calling start() on an already active bundle has no effect). >>> >>> 2) There should be no need to wait for the framework to stop and then >>> call System.exit(). Exiting the JVM should be the responsibility of >>> whoever created and started the framework, i.e. the launcher. Calling >>> System.exit() directly from within a bundle will cause big problems if >>> your bundle is deployed to a framework embedded in a larger system, >>> e.g. an application server. >>> >>> In other words, the code could be as simple as this: >>> >>> _componentContext.getBundleContext().getBundle(0).stop(); >>> >>> Regards, >>> Neil >>> >>> On Fri, Mar 12, 2010 at 10:16 AM, <[email protected]> wrote: >>>> Hi all, >>>> >>>> >>>> >>>> I would like to expose the functionality to close the Equinox runtime via >>>> an >>>> HTTP request. Therefore I have implemented a Jetty ContextHandler as an >>>> DeclarativeService. I used the FrameworkCommandProvider as an example on >>>> how >>>> to close the runtime, but I was not able to get access to the Framework >>>> class to call method close() on it. >>>> >>>> >>>> >>>> I came up with a workaround for that, which is basically like this: >>>> >>>> >>>> >>>> Bundle bundle = _componentContext.getBundleContext().getBundle(0); >>>> >>>> if (bundle.getState() == Bundle.ACTIVE) { >>>> >>>> bundle.stop(); >>>> >>>> while (bundle.getState() != Bundle.RESOLVED) { >>>> >>>> // WAIT N milliseconds and REPEAT at most M times >>>> >>>> } >>>> >>>> } >>>> >>>> System.exit(0); >>>> >>>> >>>> >>>> >>>> >>>> This works fine for me, although it seems to be a hack stopping bundle with >>>> Id 0. Are there better ways to achieve my goal ? Are there any ways to get >>>> access to the Framework class ? >>>> >>>> >>>> >>>> >>>> >>>> Bye, >>>> >>>> Daniel >>>> >>>> _______________________________________________ >>>> equinox-dev mailing list >>>> [email protected] >>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev >>>> >>>> >>> _______________________________________________ >>> equinox-dev mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
