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