[
https://issues.apache.org/jira/browse/CONFIGURATION-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515853
]
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: 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]
