Lets assume you start the Equinox instances with your own launcher using the Framework launch API. After that code launches the framework, it parks a thread on Framework.waitForStop. Then when your servlet calls stop on the system bundle, once the framework has indeed stopped, the thread parked on waitForStop will awaken and can then tidily end the VM's life perhaps including System.exit. (This is all standard OSGi and requires no Equinox specifics.) --
BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: <daniel.stu...@empolis.com> To: <equinox-dev@eclipse.org> Date: 2010/03/12 12:15 Subject: AW: [equinox-dev] Question on programatic close of the runtime Sent by: equinox-dev-boun...@eclipse.org Hi all, our application (BTW: we are talking about SMILA) is a backend server, with instances running on a cluster. What do you suggest to remotely shutdown the OSGi instances on each cluster node? We cannot expect an administrator to log on every machine and to exit the OSGI console by typing "close". Therefore I had the idea to provide this functionality via HTTP. So it's an external call that stops bundle zero and after a configurable timeout calls System.exit() (hopefully giving the runtime enough time to savely stop all bundles). So the System.exit() is done on purpose by an administrator. One way of connecting remotely would be to use telnet and then send a close command to the OSGi console. But this is cumbersome. Is this "safer" than my approach as after Framework.close() this does also call System.exit() ? Bye, Daniel -----Ursprüngliche Nachricht----- Von: equinox-dev-boun...@eclipse.org [ mailto:equinox-dev-boun...@eclipse.org] Im Auftrag von Neil Bartlett Gesendet: Freitag, 12. März 2010 17:54 An: Equinox development mailing list Betreff: Re: [equinox-dev] Question on programatic close of the runtime 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 <tdiek...@tibco.com> 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, <daniel.stu...@empolis.com> 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 >>> equinox-dev@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/equinox-dev >>> >>> >> _______________________________________________ >> equinox-dev mailing list >> equinox-dev@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/equinox-dev > > _______________________________________________ > equinox-dev mailing list > equinox-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
