[equinox-dev] Question on programatic close of the runtime
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
Re: [equinox-dev] Question on programatic close of the runtime
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
Re: [equinox-dev] Question on programatic close of the runtime
Do I smell DOS attack? :-)
--
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:
Neil Bartlett njbartl...@gmail.com
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2010/03/12 05:35
Subject:
Re: [equinox-dev] Question on programatic close of the runtime
Sent by:
equinox-dev-boun...@eclipse.org
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
Re: [equinox-dev] Question on programatic close of the runtime
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
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
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 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
AW: [equinox-dev] Question on programatic close of the runtime
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
Re: AW: [equinox-dev] Question on programatic close of the runtime
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
Re: AW: [equinox-dev] Question on programatic close of the runtime
Why are you using the -console option? Seems like you would not really want something on a cluster to be running in console mode. I am wondering who actually would run commands on this console. I suggest you look at the org.eclipse.osgi.framework.console.ConsoleSession service in 3.6 if you need a remote console for which you want more control over. When you register a ConsoleSession service a new console will be started for your ConsoleSession. You will have control over what provides the input and output for the console session (use System.in/out, use a socket, provide a web UI, provide a console RCP view etc.). Then when you want the session to end you simply unregister your ConsoleSession. If a bundle provides the console session service then the session will automatically get cleaned up when stopping the system bundle because all bundles will be stopped which causes all services registered by bundles to be unregistered. Unfortunately the built-in console session that gets used with the -console option does not automatically close when the framework is shutdown. This is because we have some support in the console for running commands even after the framework has shutdown and we leave this session open for that purpose. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=279562 for more details. Tom | | From: | | --| |daniel.stu...@empolis.com | --| | | To:| | --| |equinox-dev@eclipse.org | --| | | Date: | | --| |03/12/2010 11:15 AM | --| | | Subject: | | --| |AW: [equinox-dev] Question on programatic close of the runtime | --| 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
Re: AW: [equinox-dev] Question on programatic close of the runtime
Hello, Please stop sending me emails! Take me out of your mailing list. p...@email.lu Thomas Watson tjwat...@us.ibm.com a écrit : Why are you using the -console option? Seems like you would not really want something on a cluster to be running in console mode. I am wondering who actually would run commands on this console. I suggest you look at the org.eclipse.osgi.framework.console.ConsoleSession service in 3.6 if you need a remote console for which you want more control over. When you register a ConsoleSession service a new console will be started for your ConsoleSession. You will have control over what provides the input and output for the console session (use System.in/out, use a socket, provide a web UI, provide a console RCP view etc.). Then when you want the session to end you simply unregister your ConsoleSession. If a bundle provides the console session service then the session will automatically get cleaned up when stopping the system bundle because all bundles will be stopped which causes all services registered by bundles to be unregistered. Unfortunately the built-in console session that gets used with the -console option does not automatically close when the framework is shutdown. This is because we have some support in the console for running commands even after the framework has shutdown and we leave this session open for that purpose. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=279562 for more details. Tom | | From: | | --| |daniel.stu...@empolis.com | --| | | To:| | --| |equinox-dev@eclipse.org | --| | | Date: | | --| |03/12/2010 11:15 AM | --| | | Subject: | | --| |AW: [equinox-dev] Question on programatic close of the runtime | --| 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
Re: AW: [equinox-dev] Question on programatic close of the runtime
Hi! You can just go to: https://dev.eclipse.org/mailman/listinfo/equinox-dev to unsubscribe from the list. HTH, Martin On 12.03.10 21:30, cpint...@pt.lu wrote: Hello, Please stop sending me emails! Take me out of your mailing list. p...@email.lu Thomas Watson tjwat...@us.ibm.com a écrit : Why are you using the -console option? Seems like you would not really want something on a cluster to be running in console mode. I am wondering who actually would run commands on this console. I suggest you look at the org.eclipse.osgi.framework.console.ConsoleSession service in 3.6 if you need a remote console for which you want more control over. When you register a ConsoleSession service a new console will be started for your ConsoleSession. You will have control over what provides the input and output for the console session (use System.in/out, use a socket, provide a web UI, provide a console RCP view etc.). Then when you want the session to end you simply unregister your ConsoleSession. If a bundle provides the console session service then the session will automatically get cleaned up when stopping the system bundle because all bundles will be stopped which causes all services registered by bundles to be unregistered. Unfortunately the built-in console session that gets used with the -console option does not automatically close when the framework is shutdown. This is because we have some support in the console for running commands even after the framework has shutdown and we leave this session open for that purpose. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=279562 for more details. Tom | | From: | | --| |daniel.stu...@empolis.com | --| | | To: | | --| |equinox-dev@eclipse.org | --| | | Date: | | --| |03/12/2010 11:15 AM | --| | | Subject: | | --| |AW: [equinox-dev] Question on programatic close of the runtime | --| 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
