[ http://issues.apache.org/jira/browse/SOLR-68?page=comments#action_12448230 ] Hoss Man commented on SOLR-68: ------------------------------
>> the most 'naive' solution could be separate shared solr.jar in the same >> classpath/classloader as plugins... Yeah, I considered that briefly, but I had two big reservations about attempting that approach... 1) Complicates installation in the "simple" case. right now users that wnat an "out of hte box" experience just need to drop a WAR file in place and create two config files. seperating the classes into an external JAR would complicate that by requiring them to put that JAR in their containers shared/common classpath. 2) I'm 90% certain that would eliminate the ability to run multiple solr instances in the same servlet container, because of the way the SolrCore and much of hte COnfig information is implimented via Singletons ... if those classes were loaded by a common classloader, there would be only one instance per container -- not one instance per webapp. > 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
