Hi I observed that the ServiceLoader is used for the following two scenarios: - the slf4j-api bundle looks up org.slf4j.spi.SLF4JServiceProvider implementations, we want that to be ch.qos.logback.classic.spi.LogbackServiceProvider (from logback-classic) - the logback-classic bundle looks up ch.qos.logback.classic.spi.Configurator, we want that to be org.apache.sling.commons.log.logback.spi.DefaultConfigurator (see Eric's PR)
One way to satisfy these requirements could be to - attach a fragment bundle to the slf4j-api bundle, where the fragment provides an Import-Package header for ch.qos.logback.classic.spi and a META-INF/service/org.slf4j.spi.SLF4JServiceProvider file pointing to ch.qos.logback.classic.spi.LogbackServiceProvider - attach a fragment bundle to the logback-classic bundle, where the fragment provides an Import-Package header for org.apache.sling.commons.log.logback.spi. and a META-INF/service/ch.qos.logback.classic.spi.Configurator file pointing to org.apache.sling.commons.log.logback.spi.DefaultConfigurator A more sophisticated version could also "attach" implementations of the respective APIs that perform an OSGi service lookup of and delegate to a service. But maybe the above is less dynamic, which might be good for logging. Thoughts? Anything I missed? Reasons why this wouldn't work? Regards Julian On Wed, 15 Jan 2025 at 10:55, Robert Munteanu <romb...@apache.org> wrote: > > On Mon, 2025-01-13 at 07:35 +0100, Carsten Ziegeler wrote: > > > > > > I wonder though (I read "too many hacks" in Julian's email ;-) ) if > > > we > > > could branch off in a different direction and create a bundle that > > > does > > > the SPIFly's job but in a simple way that is specific for the > > > commons- > > > log/slf4j situation: > > > > > > 1. Advertise an osgi.serviceloader capability, but restricts its > > > visiblity via a hook (ResolverHook? [2] ) to only the slf4j api > > > bundle > > > 2. Processes the slf4j api bundle to add an import to the specific > > > implementation of the ( WeavingHook? [3] ) > > > > > > I don't think this can be done directly in the commons-log bundle > > > because we'd have a circular dependency between it and the slf4j- > > > api > > > bundle. > > > > > > > One thing I would like to avoid is weaving :) If we have to do that, > > then it might be better to just directly use SPIFLy. > > Right, my idea was not to weave but adjust the imports dynamically > (which is part of OSGi Weaving ). But that can come later if anyone has > time for it. > > I think we are converging towards a solution where we have: > > - a light bundle > - an all-in-one bundle, without SPIFly > > which to me looks like a good solution to go forward. > > Thanks, > Robert
