commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Norris (JIRA)" <>
Subject [jira] Created: (CONFIGURATION-286) ConfigurationUtils.locateFromClasspath() Classloader search logic:
Date Wed, 25 Jul 2007 23:49:31 GMT
ConfigurationUtils.locateFromClasspath() Classloader search logic:

                 Key: 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

- 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:
For additional commands, e-mail:

View raw message