ConfigurationUtils.locateFromClasspath() Classloader search logic:
------------------------------------------------------------------
Key: CONFIGURATION-286
URL: https://issues.apache.org/jira/browse/CONFIGURATION-286
Project: Commons Configuration
Issue Type: Improvement
Affects Versions: 1.4
Environment: JBoss 4.0.5.GA, JMX, Java6_01
Reporter: Jeremy Norris
Priority: Minor
This is not necessarily a bug in Commons Configuration, rather simply questions
the Classloader search logic in ConfigurationUtils.locateFromClasspath().
ConfigurationUtils.locateFromClasspath(), looks up resources from Classloaders
in the following order:
- Thread.currentThread().getContextClassLoader();
- ClassLoader.getSystemResource(resourceName);
Is this correct? Should there be more loaders looked up? Here is a scenario
that "fails" to find the desired resource:
A JMX invocation into a managed EJB that's scoped into an EAR on JBoss, which
contains a resource in another jar inside:
Thread.currentThread().getContextClassLoader() will not find it since the
classloader from currentThread() is from the jmx-console war context. In this
situation, the correct loader I want is
ConfigurationUtils.class.getClassLoader() (since commons configuration is
bundled with my ear). Does it make sense to check this one as well? Other
solutions are simply to give it the URL resource at the point it is looked up
(ie: new Configuration(getClass().getResource(resourceName))), so it doesn't
fall though to an unclear, complicated resource lookup from classloaders.
What is the cleanest solution in this scenario?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
