[ http://issues.apache.org/jira/browse/SOLR-68?page=comments#action_12447950 ] Hoss Man commented on SOLR-68: ------------------------------
> 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... http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html ...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. > Custom ClassLoader for "plugins" > -------------------------------- > > Key: SOLR-68 > URL: http://issues.apache.org/jira/browse/SOLR-68 > Project: Solr > Issue Type: New Feature > Reporter: Hoss Man > Attachments: classloader.patch > > > After beating my head against my desk for a few hours yesterday trying to > document how to load custom plugins (ie: Analyzers, RequestHandlers, > Similarities, etc...) in the various Servlet Containers -- only to discover > that it is aparently impossible unless you use Resin, it occured to me in the > wee hours of last night that since the only time we ever need to load > "pluggable" classes is when explicitly lookup the class by name, we could > make out own ClassLoader and use it ... so i whiped together a little patch > to Config.java that would load JARs out of $solr.home}/lib and was seriously > suprised to discover that it seemed to work. > In the clod light of day, I am again suprised that I still think this might > be a good idea, but i'm not very familiar with ClassLoader semantics, so i'm > not sure if what i've done is an abomination or not -- or if the idea is > sound, but the implimentation is crap. > I'm also not sure if it works in all cases: more testing of various > Containers would be good, as well as testing more complex sitautions (ie: > what if a class explicitly named as a plugin and loaded by this new > classloader then uses reflection to load another class from the same Jar > using Thread.currentThread().getContextClassLoader() ... will that fail?) > So far I've quick and dirty testing with my apachecon JAR under > apache-tomcat-5.5.17, the jetty start.jar we use for the example, > resin-3.0.21 and jettyplus-5.1.11-- all of which seemed to work fine except > for jettyplus-5.1.11 -- but that may have been because of some other > configuration problem I had. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
