commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Heger (JIRA)" <>
Subject [jira] Commented: (CONFIGURATION-286) ConfigurationUtils.locateFromClasspath() Classloader search logic:
Date Thu, 26 Jul 2007 20:27:04 GMT


Oliver Heger commented on CONFIGURATION-286:

This is a good point. We have discussed this issue before, more information can be found in
this ticket: CONFIGURATION-153. I assume that we will probably implement some kind of locator
objects as described in this ticket in the next major release. This would make it possible
to use specific loading strategies on a per configuration basis if required.

To your current problem: Trying ConfigurationUtils.class.getClassLoader() if the other class
loaders fail seems reasonable to me. Would it help you if we added this additional test?

> ConfigurationUtils.locateFromClasspath() Classloader search logic:
> ------------------------------------------------------------------
>                 Key: CONFIGURATION-286
>                 URL:
>             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:
For additional commands, e-mail:

View raw message