enapps-enorman commented on PR #18: URL: https://github.com/apache/sling-org-apache-sling-commons-log/pull/18#issuecomment-2077746890
> 1. ServiceLoder (+mediator) ... > Would it be possible to short-circuit the ServiceLoader in a similar manner to the work we do for Commons Johnzon? That would keep deployments lean and do less unneeded work. The ServiceLoader mediator availability isn't really a problem for me since I have to have it around anyway for the various jetty-* bundles that I use that require it. Also, the sling starter already includes the mediator bundles for groovy, so... In my opinion, trying to do that kind of ServiceLoader workaround is a losing battle. I think what you are suggesting is to repackage the ServiceLoader consumers and providers into the same bundle so there is no classloading visibility problems. The problem with that is that someone has to be paying attention whenever any of those third-party bundles has a new release and then do a new release of the o.a.sling.commons.log with the new bits. That didn't happen the last time which led to the embedded slf4j / logback classes in the o.a.sling.commons.log bundle drifting years out of date. With that said, I do see that there is one other option described in the slf4j FAQ that might work without the mediator: https://www.slf4j.org/faq.html#changesInVersion200 > SINCE 2.0.9 You can specify the provider class explicitly via the "slf4j.provider" system property. This bypasses the service loader mechanism for finding providers and may shorten SLF4J initialization. I believe the extra work to do that would be to configure the "slf4j.provider" framework property, export the "org.apache.sling.commons.log.logback.spi" package from the o.a.sling.commons.log bundle and then deploy a fragment bundle attached to the slf4j-api host bundle that augments the Import-Package instruction to include the "org.apache.sling.commons.log.logback.spi" package to make it visible to the slf4j-api classloader. If that works then the choice to use the ServiceLoader mediator or the framework-property + fragment bundle could be decided by whoever is constructing the application. Let me know if that would be acceptable to you. > 2. The classloading issues from Logback It has been 2 weeks since I opened the PR proposal to logback and there has been no response at all. Do you know anyone over there would could review it and give a yes or no answer? I'm not really interested in wasting more of my time on alternate ways to do the same thing. If you want to try some other approach then please provide a patch with the changes you think will work better. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
