On Mon, 17 Dec 2007 06:31:10 -0500
"Hiram Chirino" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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
