DS is the *newest* way. It's certainly not the only way. But for many cases it is the *best* way. But I do agree that using XML is not everyone's first choice, and that DS could be enhanced to support more scenarios. Having used OSGi since release 1 I've used ServiceListeners, ServiceTrackers and DS a lot, and most recently I've been using DS in the preparation of an OSGi book that I am writing with Jeff McAffer and Paul Vanderlei. While the book discusses the many approaches to working with OSGi services we used DS for the example application and found it to be generally worthwhile. This, I guess, is why it might sound like I'm favoring DS. As I say, it's not the only way.
I encourage you to file feature requests in the OSGi bugzilla database... https://www.osgi.org/bugzilla/ https://www.osgi.org/members/bugzilla/ Thanks Simon From: Marcel Offermans <[email protected]> To: OSGi Developer Mail List <[email protected]> Date: 09/29/2009 11:32 AM Subject: Re: [osgi-dev] Activate component only after another component's state is set Sent by: [email protected] On Sep 29, 2009, at 17:05 , Simon J Archer wrote: In the days before DS where we used the programmatic service APIs to register services and their properties it was actually easier to do this by simply using the ServiceRegistration's setProperties(Dictionary) API. You almost make it sound as if DS are the new and preferred way of dealing with service dependencies. Whilst DS are useful for a lot of scenarios, they surely aren't the only or best way to deal with every (service dependency related) issue. That said, it would be good if DS would support this specific use case. I just don't see a purely declarative model in general being flexible enough to take advantage of all the dynamism that OSGi offers. Greetings, Marcel _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
