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
