> On 26 May 2017, at 17:18, Mark Raynsford <list+org.o...@io7m.com> wrote:
> Hello!
> On 2017-05-26T14:23:43 +0200
> Peter Kriens <peter.kri...@aqute.biz> wrote:
>> Yes, you can reuse the Req/Cap model in OSGi for this.
>>
>> I understand the problem is that bundle A.1 uses bundle B.1 and A.2 uses
>> B.2. If A.1 loads a resource X, then it should originate form B.1 and A.2
>> should load from B.2?
> Yes, that's exactly it.
>> If you use the resource services as mandatory dependencies in DS then you
>> must register the services with a property and use the target filter on the
>> consuming side. A bit awkward since it should contain a version. This does
>> not have to be the OSGi bundle version but that of course makes it easier.
>> One trick is to make the version a Java constant. You can then refer to this
>> constant in a bnd package version annotation AND in your target filter.
>> (Assuming you use bnd.)
> That might not be so bad.
>> Another trick is to use a class/interface specific for each application...
> I'm not sure about this one (I think it may be impractical for reasons
> I won’t go into here), but I'll keep it in mind.
From a class space sharing technique it is the easiest :-) Everything is taken
care of for free.
>> If the services are not involved in DS dependencies then there is another
>> solution. First, A.1 must require B1 in some defined namespace. This can be
>> osgi.wiring.bundle or osgi.wiring.package if you have a package name that is
>> shared. You can also define your own namespace.
> I'm not sure what you mean by "some defined namespace". Do you mean
> something along the lines of:
>
> Provide-Capability:
>
> com.io7m.example.resource_package;name:String="a.b.c";version:Version="1.0.0"
>
> ... and:
>
> Require-Capability:
> com.io7m.example.resource_package;filter:="(&(name=a.b.c)(version=1.0.0))"
>
> ?
Jup.
>> You should then register as a DS service factory.
> Is this a specific reference to something in DS, or is it just a
> general term describing a service that instantiates other services?
Ok, I should have used service scopes, the @Component.servicefactory() is
deprecated.
Service Scopes:
singleton 1 instance shared by all
bundle instance per bundle
prototype special, can handle 1 instances per get
>> When you get a request you get the calling bundle. Through the bundle
>> you can find out to what bundles it is wired to in the given
>> namespace.
> Can you explain a little more about this? I don't see anything in the
> Bundle interface, is there some specific API for accessing wiring?
You can get a BundleWiring from a Bundle.adapt(BundleWiring.class). This
provides you access to the wires.
>
>> You can then do the resource request. Clearly, this
>> requires that one DS component is shared between all versions of
>> applications. In this model the easiest is to register a single
>> service for all resources.
> Yes, I think in practice, there'd be a single ResourceResolver service
> through which all requests are made.
So then the wiring traversing should work fine.
Kind regards,
Peter Kriens
>
> M
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
