Re: [equinox-dev] Using Equinox for Headless Applications

[Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]

> 3) Scheduling: run "jobs" or "tasks"
at certain times
  On this particular point, the
application admin service (part of the MEG specification) has a built-in
scheduler. Therefore if you were to map your "tasks" to applications
(note that the term application in the osgi spec is defined loosely) then
you could leverage this.
  Note that we are currently working
on an implementation of this service for equinox and it should made available
in the eclipse SDK shortly (probably for M4). It will be announced here.

HTH, 

PaScaL

"Neil Bartlett" <njbartlett@xxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

11/06/2006 09:37 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	"Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] Using Equinox for Headless Applications

Marcus,

Yes these are all excellent use-cases for the use of OSGi in general and
Equinox specifically. As other respondents have pointed out, your best
source of documentation is probably the core OSGi specification
downloadable from www.osgi.org. However I'll try to give you some pointers
for your specific use-cases so that you may have an idea where to start.

> 1) Run an execution environment (server)

Running Equinox as a standalone executable (ie without the GUI) is
documented here:
http://www.eclipse.org/equinox/documents/quickstart.php

The OSGi console will let you do most of the management that you need to
do. The only major drawback at the moment is you can't run it over port
in
a secure way, so you have to use it from the console. However you can use
standard UNIX tools like bg, fg or even "screen" to manage this.

The OSGi console can also be extended with your own code, so you can build
custom commands to control your server. I believe that Chris Aniszczyk
has
written a how-to article on that recently.

In the longer term, the Equinox team are building JMX support so you could
manage the whole thing through your web browser or a JMX management tool.

> 2) Deploy application as bundles/plugins (hopefully remotely)

You can do this from the console using the "install" command.
Alternatively any bundle can call the installBundle() method on
BundleContext, so you could write your own manager bundle that installs
and updates bundles on request. installBundle() is overloaded, one version
takes an InputStream to supply the bundle data. That InputStream could
come from a remote source such as an HTTP or FTP connection or whatever.

> 3) Scheduling: run "jobs" or "tasks" at certain
times

There's nothing in the OSGi APIs for scheduling at the moment. You could
investigate a library such as Quartz to help you out here. I don't have
personal experience of using Quartz so there might be some glue code to
write.

One thing to be wary of is using the start() method of your
BundleActivator to perform your tasks. You could certainly use it to kick
off a thread, but if you start doing lots of work right in the start()
method then you will starve the framework.... OSGi would like its thread
back!

You could use the Eclipse Jobs API to abstract away from the raw threads.
The really cool thing about this is you can then take the same Jobs and
run them in your RCP app or the IDE, and you'll get progress reporting
etc
on them. The core Jobs API has no dependency on the GUI though.

> 4) Start/Stop (hopefully remotely)

Do you mean overriding the scheduler in order to manually start tasks?
There are lots of ways to do this, but I would probably look at writing
a
console command for it (see (1)).

> 5) Upgrade (hopefully remotely)

To upgrade a bundle just use the "update" command on the console,
or from
code call update() on the Bundle. Just like installBundle(), there's a
version that takes an InputStream so you can supply the data from
anywhere. This again is probably a job for a manager bundle. The manager
bundle can even use update() to upgrade itself :-)

I hope this helps to get you started. Good luck.

Regards,
Neil




_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev