Class loading in J2EE can get pretty weird, and I confess I still
don't fully understand it. I looked into this matter further and I
realized two things:
1) According to the J2EE specs, the context classloader is, in fact,
the correct one to use in a situation like this.
2) I now can't replicate the bug that this patch was designed to fix.
So I'm thinking I may have just made a mistake while setting up my
web app, and put the config files in the wrong place.
So my patch probably won't do any harm, but I'm not sure if it's
necessary.
-MB
On Apr 23, 2006, at 5:42 PM, Yonik Seeley (JIRA) wrote:
[ http://issues.apache.org/jira/browse/SOLR-13?
page=comments#action_12375913 ]
Yonik Seeley commented on SOLR-13:
----------------------------------
Hmmm, I had used Config.class in the past, but I switched to the
context classloader when I saw this Nutch bug:
http://issues.apache.org/jira/browse/NUTCH-142
It seems like these two bugs contradict.
Anyway, I'm inclined to commit your patch since it only tries the
classloader for Config if the context classloader fails to find the
resource.
patch to Config class; improves the loading of resources from
classpath
---------------------------------------------------------------------
--
Key: SOLR-13
URL: http://issues.apache.org/jira/browse/SOLR-13
Project: Solr
Type: Improvement
Environment: Mac OS 10.4.6, Java 1.5.0_06, JBoss 4.0.1
Reporter: Mike Baranczak
Priority: Minor
Attachments: config.patch
If config files aren't found in the expected places, Config
attempts to find them on the classpath. The trouble is, it's using
the current thread's context classpath, which means that the web
application's own classpath is ignored.
--
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
