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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 >
