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
