You cannot have two bundles where: - each exports the same package (and does not import it) - AND each exports a service for a type in said package - AND those services are compatible
Basics of OSGi Classloading: - each bundle is loaded in a separate classloader - classloaders load classes (and therefore packages) so a package can be loaded as many times as there are classloaders (bundles) that can load it - each of those package instances are incompatible since they come from different classloaders - two bundles exporting the same package are immediately incompatible UNLESS the framework has enough information (substitutable imports) to be able to only load one of those packages during runtime (in which case it won't actually load the package from each bundle that provides it, but only from one such bundle, and let all the other bundles import it instead of using their own) then the classes and instances would be compatible. But why you would deliberately subject yourself to that kind of scenario is beyond me. Exporting the package from a single API bundle has never been a bad thing. That should be your goto approach. - Ray On Wed, Mar 11, 2020 at 10:57 AM Clément Delgrange 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. > > 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?! > > > You may want to also look at > https://blog.osgi.org/2020/01/to-embed-or-not-to-embed-your-api.html > > 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, > > You may want to also look at > https://blog.osgi.org/2020/01/to-embed-or-not-to-embed-your-api.html > > :) > > - 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 >> 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 >> > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
