On 2017-05-26T11:16:29 +0000 "Fauth Dirk (AA-AS/EIS2-EU)" <dirk.fa...@de.bosch.com> wrote:
> Hi, > > AFAIK capabilities are used to resolve bundles. They will not help to > restrict the referenced services. That means if you reference resource > services of a special type in a consumer service, you can not specify which > service should be injected by using capabilities. > > For restricting the services that should be injected you can use the target > reference property. The value is an LDAP filter that can inspect service > properties to select the target services that should be referenced. So you > could for example specify a version property on your services and specify a > target filter in our consumer. > > It is also possible to dynamically change the target filter using the > Configuration Admin. > > I wrote about this in one of my blog posts: > http://blog.vogella.com/2016/09/26/configuring-osgi-declarative-services/ Thanks, I'll give this a read. I think the bulk of my problem distills down to the fact that, for Java code, we have the classloader mechanism to partition and control the (otherwise global) namespace. For resources, an analogous mechanism doesn't really exist. I expose resources as services because that's what OSGi has. To explain: A Java class a.b.C in bundle A contains a reference to a class x.y.Z. The bundle A specifies that it requires a package x.y and, for the purposes of this example, it specifically requires x.y version [1,2). Two bundles B and C both contain a class x.y.Z. B states that it provides x.y version 1 and bundle C states that it provides provides x.y version 2. The OSGi runtime wires A to B, because only B satisfies the requirements of A, and it uses the JVM's classloader system to ensure that all references to x.y.Z in a.b.C are provided by the class loaded from B. The classes in A will never see the classes in C. The class loader system, driven by the metadata provided by the bundle manifests, effectively takes unversioned references such as x.y.Z and wires them up correctly. For resources that aren't Java code, we don't have this same classloader system. I can look in an NPC definition file and see that it depends on something called "x.y.Z", but it's now my responsibility, based on the metadata included in the bundle that contains the NPC definition, to wire that reference up to another compatible bundle that contains "x.y.Z". It feels like I'd basically have to reinvent classloading and a portion of the OSGi resolver to do this, so that suggests that I'm almost certainly doing something wrong or missing something blindingly obvious. M
pgpYPI0lvPfHu.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
