: 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: [email protected]
For additional commands, e-mail: [email protected]
