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 Nimrod Cohen <Ni...@nice.com> on 2014/09/01 17:30:46 UTC

Classloader for plugin jar

Hi
We have a plugin that works as long as we have all the jars in sold webapps\web-inf\lib

Once we copy the jar to a different location we solr starts ok but on run time we get the below error, we think that solr don't use the right class loader.

Do you have any idea get over this?

Working on solr-4.9.0

null:org.apache.commons.lang.SerializationException: java.lang.ClassNotFoundException: com.ccih.dataexp.config.ClusteringConfiguration
        at org.apache.commons.lang.SerializationUtils.deserialize(SerializationUtils.java:166)
        at org.apache.commons.lang.SerializationUtils.deserialize(SerializationUtils.java:193)
        at org.apache.commons.lang.SerializationUtils.clone(SerializationUtils.java:81)
        at com.ccih.dataexp.pipeline.ClusteringPipeline.newContext(ClusteringPipeline.java:60)
        at com.ccih.analytics.clustering.hotTopics.HotTopics.run(HotTopics.java:31)
        at com.ccih.analytics.data.solr.DEXSearchComponent.runHotTopics(DEXSearchComponent.java:391)
        at com.ccih.analytics.data.solr.DEXSearchComponent.runDEX(DEXSearchComponent.java:279)
        at com.ccih.analytics.data.solr.DEXSearchComponent.onDistributedProcessComplete(DEXSearchComponent.java:206)
        at com.ccih.analytics.data.solr.SolrCloudAwareSearchComponent.finishStage(SolrCloudAwareSearchComponent.java:68)
        at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:330)
        at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
        at org.apache.solr.core.SolrCore.execute(SolrCore.java:1952)
        at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:774)
        at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
        at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
        at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
        at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
        at org.eclipse.jetty.server.Server.handle(Server.java:368)
        at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
        at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
        at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
        at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
        at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
        at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
        at java.lang.Thread.run(Unknown Source)

Thanks,
NIMROD COHEN
Software Engineer
RTI
(T) +972 (9) 775-3668
(M) +972 (0) 52-5522901
nimrod.cohen@nice.com<ma...@nice.com>
www.nice.com<http://www.nice.com/>
[cid:image001.jpg@01CFC607.6DAB3040]<http://www.nice.com/real-time-guidance>

Re: Classloader for plugin jar

Posted by Shawn Heisey <so...@elyograg.org>.
On 9/1/2014 9:30 AM, Nimrod Cohen wrote:
> We have a plugin that works as long as we have all the jars in sold
> webapps\web-inf\lib
> 
> Once we copy the jar to a different location we solr starts ok but on
> run time we get the below error, we think that solr don’t use the right
> class loader.

My reply got long-winded, sorry about that.

The solution that I have found which works the best is to put all
contrib and third-party jars for Solr components into one place --
${solr.solr.home}/lib.  If you use this approach, they only get loaded
once.  If you've got many cores using the <lib> tag in solrconfig.xml,
then the jars will be loaded once for every single core.  Even if this
doesn't use extra memory (I don't know if it does), it will slow down
core loading.

The solr.solr.home system property is the location of the solr.xml file
that configures Solr's core loader.  If you don't set it, it defaults to
"./solr" -- relative to the current working directory of the process
that runs Solr.

This approach *usually* works, but not always.  There is one case that I
know of where it won't work -- the JTS jar required by advanced spatial
features must be part of the libraries extracted from the solr WAR, or
its classes cannot be used.  I don't know if your plugin suffers from
the same problem, but I would suspect that it does not.

If you're using 4.2.1 or earlier, you must tell Solr to use the lib
directory I've described with the following attribute on the solr tag in
solr.xml:

sharedLib="lib"

https://wiki.apache.org/solr/Solr.xml%20%28supported%20through%204.x%29

If you're on version 4.3 or later, specifying the configuration above
can actually cause it not to work, even if you're using the old solr.xml
format.  Solr will automatically use that location without any
configuration at all.  There's an issue in Jira about this problem:

https://issues.apache.org/jira/browse/SOLR-4852

Thanks,
Shawn