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
to.
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....
-Hoss
