[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [equinox-dev] Question on programatic close of the runtime
|
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