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 14:30:17 GMT
On Mon, 17 Dec 2007 06:31:10 -0500
"Hiram Chirino" <hiram@hiramchirino.com> wrote:

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

But if you need to wait for stuff to become available, then there might not be much choice.

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

I think this is because you are making your ordering dependencies very fine grained. If you
just defined classes of bundles that go into variable start levels, like UNIX run levels,
then you just need to decide what goes where. You could easily embed start-level metadata
into your bundles and then have an "installer" service that you use to install your bundles
and probe for the specified start level (rather than calling BundleContext.installBundle()
directly).

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

Yes, and it would likely work across frameworks. Granted, I am not proposing that you follow
your fine-grained ordering approach, but it would be possible to do on top of the framework.

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

One possibility is to view your commands as dependencies and essentially use the event notification
system to track your command dependencies, then when all of your dependencies are available
you are good to go...however, this approach might be a little tricky in determining if a command
was never going to arrive.

Yet another approach is to implement your command shell using the extender model. In this
approach, your command-line handler can probe the installed bundles to see if they provide
the required commands. Typically such an involves loading and instantiating classes from the
command provider bundles. If you want to use services for your commands, you could sort of
combine the approach from the above paragraph where you treat your commands as dependencies,
but you could include metadata in your command provider bundles indicating which commands
they provide, then you could probe the bundles to determine if all the commands were valid
and if so wait for the services to appear.

Some information on the extender model is in my ApacheCon presentation:

    http://cwiki.apache.org/FELIX/presentations.data/felix-apachecon-20071114.pdf

-> richard

> 
> 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
> > >
> >
> 
> 
> 
> -- 
> Regards,
> Hiram
> 
> Blog: http://hiramchirino.com
> 
> Open Source SOA
> http://open.iona.com

Mime
View raw message