commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Norris (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CONFIGURATION-286) ConfigurationUtils.locateFromClasspath() Classloader search logic:
Date Thu, 26 Jul 2007 21:10:04 GMT

    [ 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message