[
http://issues.apache.org/jira/browse/SOLR-68?page=comments#action_12447942 ]
Fuad Efendi commented on SOLR-68:
---------------------------------
>...is when explicitly lookup the class by name, we could make out own
>ClassLoader and use it...
The simplest way is to create a Class object is:
Class fooClass = Class.forName("Foo")
which is equivalent to:
Class.forName("Foo", true, this.getClass().getClassLoader())
Then,
Foo fooObject = fooClass.newInstance()
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...
Sorry, still trying to understand why we would need that method:
public static Class findClass(String cname, String... subpackages)
even here, we can loop in [subpackage+"."+cname] using Class.forName()...
> 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
