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