2008/6/10 Felix Meschberger <[EMAIL PROTECTED]>: > Hi, > > Am Montag, den 09.06.2008, 13:55 -0700 schrieb jaredmac: > > I'm using Felix/SCR for a GUI application. GUI clients want to know what > > services have registered with a certain interface. However, I get > > non-deterministic behavior when GUI clients make this query (which occurs > > right after bundles have been started): i.e., sometimes, there will be 2 > > services registered, other times 3 or 4. With some debugging, I can see > that > > ServiceEvents are being fired asynchronously as these services are > > registered, and that occurs at the same time that the clients make their > > query on a separate thread, leading to the non-determinism. > > Well, this non-determinstism is by design. OSGi frameworks are dynamic > where everything can come and go virtually at any time. This is very > important and powerful. The drawback - if you will - of this is, that > you have to be aware of this situation, which may be very uncommon at > first sight. If you get used to it, it is like heaven ;-) > > Now, for your situation, the problem is, that as a service consumer you > cannot tell, at which time "all" services are registered, because there > is no notion of "all" services. > > > > > I get the impression reading the forum that my GUI clients should instead > be > > coded to react to/listen for new services coming on-line, rather than > making > > a query up-front... > > Yes. This is a good thing and probably the only thing you can do. >
while I agree that making your GUI more dynamic is typically a good thing, it isn't necessarily the only thing you can do - another solution would be to use the "extender pattern" (http://www.aqute.biz/Snippets/Extender) the extender pattern concept is to watch for bundles with special metadata and act accordingly - because bundles are more coarsely grained you can avoid some of the asynchronous issues that you see with services. this is what Eclipse does - bundles (aka plug-ins) contribute extensions to extension points by using metadata stored inside the bundle (plugin.xml). the set of installed bundles is scanned at start-up and this metadata is then aggregated into what's known as the "Extension Point Registry" - while this is much less dynamic than services, some feel it is a better fit for GUIs so you could do something similar - have either a file, or manifest header, that you watch out for - and arrange for all your service bundles to have the relevant metadata. Then you just need to ensure the service bundles start before the client bundles (perhaps using start-levels or a manager bundle) such a solution isn't as robust as a dynamic GUI that can handle bundles appearing and disappearing on the fly - but it can be simpler to develop and manage, especially if you have full control over the framework. PS. you might also find this comparison interesting: http://eclipse.dzone.com/articles/comparison-eclipse-extensions-and-osgi-services HTH > but I was hoping to insulate my GUI code from this, > > because the GUI, as it currently stands, should be static once everything > is > > initialized. > > Using SCR you can in fact isolate your clients from OSGi specific code: > In that you declare a binding method (don't forget the unbind method !) > the SCR will call the component whenever a new service arives (and goes > away). So the component -- presumably the client ? -- will always be up > to date and have the current list of services available. > > > > > So what I'd like is the following: > > > > 1. Bundles installed, started > > 2. Services registered > > 3. Clients ask for list of services, get deterministic answer > > Clients always get a deterministic answer: The services registered at > the time of the call. The non-determinism comes from the fact, that the > services are registered asynchronously, which is by design and good. > > Hope this helps. > > Regards > Felix > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Stuart
