[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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 <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
>