Using JDBCStream, Solr cannot find my database driver if I put the .jar in the 
shared lib directory ($SOLR_HOME/lib).  In order for the classloader to find 
it, the driver has to be in the server's lib directory.  Looking at why, I see 
that to get the full classpath, including what is in the shared lib directory, 
we'd typically get a reference to a SolrCore, call "getResourceLoader" and then 
"findClass".  This makes use of the URLClassLoader that knows about the shared 
lib.

But fixing JDBCStream to do this might not be so easy?  Best I can tell, 
Streaming Expressions are written nearly stand-alone as client code that merely 
executes in the Solr JVM.  Is this correct?  Indeed, the code itself is 
included with the client, in the SolrJ package, despite it mostly being 
server-side code ... Maybe I misunderstand?

On the one hand, it isn't a huge deal as to where you need to put your drivers 
to make this work.  But on the other hand, it isn't really the best user 
experience, in my opinion at least, to have to dig around the server 
directories to find where your driver needs to go.  And also, if this is truly 
server-side code, why do we ship it with the client jar?  Unless there is a 
desire to make a stand-alone Streaming Expression engine that interacts with 
Solr as a client, would it be acceptable to somehow expose the SolrCore to it 
for loading resources like this?

James Dyer
Ingram Content Group

Reply via email to