[
http://issues.apache.org/jira/browse/SOLR-68?page=comments#action_12448278 ]
Hoss Man commented on SOLR-68:
------------------------------
FYI: I just did a fresh install of jetty-5.1.11 and confirmed that (for my
simple test case of some self contained request handlers in a single JAR) it
works with jetty and jettyplus.
I'd like to do some more testing with just dropping lucene contrib JARs in, and
having multiple JARs ... but assuming no suprises pop up, I think i may just
not worry about some of the more extreme situtions i brought up on the mailing
list since:
1) those situations will hopefully be rare
2) i'm not even sure if those situations will cause a problem
3) if one of those situations does cause a problem, we can allways re-address
the specifics of the ClassLoader independent of the overall "API" of having a
${solr.home}/lib directory
4) if someone relaly does have a situation we can't address because of some
specific quirks in the ClassLoader of their servlet container, nothing in this
approach procludes then from unwrapping the WAR and ading their classes
directly (which is the only option at the moment)
> 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
