I'm not following the scenario you are suggesting as it would apply to SLF4J. I understand that you describe a situation where SLF4J is loaded by both the container and the webapp (and so they are technically different classes), but not how this will pose a problem. Logger's are only used internal to a class and so it wouldn't matter if the class that is using SLF4J internally is passed from the webapp to the container since the container wouldn't directly touch it.
By the way, SLF4J uses a very unique (in Java) technique of static binding to a logging implementation. It does no dynamic class lookups to find the logger implementation (unlike JCL). Instead, each SLF4J implementation jar provides the very same class, which the API jar talks to. ~ David hossman wrote: > > > It's not just a question of API compatibility, it's a question of *class* > compatibility (ie: byte code) > > Even if the public APIs are consistent, it's very easy to get into > "classloader hell" when a webapp has one version of a class loaded (even > if it's a private class) while the servlet container has another version > loaded -- especially in the case where webapps will likely be passing > these objects up to code running in the Servlet Container context (for > example: the "default" case of a centrally configured logging) > > This, by definition, cannot happen with JUL, because there is only one > version of the j.u.l.* class files loaded by the JVM at anyone time. > > : Hmm. This is probably fixable doing either of these two (both are > easy): > : 1. update the SLF4J in Jetty > : 2. at deploy time either remove slf4j from the war, or configure Jetty > not > : to use it (JBoss has that latter feature which is quite nice) > : > : This is also a scenario that could play out with JUL, it's just embedded > : with the JDK. Sun just hasn't updated it yet (if they did I am unaware; > : simple searches suggest not). > : > : Any way, I think that logging APIs stabilize really fast by necessity -- > : nobody wants a fast changing logging API. I'd be really surprised to > hear > : of this sort of thing from any of the usual suspects going forward. I > am > : referring to the API where frameworks log to, not other parts which apps > : tend not to write to. > > > -Hoss > > > -- View this message in context: http://www.nabble.com/Solr-Logging-tp16836646p17042875.html Sent from the Solr - Dev mailing list archive at Nabble.com.
