Hallo Sebastian,

wow, look at this output from the original downloads:

%) tar tvfz apache-nutch-1.7-bin.tar.gz |grep solrj
-rw-rw-r-- 0/0 281626 2013-06-20 23:10 apache-nutch-1.7/lib/solr-solrj-3.4.0.jar -rw-rw-r-- 0/0 281626 2013-06-20 23:10 apache-nutch-1.7/plugins/indexer-solr/solr-solrj-3.4.0.jar

%) unzip -l ./apache-nutch-1.8-bin.zip |grep solrj
281626 2014-03-11 19:02 apache-nutch-1.8/plugins/indexer-solr/solr-solrj-3.4.0.jar

The 1.7 zip also contains solrj in the lib directory.

To bad I picked just the wrong package to start working with.

Of course, if all problematic class libraries are confined to their plugin-directories, the "ask parent first" protocol is not that important.

Thanks for your help,
Harald.



On 23.04.2014 00:32, Sebastian Nagel wrote:
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






--
Harald Kirsch
Raytion GmbH
Kaiser-Friedrich-Ring 74
40547 Duesseldorf
Fon +49-211-550266-0
Fax +49-211-550266-19
http://www.raytion.com

Reply via email to