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,
_______________________________________________
Logback-user mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-user
