Hi Harald, > My naming was a bit lax. I am talking about solr-solrj*.jar and conflicts > between the 3.4.0 > provided in lib and the one I need, some 4.x.
Yes, but there should be only: apache-nutch-1.8/plugins/indexer-solr/solr-solrj-3.4.0.jar There should be no solr-solrj-3.4.0.jar in lib/: - where does it come from? The 1.8 bin package? - if built from source: - ant clean ? - is some Solr dep mention in ivy/ivy.xml? > When I look at the source code of the PluginClassLoader, it is nothing but a > URLClassLoader with a > constructor calling super(...). Looking at the documentation of ClassLoader > (http://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html), it > says: > > "When requested to find a class or resource, a ClassLoader instance will > delegate the search for > the class or resource to its parent class loader before attempting to find > the class or resource > itself." > > To me this sounds as if the statement in the wiki is just wrong, yet I am > surprised that nobody > noticed this before. Maybe I am missing something? That seems to be the case. Needs to be checked. Thanks, Sebastian On 04/22/2014 09:09 AM, Harald Kirsch wrote: > Hello Sebastian. > > thanks for your comments. > > On 18.04.2014 16:24, Sebastian Nagel wrote: >> Hi Harald, >> >>> 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. > > My naming was a bit lax. I am talking about solr-solrj*.jar and conflicts > between the 3.4.0 provided > in lib and the one I need, some 4.x. > >> >>> 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 > > When I look at the source code of the PluginClassLoader, it is nothing but a > URLClassLoader with a > constructor calling super(...). Looking at the documentation of ClassLoader > (http://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html), it > says: > > "When requested to find a class or resource, a ClassLoader instance will > delegate the search for the > class or resource to its parent class loader before attempting to find the > class or resource itself." > > To me this sounds as if the statement in the wiki is just wrong, yet I am > surprised that nobody > noticed this before. Maybe I am missing something? > > Harald. > > > > > > > > > >> >> 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 >> >> >
