You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Shawn Heisey <so...@elyograg.org> on 2012/10/13 11:43:37 UTC
Solr4 without slf4j bindings -- apparent catch-22
I'm trying to get a Solr4 install going, building without slf4j
bindings. I am using branch_4x from svn, and using a homegrown init
script. That script is modeled on what I already have working for
version 3.5.0. Solr and Jetty live in /opt/solr4, and the init script
does a chdir to that directory before firing up jetty. I am pointing
solr.home at /index/solr4, using -Dsolr.solr.home.
/index/solr4/solr.xml exists and has sharedLib="lib".
If I use the standard .war file, sharedLib works as I would expect it
to. The solr.xml file is found and it finds the sharedLib directory
just fine, as you can see from this log excerpt:
Oct 13, 2012 3:38:37 AM org.apache.solr.core.SolrResourceLoader
locateSolrHome
INFO: using system property solr.solr.home: /index/solr4
Oct 13, 2012 3:38:37 AM org.apache.solr.core.SolrResourceLoader <init>
INFO: new SolrResourceLoader for deduced Solr Home: '/index/solr4/'
Oct 13, 2012 3:38:37 AM org.apache.solr.core.SolrResourceLoader
replaceClassLoader
INFO: Adding 'file:/index/solr4/lib/mysql-connector-java-5.1.21-bin.jar'
to classloader
Oct 13, 2012 3:38:37 AM org.apache.solr.core.SolrResourceLoader
replaceClassLoader
INFO: Adding 'file:/index/solr4/lib/slf4j-api-1.7.2.jar' to classloader
Oct 13, 2012 3:38:37 AM org.apache.solr.core.SolrResourceLoader
replaceClassLoader
INFO: Adding 'file:/index/solr4/lib/log4j-1.2.17.jar' to classloader
Oct 13, 2012 3:38:37 AM org.apache.solr.core.SolrResourceLoader
replaceClassLoader
INFO: Adding 'file:/index/solr4/lib/slf4j-log4j12-1.7.2.jar' to classloader
Oct 13, 2012 3:38:37 AM org.apache.solr.core.SolrResourceLoader
replaceClassLoader
INFO: Adding 'file:/index/solr4/lib/log4j-over-slf4j-1.7.2.jar' to
classloader
Oct 13, 2012 3:38:37 AM org.apache.solr.core.SolrResourceLoader
replaceClassLoader
INFO: Adding 'file:/index/solr4/lib/jcl-over-slf4j-1.7.2.jar' to classloader
Oct 13, 2012 3:38:37 AM org.apache.solr.servlet.SolrDispatchFilter init
INFO: SolrDispatchFilter.init()
The problem that I am having is with the -excl-slf4j.war file, which I
am trying to use in order to use log4j instead of jdk logging. When I
do that, it seems to be unable to find the sharedLib folder in
solr.xml. Because it can't find any slf4j bindings at all, I cannot see
what's going on in the log. Entire log included:
2012-10-13 02:21:52.972:INFO:oejs.Server:jetty-8.1.2.v20120308
2012-10-13 02:21:52.988:INFO:oejs.NCSARequestLog:Opened
/opt/solr4/logs/request.2012_21_13.log
2012-10-13 02:21:52.992:INFO:oejdp.ScanningAppProvider:Deployment
monitor /opt/solr4/contexts at interval 0
2012-10-13 02:21:52.995:INFO:oejd.DeploymentManager:Deployable added:
/opt/solr4/contexts/solr.xml
2012-10-13 02:21:53.710:INFO:oejw.StandardDescriptorProcessor:NO JSP
Support for /solr, did not find org.apache.jasper.servlet.JspServlet
2012-10-13 02:21:53.732:INFO:oejsh.ContextHandler:started
o.e.j.w.WebAppContext{/solr,file:/opt/solr4/solr-webapp/webapp/},/opt/solr4/webapps/solr.war
2012-10-13 02:21:53.732:INFO:oejsh.ContextHandler:started
o.e.j.w.WebAppContext{/solr,file:/opt/solr4/solr-webapp/webapp/},/opt/solr4/webapps/solr.war
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 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 work, and how to I tell jetty/solr where to find
them? I would very much like to avoid having to specify individual jars
on the java commandline, because of the upgrade pain that will cause.
Thanks,
Shawn
Re: Solr4 without slf4j bindings -- apparent catch-22
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <so...@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
>
Re: Solr4 without slf4j bindings -- apparent catch-22
Posted by Shawn Heisey <so...@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
Re: Solr4 without slf4j bindings -- apparent catch-22
Posted by Chris Hostetter <ho...@fucit.org>.
: I'm trying to get a Solr4 install going, building without slf4j bindings. I
...
: If I use the standard .war file, sharedLib works as I would expect it to. The
: solr.xml file is found and it finds the sharedLib directory just fine, as you
: can see from this log excerpt:
...
: INFO: Adding 'file:/index/solr4/lib/slf4j-api-1.7.2.jar' to classloader
...
: The problem that I am having is with the -excl-slf4j.war file, which I am
: trying to use in order to use log4j instead of jdk logging. When I do that,
: it seems to be unable to find the sharedLib folder in solr.xml. Because it
: can't find any slf4j bindings at all, I cannot see what's going on in the log.
: Entire log included:
I think one, or both, of us is confused about how the dist-war-excl-slf4j
target is intended to be used.
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 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.
-Hoss
Re: Solr4 without slf4j bindings -- apparent catch-22
Posted by Michael Della Bitta <mi...@appinions.com>.
> slf4j-api has to match what solr was compiled against so that the logging calls solr makes will still work.
To my knowledge, that's not strictly true:
http://www.slf4j.org/faq.html#compatibility
Michael Della Bitta
------------------------------------------------
Appinions
18 East 41st Street, 2nd Floor
New York, NY 10017-6271
www.appinions.com
Where Influence Isn’t a Game
On Mon, Oct 15, 2012 at 3:35 PM, Chris Hostetter
<ho...@fucit.org> wrote:
> slf4j-api has
> to match what solr was compiled against so that the logging calls solr
> makes will still work.
Re: Solr4 without slf4j bindings -- apparent catch-22
Posted by Chris Hostetter <ho...@fucit.org>.
: As an interim measure, I tried putting the jars in a separate directory and
: added a commandline option for the classpath. I also downgraded to 1.6.4,
: because despite asking for a war without it, the war still contains slf4j-api
: version 1.6.4. The log still shows that it failed to find a logger binding -
: no difference from above.
As a followup to my other comments:
I think the reason the slf4j-api jar is left in the war is because the
"exclusion" is only of the specifc binding used. users can't arbitrarily
drop in any version of slf4j that they want at runtime, the slf4j-api has
to match what solr was compiled against so that the logging calls solr
makes will still work.
: -Djava.util.logging.config.file=etc/logging.properties option. Trying to set
: that property in jetty.xml according to the wiki didn't work. I notice that
: the example says 'mortbay' ... perhaps Jetty 8 does it differently?
Very probably
-Hoss
Re: Solr4 without slf4j bindings -- apparent catch-22
Posted by Shawn Heisey <el...@elyograg.org>.
On 10/13/2012 3:43 AM, Shawn Heisey wrote:
> The problem that I am having is with the -excl-slf4j.war file, which I
> am trying to use in order to use log4j instead of jdk logging. When I
> do that, it seems to be unable to find the sharedLib folder in
> solr.xml. Because it can't find any slf4j bindings at all, I cannot
> see what's going on in the log. Entire log included:
>
> 2012-10-13 02:21:52.972:INFO:oejs.Server:jetty-8.1.2.v20120308
> 2012-10-13 02:21:52.988:INFO:oejs.NCSARequestLog:Opened
> /opt/solr4/logs/request.2012_21_13.log
> 2012-10-13 02:21:52.992:INFO:oejdp.ScanningAppProvider:Deployment
> monitor /opt/solr4/contexts at interval 0
> 2012-10-13 02:21:52.995:INFO:oejd.DeploymentManager:Deployable added:
> /opt/solr4/contexts/solr.xml
> 2012-10-13 02:21:53.710:INFO:oejw.StandardDescriptorProcessor:NO JSP
> Support for /solr, did not find org.apache.jasper.servlet.JspServlet
> 2012-10-13 02:21:53.732:INFO:oejsh.ContextHandler:started
> o.e.j.w.WebAppContext{/solr,file:/opt/solr4/solr-webapp/webapp/},/opt/solr4/webapps/solr.war
>
> 2012-10-13 02:21:53.732:INFO:oejsh.ContextHandler:started
> o.e.j.w.WebAppContext{/solr,file:/opt/solr4/solr-webapp/webapp/},/opt/solr4/webapps/solr.war
>
> 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 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 work, and how to I tell jetty/solr where to find
> them? I would very much like to avoid having to specify individual
> jars on the java commandline, because of the upgrade pain that will
> cause.
As an interim measure, I tried putting the jars in a separate directory
and added a commandline option for the classpath. I also downgraded to
1.6.4, because despite asking for a war without it, the war still
contains slf4j-api version 1.6.4. The log still shows that it failed to
find a logger binding - no difference from above.
java -classpath libsolr/log4j-1.2.17.jar:libsolr/slf4j-log4j12-1.6.4.jar
-jar start.jar
In other news, I finally got jetty to pay attention to my
logging.properties file for jdk logging, but I had to do it with a
-Djava.util.logging.config.file=etc/logging.properties option. Trying to
set that property in jetty.xml according to the wiki didn't work. I
notice that the example says 'mortbay' ... perhaps Jetty 8 does it
differently?
http://wiki.apache.org/solr/LoggingInDefaultJettySetup
I would really prefer to use log4j ... can anyone tell me how I can go
about doing this successfully?
Thanks,
Shawn