lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject RE: Solr 4.4.0: Plugin init failure for [schema.xml] analyzer/tokenizer
Date Thu, 19 Sep 2013 19:02:58 GMT

Ok, first off -- let's clear up some confusion...

1) except for needing to put hte logging jars in your servlet container's 
to level classpath, you should not be putting any jars that come from solr 
or lucene, or any jars for custom plugins you have written in "tomcat/lib"

2) you should never manually add/remove any jars or any kind from solr's 
"WEB-INF/lib/" directory.

3) if you have custom plugins you want to load, you should create a *new* 
lib directory, and put your custom plugin jars 9and their dependencies) in 
that directory, and configure it (either with sharedLib in solr.xml, or 
with a <lib> directive in your solrconfig.xml file)

As for the situation situation you find yourself in...

here are the big, gigantic (the size of football fields even) red flags 
that jump out at me as being the sort of thing that could cause all sorts 
of classloader nightmares with your setup...

: *         Following are the jars placed in "tomcat/lib" dir:
: lucene-core.jar 
: solr-core-1.3.0.jar 
: solr-dataimporthandler-4.4.0.jar 
: solr-dataimporthandler-extras-4.4.0.jar
: solr-solrj-4.4.0.jar
: lucene-analyzers-common-4.2.0.jar
: Jars in "tomcat/ webapps/ROOT/WEB-INF/lib/"
: lucene-core-4.4.0.jar 
: nps-solr-plugin-1.0-SNAPSHOT.jar
: solr-core-4.4.0.jar
: solr-dataimporthandler-4.4.0.jar
: lucene-analyzers-common-4.4.0.jar 
: solr-solrj-4.4.0.jar

You clearly have two radically diff versions of solr-core and lucene-core 
in your classpath, which could easily explain the problems of 
ClassCastExceptions related to hte TokenizerFactory class -- because there 
are going ot be two radically differnet versions of that class in the 
classpath, and who knows which one java is trying to cast your custom impl 

seperate from that: even if the multiple solr-dataimporthandler, 
lucene-analyzers-common, solr-solrj jars in each of those directories are 
the exact same binary files, when loaded into the hierarchical 
classloaders of a servlet container, they produce differnt copies of the 
same java classes -- so you can again have classloader problems of 
some execution paths using a "leaf" classloader to access ClassX while 
another thread might use a "parent" classloader to access ClassX -- these 
differnet class instances will have different static fields, and instances 
of these classes will (probably) not be .equals(), etc....


View raw message