[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] starting up an osgi-based "application"
|
The start method of the BundleActivator is for quick initialization code.
Any long running application code should definitely be spawned off in a
separate thread. The spec does not state that bundles will be started in a
separate thread. If you want to prevent the framework from exiting then
you should make sure your application thread is NOT a daemon thread. This
will prevent the JVM from exiting until your application thread is stopped.
In some OSGi implementations if there are only daemon threads running then
it is assumed the framework is in a stale state and it exits. In most
environments there is some kind of application thread running. For
example, a management agent, web server, etc that can act on the framework.
These applications spawn a separate thread during startup to run their
application code.
You must also put the necessary hooks in your application thread to exit
during your BundleActivator.stop() method. This will allow for your
application bundle to properly shutdown and reclaim it classloader as long
as you do not pin any objects.
Thomas Watson
Pervasive Development
Phone: 512-838-4533 Tie: 678-4533
tjwatson@xxxxxxxxxx
Jeff McAffer
<Jeff_McAffer@ca.i To: equinox-dev@xxxxxxxxxxx
bm.com> cc:
Sent by: Subject: [equinox-dev] starting up an osgi-based "application"
equinox-dev-admin@
eclipse.org
08/05/2003 10:32
PM
While individual OSGi implementations will differ, I think this is a common
problem.
When you start an OSGi framework, there is likely a mechanism for defining
a set of bundles to install and perhaps start. Given this you could just
put my application "main" in the appropriate BundleActivator.start() and
put that bundle on the autostart list.
If I understand correctly, that means that start() never exits (well at
least not until the app is done). As a result, you are running the whole
time with the app bundle in STARTING state. Does this not cause problems
with update? For instance, if you want to update the app bundle, you have
to stop it. But you can't stop a STARTING bundle (or you can but it will
throw and exception and will likely not be restarted).
This also implies that there is a different thread for each start() call as
there is no real guaranteed start order so any one of the start's could
block forever (or a long time) and prevent/delay the running of the
following start()s.
So, you could fork a thread to run the app and let start() return. This is
cool and allows for updating, running the other start(), etc. But you
somehow have to stop the framework from exiting. In the couple of
implementations I have seen, if you ignore the console, the framework comes
up, installs/starts the bundles and then, with nothing else to do, falls
off the end of main() (effectively) and stops. What is common practice
here?
Jeff
