[
https://issues.apache.org/jira/browse/CONFIGURATION-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515869
]
Jeremy Norris commented on CONFIGURATION-286:
---------------------------------------------
Thanks for your comments. I like the locator strategy. That seems like the
best solution. Personally, I'm not sure if the small obscure benefits of
adding "ConfigurationUtils.class.getClassLoader()" is worth the extra
complication of the documented behavior of this call - especially if a new
locator strategy is coming in the future. I can work around this in other ways
like finding the resource URL before I call new Configuration(). Thanks again.
> 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]
