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
