You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by "Piotr P. Karwasz" <pi...@gmail.com> on 2022/04/01 18:32:13 UTC
OSGI service lookup
Hello,
In my initial version of the release 2.x `ServiceLoaderUtil` I used an
external OSGI bundle (`osgi-resource-locator`) to lookup services in other
bundles (cf. source code
<https://github.com/apache/logging-log4j2/blob/d262274585735d36bc39d11475005d2021a095f9/log4j-api/src/main/java/org/apache/logging/log4j/util/ServiceLoaderUtil.java#L34>).
The main advantage I saw in it was that JAXB and other Jakarta EE artifacts
use it too.
However, after discussing this with Ralph, I am no longer convinced that
this is the best tool for the job, because:
- since Eclipse took over Java EE, the artifact seems unmaintained
(cf. Github
project <https://github.com/eclipse-ee4j/glassfish-hk2-extra>) and does
not even have a stable JPMS module name, which is problematic for `master
`,
- it is not included by default in the OSGI containers I checked
(although I didn't check very hard).
Because of these reasons and the difficulties I had in using
`osgi-resource-locator` on Java 11 I removed OSGI support in PR #804
<https://github.com/apache/logging-log4j2/pull/804>, waiting for a better
solution (the `ServiceLoaderUtil` is a post-2.17.2 addition, so there is no
BC to take care of). Among the alternatives we could:
1. duplicate the functionality of `osgi-service-locator` (but not the
code which is licensed under EPL),
2. rely on the Service Loader Mediator
<http://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html>,
which requires an additional OSGI service. I am not sure if this would work
in our case, since I am not calling `ServiceLoader` directly, but
through `MethodHandles.Lookup` as a workaround for Java 9+ caller
sensitivity. From what I have read the Service Loader Mediator weaves
the bundles code looking for calls of `ServiceLoader` methods.
3. keep the *status quo*, which requires all OSGI bundles to register
their services as OSGI services. If I am not mistaken, currently only
implementation providers do it. While this might seem as the most
cumbersome solution, Declarative OSGI Services
<http://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html>,
which were already proposed by Matt in LOG4J2-515
<https://issues.apache.org/jira/browse/LOG4J2-515>, should help keep the
maintenance work minimal, since Declarative Services Runtimes seem quite
commonly deployed these days.
Which solution should be adopted? I think that the main concern here should
be to provide a simple way for plugin authors to deploy their modules in
OSGI.
Piotr
Re: OSGI service lookup
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Ralph,
On Sat, 2 Apr 2022 at 11:02, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Ok. But what does that mean with regard to the 3 options Piotr listed?
Declarative Services is backward compatible, so if someone declares a
provider using DS, it will be detected by our current logic. Since we
want (do we?) to maintain compatibility with OSGI runtimes without DS,
we should not use DS directly in our code, but we can use it in
documentation as a rapid way to add OSGI support to a jar of user
custom components.
I added OSGI services lookup to my `ServiceLoaderUtil` PR
(https://github.com/apache/logging-log4j2/pull/804) and it can detect
both services registered manually and through DS.
Piotr
Re: OSGI service lookup
Posted by Ralph Goers <ra...@dslextreme.com>.
Ok. But what does that mean with regard to the 3 options Piotr listed?
Ralph
> On Apr 1, 2022, at 4:37 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> OSGi services are the lowest level primitive they have besides bundles and wires. The declarative services runtime was my preferred system when I was using OSGi several years ago, though I don’t know if that’s the preferred standard.
>
> —
> Matt Sicker
>
>> On Apr 1, 2022, at 18:16, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> Actually, I’d prefer the one that is the most OSGi-like so that it is easily usable
>> by OSGi users (if there are any). It seems to me that what we are currently
>> doing fits that the best - requiring them to be OSGi services.
>>
>> Ralph
>>
>>> On Apr 1, 2022, at 1:23 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> I'd most prefer whichever approach is most compatible with the
>>> non-OSGi use case. For anything OSGi-specific that needs to be added
>>> to our metadata, it would be best provided in a format that's easily
>>> merged with other metadata (e.g., via the manifest.mf file). The DSR
>>> idea still sounds pretty good.
>>>
>>>> On Fri, Apr 1, 2022 at 1:32 PM Piotr P. Karwasz <pi...@gmail.com> wrote:
>>>>
>>>> Hello,
>>>> In my initial version of the release 2.x `ServiceLoaderUtil` I used an
>>>> external OSGI bundle (`osgi-resource-locator`) to lookup services in other
>>>> bundles (cf. source code
>>>> <https://github.com/apache/logging-log4j2/blob/d262274585735d36bc39d11475005d2021a095f9/log4j-api/src/main/java/org/apache/logging/log4j/util/ServiceLoaderUtil.java#L34>).
>>>> The main advantage I saw in it was that JAXB and other Jakarta EE artifacts
>>>> use it too.
>>>>
>>>> However, after discussing this with Ralph, I am no longer convinced that
>>>> this is the best tool for the job, because:
>>>>
>>>> - since Eclipse took over Java EE, the artifact seems unmaintained
>>>> (cf. Github
>>>> project <https://github.com/eclipse-ee4j/glassfish-hk2-extra>) and does
>>>> not even have a stable JPMS module name, which is problematic for `master
>>>> `,
>>>> - it is not included by default in the OSGI containers I checked
>>>> (although I didn't check very hard).
>>>>
>>>> Because of these reasons and the difficulties I had in using
>>>> `osgi-resource-locator` on Java 11 I removed OSGI support in PR #804
>>>> <https://github.com/apache/logging-log4j2/pull/804>, waiting for a better
>>>> solution (the `ServiceLoaderUtil` is a post-2.17.2 addition, so there is no
>>>> BC to take care of). Among the alternatives we could:
>>>>
>>>> 1. duplicate the functionality of `osgi-service-locator` (but not the
>>>> code which is licensed under EPL),
>>>> 2. rely on the Service Loader Mediator
>>>> <http://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html>,
>>>> which requires an additional OSGI service. I am not sure if this would work
>>>> in our case, since I am not calling `ServiceLoader` directly, but
>>>> through `MethodHandles.Lookup` as a workaround for Java 9+ caller
>>>> sensitivity. From what I have read the Service Loader Mediator weaves
>>>> the bundles code looking for calls of `ServiceLoader` methods.
>>>> 3. keep the *status quo*, which requires all OSGI bundles to register
>>>> their services as OSGI services. If I am not mistaken, currently only
>>>> implementation providers do it. While this might seem as the most
>>>> cumbersome solution, Declarative OSGI Services
>>>> <http://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html>,
>>>> which were already proposed by Matt in LOG4J2-515
>>>> <https://issues.apache.org/jira/browse/LOG4J2-515>, should help keep the
>>>> maintenance work minimal, since Declarative Services Runtimes seem quite
>>>> commonly deployed these days.
>>>>
>>>> Which solution should be adopted? I think that the main concern here should
>>>> be to provide a simple way for plugin authors to deploy their modules in
>>>> OSGI.
>>>>
>>>> Piotr
>>
Re: OSGI service lookup
Posted by Matt Sicker <bo...@gmail.com>.
OSGi services are the lowest level primitive they have besides bundles and wires. The declarative services runtime was my preferred system when I was using OSGi several years ago, though I don’t know if that’s the preferred standard.
—
Matt Sicker
> On Apr 1, 2022, at 18:16, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Actually, I’d prefer the one that is the most OSGi-like so that it is easily usable
> by OSGi users (if there are any). It seems to me that what we are currently
> doing fits that the best - requiring them to be OSGi services.
>
> Ralph
>
>> On Apr 1, 2022, at 1:23 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> I'd most prefer whichever approach is most compatible with the
>> non-OSGi use case. For anything OSGi-specific that needs to be added
>> to our metadata, it would be best provided in a format that's easily
>> merged with other metadata (e.g., via the manifest.mf file). The DSR
>> idea still sounds pretty good.
>>
>>> On Fri, Apr 1, 2022 at 1:32 PM Piotr P. Karwasz <pi...@gmail.com> wrote:
>>>
>>> Hello,
>>> In my initial version of the release 2.x `ServiceLoaderUtil` I used an
>>> external OSGI bundle (`osgi-resource-locator`) to lookup services in other
>>> bundles (cf. source code
>>> <https://github.com/apache/logging-log4j2/blob/d262274585735d36bc39d11475005d2021a095f9/log4j-api/src/main/java/org/apache/logging/log4j/util/ServiceLoaderUtil.java#L34>).
>>> The main advantage I saw in it was that JAXB and other Jakarta EE artifacts
>>> use it too.
>>>
>>> However, after discussing this with Ralph, I am no longer convinced that
>>> this is the best tool for the job, because:
>>>
>>> - since Eclipse took over Java EE, the artifact seems unmaintained
>>> (cf. Github
>>> project <https://github.com/eclipse-ee4j/glassfish-hk2-extra>) and does
>>> not even have a stable JPMS module name, which is problematic for `master
>>> `,
>>> - it is not included by default in the OSGI containers I checked
>>> (although I didn't check very hard).
>>>
>>> Because of these reasons and the difficulties I had in using
>>> `osgi-resource-locator` on Java 11 I removed OSGI support in PR #804
>>> <https://github.com/apache/logging-log4j2/pull/804>, waiting for a better
>>> solution (the `ServiceLoaderUtil` is a post-2.17.2 addition, so there is no
>>> BC to take care of). Among the alternatives we could:
>>>
>>> 1. duplicate the functionality of `osgi-service-locator` (but not the
>>> code which is licensed under EPL),
>>> 2. rely on the Service Loader Mediator
>>> <http://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html>,
>>> which requires an additional OSGI service. I am not sure if this would work
>>> in our case, since I am not calling `ServiceLoader` directly, but
>>> through `MethodHandles.Lookup` as a workaround for Java 9+ caller
>>> sensitivity. From what I have read the Service Loader Mediator weaves
>>> the bundles code looking for calls of `ServiceLoader` methods.
>>> 3. keep the *status quo*, which requires all OSGI bundles to register
>>> their services as OSGI services. If I am not mistaken, currently only
>>> implementation providers do it. While this might seem as the most
>>> cumbersome solution, Declarative OSGI Services
>>> <http://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html>,
>>> which were already proposed by Matt in LOG4J2-515
>>> <https://issues.apache.org/jira/browse/LOG4J2-515>, should help keep the
>>> maintenance work minimal, since Declarative Services Runtimes seem quite
>>> commonly deployed these days.
>>>
>>> Which solution should be adopted? I think that the main concern here should
>>> be to provide a simple way for plugin authors to deploy their modules in
>>> OSGI.
>>>
>>> Piotr
>
Re: OSGI service lookup
Posted by Ralph Goers <ra...@dslextreme.com>.
Actually, I’d prefer the one that is the most OSGi-like so that it is easily usable
by OSGi users (if there are any). It seems to me that what we are currently
doing fits that the best - requiring them to be OSGi services.
Ralph
> On Apr 1, 2022, at 1:23 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> I'd most prefer whichever approach is most compatible with the
> non-OSGi use case. For anything OSGi-specific that needs to be added
> to our metadata, it would be best provided in a format that's easily
> merged with other metadata (e.g., via the manifest.mf file). The DSR
> idea still sounds pretty good.
>
> On Fri, Apr 1, 2022 at 1:32 PM Piotr P. Karwasz <pi...@gmail.com> wrote:
>>
>> Hello,
>> In my initial version of the release 2.x `ServiceLoaderUtil` I used an
>> external OSGI bundle (`osgi-resource-locator`) to lookup services in other
>> bundles (cf. source code
>> <https://github.com/apache/logging-log4j2/blob/d262274585735d36bc39d11475005d2021a095f9/log4j-api/src/main/java/org/apache/logging/log4j/util/ServiceLoaderUtil.java#L34>).
>> The main advantage I saw in it was that JAXB and other Jakarta EE artifacts
>> use it too.
>>
>> However, after discussing this with Ralph, I am no longer convinced that
>> this is the best tool for the job, because:
>>
>> - since Eclipse took over Java EE, the artifact seems unmaintained
>> (cf. Github
>> project <https://github.com/eclipse-ee4j/glassfish-hk2-extra>) and does
>> not even have a stable JPMS module name, which is problematic for `master
>> `,
>> - it is not included by default in the OSGI containers I checked
>> (although I didn't check very hard).
>>
>> Because of these reasons and the difficulties I had in using
>> `osgi-resource-locator` on Java 11 I removed OSGI support in PR #804
>> <https://github.com/apache/logging-log4j2/pull/804>, waiting for a better
>> solution (the `ServiceLoaderUtil` is a post-2.17.2 addition, so there is no
>> BC to take care of). Among the alternatives we could:
>>
>> 1. duplicate the functionality of `osgi-service-locator` (but not the
>> code which is licensed under EPL),
>> 2. rely on the Service Loader Mediator
>> <http://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html>,
>> which requires an additional OSGI service. I am not sure if this would work
>> in our case, since I am not calling `ServiceLoader` directly, but
>> through `MethodHandles.Lookup` as a workaround for Java 9+ caller
>> sensitivity. From what I have read the Service Loader Mediator weaves
>> the bundles code looking for calls of `ServiceLoader` methods.
>> 3. keep the *status quo*, which requires all OSGI bundles to register
>> their services as OSGI services. If I am not mistaken, currently only
>> implementation providers do it. While this might seem as the most
>> cumbersome solution, Declarative OSGI Services
>> <http://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html>,
>> which were already proposed by Matt in LOG4J2-515
>> <https://issues.apache.org/jira/browse/LOG4J2-515>, should help keep the
>> maintenance work minimal, since Declarative Services Runtimes seem quite
>> commonly deployed these days.
>>
>> Which solution should be adopted? I think that the main concern here should
>> be to provide a simple way for plugin authors to deploy their modules in
>> OSGI.
>>
>> Piotr
Re: OSGI service lookup
Posted by Matt Sicker <bo...@gmail.com>.
I'd most prefer whichever approach is most compatible with the
non-OSGi use case. For anything OSGi-specific that needs to be added
to our metadata, it would be best provided in a format that's easily
merged with other metadata (e.g., via the manifest.mf file). The DSR
idea still sounds pretty good.
On Fri, Apr 1, 2022 at 1:32 PM Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hello,
> In my initial version of the release 2.x `ServiceLoaderUtil` I used an
> external OSGI bundle (`osgi-resource-locator`) to lookup services in other
> bundles (cf. source code
> <https://github.com/apache/logging-log4j2/blob/d262274585735d36bc39d11475005d2021a095f9/log4j-api/src/main/java/org/apache/logging/log4j/util/ServiceLoaderUtil.java#L34>).
> The main advantage I saw in it was that JAXB and other Jakarta EE artifacts
> use it too.
>
> However, after discussing this with Ralph, I am no longer convinced that
> this is the best tool for the job, because:
>
> - since Eclipse took over Java EE, the artifact seems unmaintained
> (cf. Github
> project <https://github.com/eclipse-ee4j/glassfish-hk2-extra>) and does
> not even have a stable JPMS module name, which is problematic for `master
> `,
> - it is not included by default in the OSGI containers I checked
> (although I didn't check very hard).
>
> Because of these reasons and the difficulties I had in using
> `osgi-resource-locator` on Java 11 I removed OSGI support in PR #804
> <https://github.com/apache/logging-log4j2/pull/804>, waiting for a better
> solution (the `ServiceLoaderUtil` is a post-2.17.2 addition, so there is no
> BC to take care of). Among the alternatives we could:
>
> 1. duplicate the functionality of `osgi-service-locator` (but not the
> code which is licensed under EPL),
> 2. rely on the Service Loader Mediator
> <http://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html>,
> which requires an additional OSGI service. I am not sure if this would work
> in our case, since I am not calling `ServiceLoader` directly, but
> through `MethodHandles.Lookup` as a workaround for Java 9+ caller
> sensitivity. From what I have read the Service Loader Mediator weaves
> the bundles code looking for calls of `ServiceLoader` methods.
> 3. keep the *status quo*, which requires all OSGI bundles to register
> their services as OSGI services. If I am not mistaken, currently only
> implementation providers do it. While this might seem as the most
> cumbersome solution, Declarative OSGI Services
> <http://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html>,
> which were already proposed by Matt in LOG4J2-515
> <https://issues.apache.org/jira/browse/LOG4J2-515>, should help keep the
> maintenance work minimal, since Declarative Services Runtimes seem quite
> commonly deployed these days.
>
> Which solution should be adopted? I think that the main concern here should
> be to provide a simple way for plugin authors to deploy their modules in
> OSGI.
>
> Piotr