[ http://issues.apache.org/jira/browse/SOLR-68?page=comments#action_12447932 ] Fuad Efendi commented on SOLR-68: ---------------------------------
It was done in Eclipse, for instance. Nutch project also has huge 'plugins'-supporting codebase which are automatically loaded and 'wired' together without explicit XML definitions, they did it Eclipse-way... I mean if you use explicit XML like <filter class="org.zzz.my.solr.filters.LowerCaseFilter"/> - you don't need to design smth like Eclipse or Nutch... A lot of headache just to replace strings like "org.apache.nutch.parse.html.HtmlParser" by <name>plugin.includes</name> <value>protocol-http|urlfilter-regex|parse-(text|html|js)|index-basic|query-(basic|site|url)|summary-basic|scoring-opic</value> Here, "parse-(text|html|js)" will look for a jar file with ID "parse-html" in plugin.xml file (inside the jar file): <plugin id="parse-html" name="Html Parse Plug-in" version="1.0.0" provider-name="nutch.org"> ... The main reason for such design: to avoid explicit names "org.apache.nutch.parse.html.HtmlParser" in main configuration XML, to allow third-parties to develop compatible plugins (which could have very different complicated extension points and implementations with specific settings, not defined in main Solr schema.xml file)... I don't think it would work in WebLogic without some explicit settings; and JEE does not easily allow direct access to a file system, especially to load a class 'from a different context' (security considerations)... > 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
