felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Another way of controlling the bundle start order: the Felix-Start-Order header
Date Mon, 17 Dec 2007 02:12:40 GMT
Hiram,

Glad to hear that you are making some progress with Felix.

I am not sure what you suggest is a good idea since it creates a very brittle system...

Can you explain the scenario a little bit? Are all bundles providing commands normally installed
when the framework starts? If so, then you can just have your command-line handler just wait
for the framework STARTED event because at that time all bundles will be started.

I think an even easier solution would be to just install all of your command bundles into
start level 1 and then command-line handler bundle into start level 2, then you can be assured
that all command providers are started before the command-line handler.

If this wouldn't be sufficient, I think you could implement the explicit ordering approach
you mention below by creating some sort of "startup/shutdown" service that handles starting/stopping
all of your bundles when the framework starts/stops. In this approach you could analyze your
dependency metadata externally and start the bundles in the order you want.

I think you really need to re-think the approach, since the dynamics of the OSGi platform
really require less brittle approaches. Maybe we can help you come up with some alternatives.

-> richard

On Sun, 16 Dec 2007 20:47:26 -0500
"Hiram Chirino" <hiram@hiramchirino.com> wrote:

> Hi,
> 
> In servicemix 4 we are implementing a command line console who's
> commands can be plugged via OSGI bundles.  One of the things we would
> like to do is be able to take a arguments on the java command line and
> execute that as a application command.  But part of the problem is
> that the bundle that gets those handles getting the java command line
> args and calling a command implemented via another bundle usually
> loads before all the command bundles get loaded.  Yeah I know we could
> use start levels to solve that start ordering problem.  But I think
> it's a bit of pain having to manually specify the start levels for
> bundles.
> 
> So I started playing with the idea of letting the command bundles to
> declare via a bundle header that it should get started before the
> "argument parsing/command calling" bundle.  I made a little patch to
> felix that you might want to consider including.  It's been
> generalized a little to allow declaring that other bundles should get
> started before or after etc.
> 
> The patch extends felix to use the "Felix-Start-Order" bundle manifest
> header.  The header is used to control the preferred start order as
> seen by the bundle in relation to other bundles.  If not specified
> bundles are started in the order of the Bundle id (the current
> behaviour).     The header is set to a comma separated list specifying
> the order the bundle would like to see things started in.
> 
> Examples:
> 
> To start a bundle last:
> Felix-Start-Order: :all, :this
> 
> To start a bundle first:
> Felix-Start-Order: :this, :all
> 
> To start a bundle before bundle foo and bar:
> Felix-Start-Order: :this, foo, bar
> 
> To start a bundle after bundle foo and bar:
> Felix-Start-Order: foo, bar, :this
> 
> To start a bundle after foo, but before bar:
> Felix-Start-Order: foo, :this, bar
> 
> The current bundle is represented in the list by the ":this" token.
> The ":all" token represents all other
> bundles. Anything else should be a symbolic name of another bundle.
> 
> Anyways.. I hope someone gets time to review that patch and provide feedback.
> 
> -- 
> Regards,
> Hiram
> 
> Blog: http://hiramchirino.com
> 
> Open Source SOA
> http://open.iona.com
> 

Mime
View raw message