Thanks BJ and Ray, It's much clearer now!
Clement.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday 11 March 2020 16:45, BJ Hargrave <hargr...@us.ibm.com> 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" <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?!
>>
>>> 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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
