Community
Participate
Working Groups
Internally, SLf4jLog uses a check for the class "org.slf4j.impl.StaticLoggerBinder" to see if the slf4j jar/classpath requirements are sufficient that slf4j can configure itself. This was done to prevent an internal fallback to nop impl internally in slf4j-api that was causing silent failure of logging in the past. Need to review the need for this requirement in light of reported osgi + pax-logging use.
As a user of Pax Logging (Jetty embedded in equinox, started with the osgi boot thing) that got the surprise of jetty logs starting to go to stderr rather than to syslog after deploying a version containing https://github.com/eclipse/jetty.project/commit/fa7364ac1bbd9f24b7bcebf69e52bc665cc4bc07#L1L30 I can vouch for this :) Pax Logging is divided into two bundles, pax-logging-api and pax-logging-service. The former exposes APIs for a number of logging frameworks and the latter receives the log messages and outputs them to a log4j instance (that we have configured elsewhere). In the API bundle the slf4j implementation has the org.slf4j.impl.StaticLoggerBinder class, but it is not exported. No other bundles we use (or have authored) that use slf4j requires this class to be available to code in another bundle. To work around this we have to this problem is to create a fragment hosted by the util bundle. This contains a single class that implements org.eclipse.jetty.util.log.Logger that delegates (in a non-location aware way) to the exposed slf4j instance like this: http://8571b59854a29679.paste.se/ . Then we set org.eclipse.jetty.util.log.class at JVM startup to use this logger instead. Any way of getting the old behavior back would be greatly appreciated.
This is indeed very poor OSGi behaviour. Since part of the idea of modularity is not to need to expose implementation. So nobody is tempted to be dependant of it - as it is likely to break at some point. I don't really understand why Jetty developers thought it be a good idea to work around this anyway? Seems like if anyone have a problem with getting a NOPLogger, it is a configuration issue of the Slf4J implementation they are using. And something that Jetty should just accept.
(In reply to comment #2) > This is indeed very poor OSGi behaviour. Since part of the idea of modularity > is not to need to expose implementation. So nobody is tempted to be dependant > of it - as it is likely to break at some point. Unfortunately, reverting this change breaks behavior on all environments and deployment scenarios that pre-date OSGi. This is function we can likely break for jetty-9 (currently being worked on).
This was fixed in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=367172. Behaviour has reverted to not trying to second-guess slf4j: we instantiate an slf4j logger class and if under-the-covers it chooses to use a no-op implementation, then that's its problem, not jetty's. slf4j prints out warnings anyway if it is using a no-op impl, so the problem is not hidden. *** This bug has been marked as a duplicate of bug 367172 ***
