Since both bundles B and C offer to export the api.a package, the framework could resolve both bundles to each export the package. Thus you can end up with 2 exports of the api.a package in the framework. So bundle D will import api.a from either bundle B or bundle C and thus will not be able to see the service from the other bundle since it is not type compatible.
 
In this scenario, it is better to have only a single exporter of api.a. Bundle A would be the best choice here as it is the original source of the package. But you would need to allow it to be resolvable so it can be used at runtime.
--

BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargr...@us.ibm.com
 
 
----- Original message -----
From: "Clément Delgrange via osgi-dev" <osgi-dev@mail.osgi.org>
Sent by: osgi-dev-boun...@mail.osgi.org
To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Cc:
Subject: [EXTERNAL] [osgi-dev] Service binding issue and package wiring
Date: Wed, Mar 11, 2020 08:13
 
Hi all,
 
I have some sparse service binding issues at runtime that I think are related at how my bundles export packages.
 
Here is what I have:
- Bundle A exports API package api.a and is not resolvable (not present at runtime).
- Bundle B provides api.a.Service1 service and export/import  api.a package.
- Bundle C provides api.a.Service2 service and export/import  api.a package.
- Bundle D consumes Service1 or Service2 and import api.a package.
 
In this case is there any reason related to the way packages are wired that could lead bundle D to not get Service1 or Service2? Subsidiary question, is it fine to have an API package partly provided by two different bundles when provider bundles embed their API?
 
In a more general practice, for a specific functionality, I have often one core service contract, some DTOs and some DAO services. Which one of this combination is better (considering that I have always an unresolvable API bundle and my providers export the API package they provide):
 
- Core service, DAOs and DTOs in one API package then two providers, one for the core service implementation and DTOs and the other for the DAOs implementation.
- Core service, DAOs and DTOs split in different API packages then three providers, one for each.
 
Regards,
Clement
_______________________________________________
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

Reply via email to