: : <lib dir="/home/bridge/Workspaces/search-webapp/target/WEB-INF/lib/" : regex=".*\.jar" />
1) as a general rule, if you have a <lib/> delcaration which includes "WEB-INF" you are probably doing something wrong. Maybe not in this case -- maybe "search-webapp/target" is a completley distinct java application and you are just re-using it's jars. But 9 times out of 10, when people have a WEB-INF path they are trying to load jars from, it's because they *first* added their jars to Solr's WEB_INF directory, and then when that didn't work they added the path to the WEB-INF dir as a <lib/> ... but now you've got those classes being loaded twice, and you've multiplied all of your problems. 2) let's ignore the fact that your path has WEB-INF in it, and just assume it's some path to somewhere where on disk that has nothing to do with solr, and you want to load those jars. great -- solr will do that for you, and all of those classes will be available to plugins. Now if you wnat to explicitly do something classloader related, you do *not* want to be using Thread.currentThread().getContextClassLoader() ... because the threads that execute everything in Solr are a pool of worker threads that is created before solr ever has a chance to parse your <lib /> directive. You want to ensure anything you do related to a Classloader uses the ClassLoader Solr sets up for plugins -- that's available from the SolrResourceLoader. You can always get the SolrResourceLoader via SolrCore.getSolrResourceLoader(). from there you can getClassLoader() if you really need some hairy custom stuff -- or if you are just trying to load a simple resource file as an InputStream, use openResource(String name) ... that will start by checking for it in the conf dir, and will fallback to your jar -- so you can have a default resource file shipped with your plugin, but allow users to override it in their collection configs. -Hoss http://www.lucidworks.com/
