Hi everyone, I asked this question http://stackoverflow.com/questions/22459539/get-declarative-service-at-runtime a couple of months ago where I was trying to find a way using Declarative Services to be able to decide at runtime which version of a service to use. One of the answers there was that DS is a build-time model so that I couldn't change this model at runtime ("inject me now version 1.4 instead of version 1.8"). This made me go the iPojo route where I finally found a solution: an aggregate dependency where instead of having a single service injected, I get all of the ones for that interface injected via a list or array and then it is up to the consumer to keep that list and decide which version to use when the moment comes. This seems to work fine; however, iPojo in eclipse is not working very well with java 8, so i am reconsidering if DS would be able to do the job. Is there any way to get a list of all the services implementing an interface, and have that list be updated when a new provider registers, all using DS and avoiding Service Trackers?
The real use-case in case there is a completely different way to approach my problem is this. I have multiple bundle versions (A1.0, A1.2, A2.0, A3.0) each with a different XML file inside. The bundles expose a service whose job is just to return that XML resource. The trick is that our system can have multiple hardware devices connected, and only after a new device is connected and I query the device for its version, I can know which XML resource (or more specifically, which service version) I will need to use. So as you can see, I cannot at startup have a service injected and use that one for every device. Any suggestions are appreciated Thank you, Alejandro Endo | Software Designer/Concepteur de logiciels DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
