Ah, that explains it - thanks Hoss! I wasn’t aware of this class loader subtlety, thanks for teaching me something new today :)
-Steve On Sep 3, 2014, at 7:53 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : Yes, I specifically made a package in my custom plugins code that was in > : the solr package space i.e.: org.apache.solr.update.processor > ... > : completely fine within my unit tests as it was loaded with the same > : class loader (junit test run). I believe the specific issue that I came > ... > : something is a bit screwy with the external resource loader as this > : should work (as long as the custom class is within the same package name > : as Solr). > > Ah, ok - so yeah: what you were doing at compile time was valid, but by > then loading those "org.apache.solr.*" classes as a plugin (vs putting > them in the war with the other classes in that pacakge) is definitely what > caused the problem -- at runtime class/package identity includes the > ClassLoader... > > http://www.cooljeff.co.uk/2009/05/03/the-subtleties-of-overriding-package-private-methods/ > > ie: not a bug in Solr's plugin ClassLoader, just the devil-in-the-details > of how a "package" is defined as far as the runtime goes. (And > unfortunately, the "@Override" check in java is source annotation only - > there's no way to ask the JVM to enforce that and treat it as an assertion > or anything like that) > > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
