> and we don't need an explicit instance of a ClassLoader at all... just put JARs in a classpath... and it works in
> all containers, because we use 'parent' classloader with inherited permissions instead of touching the
> 'container-managed' Thread...
...it's not that easy. If you need to load a class which refrences another class defined in the webapp itself, your approach breaks because the ClassLoader won't wlk back down the ClassLoader hierarchy to try and find it.
Ie: if you create a "CustomRequestHandler implements SolrRequestHandler" and put it in a JAR which you then put in the "shared" lib dir for Tomcat, you'll get a class not found error for something like SolrQueryRequest when CustomRequestHandler is loaded, because SolrQueryRequest is defined in the WAR and "shared" class loader higher doesn't have access to those classes...
...hence my idea to create a new ClassLoader instance which was a "child" of the class loader being used for the webapp itself, so when it delegates on classes it doesn't recognize, it delegates "up" to the solr.war class loader.
Regarding your previous comment about the Nutch/Eclipse plugin model ... i'm not sure if that configuration syntax really fits for us ... it assumes a specific set of extension points, such that a single plugin might map to multiple points, and (as far as i can tell) each extension point is either bound to a single plugin, or hte plugins "chain" themselves.
This doesn't really fit our use case, where you might want dozens of differnet analyzers used in differnet fields – ideally someone should be able to pull any jar out of the lucene/contrib directory containing an analyzer or a Similarity class they want to use, drop that jar into a specified location, and put the name of the schema where they want to use it.
As for how Nutch does this ... they seem to be doing roughly the same thing as I'm trying for in this patch, except the more specific meaning of "plugin" allows them to have a seperate ClassLoader per plugin, that loads the exact jars enumerated in the plugins "manifest" (an xml config file; not a jar MANIFEST) .. but again i'm not sure if/how they deal with the possibility of a plugin loaded class using reflection to try and load another class later on.