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
