Re: [osgi-dev] Service binding issue and package wiring

Wed, 11 Mar 2020 08:49:25 -0700

If multiple bundles export the identical package (that is, the same class files containing the same byte codes), the runtime classes are different and distinct. A Class object is a product of the class file and the class loader which loads it.
 
So when bundle B (exporting its copy of package api.a) loads api.a.Service1 and bundle C (exporting its copy of package api.a) loads api.a.Service1, those are two different classes as far as the JVM is concerned.
 
Note, when a bundle both exports and imports a package, the framework is free to resolve the bundle in either state: exporting or importing. So when multiple bundles both export and import a given package, it is entirely possible the framework may choose that more then one of the bundles export the package. Ideally, we would want the framework to select only a single bundle to export the package and that all other bundles import the package. But there can be many reasons (such as other class space constraints) which may cause the framework to export the package from multiple bundles.
 
I would recommend you have a API bundle which exports api.a which is usable at runtime and that all implementation bundles import api.a.
--

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] Re: [osgi-dev] Service binding issue and package wiring
Date: Wed, Mar 11, 2020 10:58
 
> 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.
 
Maybe I lack some basic knowledge about Java class loading, but I thought that as the packages were at the same version there was nothing that can really distinguish them, the framework will choose to use one of the packages from a specific location (eg; Bundle B) and so the services could not be impacted by a type compatibility issue. This is what I understand from the blog post sent by Ray too: "Because the OSGi framework controls the classloading on the package level, when multiple bundles export the API package(s), the OSGi framework can decide which exporting bundle ultimately provides the API package(s) to each bundle importing the API, that is, to each API consumer.". But as I can factually see and from your explanation things can happen differently?!
 
 
Thanks for the link. In the section Going Forward, it is wrote that we should consider not embedding API packages that are defined by OSGi specifications, does this advice also holds for our own service definitions?
 
When building a system with multiple related features does it makes sens to provide a compile time Bundle with all the API packages, and, one runtime API Bundle for each API packages? Is it what the blog post is telling us? What is the relation between osgi.cmpn and the set of osgi runtime API bundles?
 
I like to have one API bundle per workspace, it makes dependency management easier and I have one unique project to be careful with. Would it be relevant that bnd/bndtools provides a support to release multiple runtime API Bundles from one API project simply by configuring something in the bnd.bnd file. I am not sure to be clear, but this is to control the number of projects needed.
 
Another solution would be to make the API Bundle resolvable, but I had some issue with that in the past...
 
 
 
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday 11 March 2020 14:19, Raymond Auge <raymond.a...@liferay.com> wrote:
 
Hi Clément,
 
 
:)
 
- Ray
 
On Wed, Mar 11, 2020 at 9:16 AM BJ Hargrave via osgi-dev <osgi-dev@mail.osgi.org> wrote:
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
 
 
----- Original message -----
From: "Clément Delgrange via osgi-dev" <osgi-dev@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
 
 
--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
 
_______________________________________________
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