Hi, Classloading is made more complicated by Jetty in that it magically treats org.slf4j.* classes as "Server" classes and won't let the webapp see them. See http://docs.codehaus.org/display/JETTY/Classloading
The original idea of letting slf4j-api stay in the war was for the webapp not to crash without logger binding configured. But with Jetty, we also get problems if we duplicate slf4j-api-*.jar both in WEB-INF/lib and other places as they needs to be seen from the same class-loader. So perhaps the war produced by dist-war-excl-slf4j should be clean of any slf4j stuff. With Jetty you can then configure your preferred logging by putting slf4j classes in jetty/lib/ext/. With Tomcat you'd probably put them in system/lib or common/lib. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com Solr Training - www.solrtraining.com 15. okt. 2012 kl. 23:30 skrev Shawn Heisey <s...@elyograg.org>: > On 10/15/2012 1:32 PM, Chris Hostetter wrote: >> I think one, or both, of us is confused about how the dist-war-excl-slf4j >> target is intended to be used. > > You arevery likely correct, and it's probably me that's confused. > >> I'm fairly certain you can't try to use slf4j/log4j from the sharedLib -- >> because at that point a lot of solr has already been initialized and >> already started doing logging so slf4j should have already tried to >> resolve the binding it should use, found nothing, and picked it's default >> NOP implementation -- as you can see in your logs... >> >> : SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". >> : SLF4J: Defaulting to no-operation (NOP) logger implementation >> : SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further >> : details. >> >> I *believe* the intended way to us the -excl-slf4j.war is by having the >> servlet container load both the log4j.jar and the slf4j binding for log4j >> -- either by putting it in the jetty/lib, or by specifing them in the >> runtime classpath -- but I think you also need to configure log4j at the >> servlet container level so that it will be initialized. > > I tried both of these-- putting them in jetty's lib, as well as putting them > inan arbitrary directory and and putting the relative path > (blah/filename.jar) on the commandline with -cp (and -classpath). I suspect > what I will need to do is create the standard war, extract it, fiddle with > the contents, and then make a new war. Not terribly automated, but upgrading > is not something I will be doing all that often. In my test environment > (where multiple back to back compiles may be commonplace) it will be a bit > painful, but I suppose I can just build the standard war and use jdk logging > there, until I'm ready to deploy to production. > >> : I also tried putting the slf4j jars in /opt/solr4/lib (jetty's lib >> directory). >> : Unsurprisingly, there was no change. Where can I put the jars to make this >> >> did you move them or copy them, because it wouldn't suprise me if having >> duplicate copies of those slf4j jars in sharedLib broke logging in solr >> even if things were configured and working properly at the jetty level. > > I thought of this, and was using 'mv' for each test iteration. > > Thanks, > Shawn >
