By the way, if the document on Jetty's class loading architecture [1] is accurate, than jetty uses local-first class loading as required by the servlet specs but with exceptions. Indeed, since jetty uses slf4j internally, it is part of what is called the "server classes" which jetty does NOT export to web-apps. So, bundling slf4j-api, logback-core and logback-classic in your web-app should work fine. Interestingly enough, jetty considers org.apache.log4j and org.apache.commons.logging as *system* classes which the web-app cannot override. I am sure there are good reasons for this strategy but it does not affect slf4j users, unless of course they are using log4j or if they are using jcl-over-slf4j. Yes, it's complicated... [1] http://docs.codehaus.org/display/JETTY/Classloading On 04/02/2010 9:41 AM, Ceki Gülcü wrote:
Assuming jetty uses child-first a.k.a. local-first class loading order, I would recommend to bundle slf4j and logback jar in your war file.
Jetty used to have the opposite class loading order, i.e. parent-first, but I am under the impression that it changed to local-first class loading in recent versions.
BTW, Tomcat uses local-first class loading by default.
HTH,