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
