Re: [osgi-dev] Service binding issue and package wiring
Thanks BJ and Ray, It's much clearer now! Clement. ‐‐‐ Original Message ‐‐‐ On Wednesday 11 March 2020 16:45, BJ Hargrave wrote: > 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" >> Sent by: osgi-dev-boun...@mail.osgi.org >> To: OSGi Developer Mail List >> 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?! >> >>> 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 >> 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 >>> >>> :) >
Re: [osgi-dev] Service binding issue and package wiring
nal 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 Listosgi-dev@mail.osgi.orghttps://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é (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) ___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Service binding issue and package wiring
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 > 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 // mobil
Re: [osgi-dev] Service binding issue and package wiring
> 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 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 > 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" >>> Sent by: osgi-dev-boun...@mail.osgi.org >>> To: OSGi Developer Mail List >>> 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 servi
Re: [osgi-dev] Service binding issue and package wiring
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" > Sent by: osgi-dev-boun...@mail.osgi.org > To: OSGi Developer Mail List > 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
Re: [osgi-dev] Service binding issue and package wiring
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 HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com - Original message -From: "Clément Delgrange via osgi-dev" Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List Cc:Subject: [EXTERNAL] [osgi-dev] Service binding issue and package wiringDate: 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 Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Service binding issue and package wiring
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
