Hi Harald, > However, due to standard class resolution of the JVM, the parent ClassLoader > is asked first. As a > result, classes from the old solrj-jar which comes with Nutch 1.8 are loaded. But it resides inside indexer-solr plugin. Every plugin has it's own class loader and I suppose that the loader of indexer-solr is not the "parent" of any other plugin. Even if: is the "old" indexer-solr active (mentioned in plugin.includes)?
> Would it be a viable workaround to just remove the old solrj from the lib > directory? Just to verify: I don't see any solrj in lib/ in Nutch 1.8 (checked tar bin package). There is only: apache-nutch-1.8/plugins/indexer-solr/solr-solrj-3.4.0.jar There should be no solrj.jar in lib/. If there is one it might help to remove it. > The solution would be a class loader which does not obey the default "ask > parent first" protocol. > Is there such a ClassLoader available for Nutch? That's interesting. My understanding is that the "local" libs of the plugin come first. Otherwise it would be impossible for a plugin to require another library version as one of Nutch's main classes. See https://wiki.apache.org/nutch/WhatsTheProblemWithPluginsAndClass-loading Sebastian On 04/17/2014 12:56 PM, Harald Kirsch wrote: > Hi, > > I am writing a plugin to communicate with the most recent version of Solr. I > add the respective > solrj-jar to the plugin as a library. > > However, due to standard class resolution of the JVM, the parent ClassLoader > is asked first. As a > result, classes from the old solrj-jar which comes with Nutch 1.8 are loaded. > > The solution would be a class loader which does not obey the default "ask > parent first" protocol. Is > there such a ClassLoader available for Nutch? > > Would it be a viable workaround to just remove the old solrj from the lib > directory? > > Harald Kirsch
