felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Another way of controlling the bundle start order: the Felix-Start-Order header
Date Mon, 17 Dec 2007 11:31:10 GMT
On Dec 16, 2007 9:12 PM, Richard S. Hall <heavy@ungoverned.org> wrote:
> 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...

Yeah.. this is another reason I'd like to bounce the idea here.
Perhaps I'm going down the wrong road.

> 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 guess part of the motivation is that if you have lots of bundles in
a system then waiting for the STARTED event could take a while to get
fired.  We would like to be able to execute commands as soon as all
the installed command related bundles are started, but not sooner
since then the command handler would report that requested commands
are not valid while in fact they would be if we waited a little longer
for the command to get registered.

> 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.

Sure.  Like I said in my initial email, start levels could probably
solve my problem.  But I think this is even more brittle and a bigger
mess to maintain than what I proposed.  At least in my approach all
the start order info is self contained in the bundles.

> 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.

Interesting idea.  So can services like this still access the bundle headers?

> 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.

Yeah.  I guess the problem is that I'm implementing a bit of a brittle
pattern.   Namely I have a bundle X that when he gets started he wants
to know what all the valid commands in the system are so that he can
report back to the user if the requested command is valid or not.

Thanks for the feedback.  And if you have any further ideas please let me know.

> -> 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
> >


Blog: http://hiramchirino.com

Open Source SOA

View raw message