On Dec 16, 2007 9:12 PM, Richard S. Hall <[EMAIL PROTECTED]> 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" <[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
