Re: [equinox-dev] Question on programatic close of the runtime

[Tim Diekmann <tdiekman@xxxxxxxxx>]

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 <tdiekman@xxxxxxxxx> 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.Stucky@xxxxxxxxxxx> 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@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>> 
>>>> 
>>> _______________________________________________
>>> equinox-dev mailing list
>>> equinox-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> 
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>> 
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev