[jira] [Comment Edited] (IO-513) Add convenience methods for reading class path resources

["Stian Soiland-Reyes (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IO-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490886#comment-15490886 ] 

Stian Soiland-Reyes edited comment on IO-513 at 9/14/16 4:38 PM:
-----------------------------------------------------------------

I agree with Gary that there should be variants with the ClassLoader as an additional parameter, (or even required parameter), use of these functions will, unlike getResourceAsStream(), lead to errors in environments with multiple classloaders (e.g. OSGi, or perhaps even within Tomcat), as:

IOUtils.class.getResource(name) will use the classloader of IOUtils, which might not have access to the classloader that holds the resource you want. It's all fine if you run on a single classpath (e.g. java -classpath loads:of:stuff) - but not in anything more complex.

And so a library using IOUtils.resourceTo* methods without providing the ClassLoader might break by anyone trying to use it in such "enterprise" environments. 

Perhaps using the (a bit slow) Reflection.getCallerClass() is a better default if no ClassLoader is provided and the resource can't be found? Or what do folks think - is that too much magic?


Better javadoc might help (if devs read it) - but for sure the variant providing the ClassLoader.



was (Author: stain):
I agree with Gary that there should be variants with the ClassLoader as an additional parameter, (or even required parameter), use of these functions will, unlike getResourceAsStream(), lead to errors in environments with multiple classloaders (e.g. OSGi, or perhaps even within Tomcat), as:

IOUtils.class.getResource(name) will use the classloader of IOUtils, which might not have access to the classloader that holds the resource you want. It's all fine if you run on a single classpath (e.g. java -classpath loads:of:tsuff). 

And so a library using IOUtils.resourceTo* methods without providing the ClassLoader might break by anyone trying to use it in such "enterprise" environments. 

Perhaps using the (a bit slow) Reflection.getCallerClass() is a better default if no ClassLoader is provided and the resource can't be found? Or what do folks think - is that too much magic?


Better javadoc might help (if devs read it) - but for sure the variant providing the ClassLoader.


> Add convenience methods for reading class path resources
> --------------------------------------------------------
>
>                 Key: IO-513
>                 URL: https://issues.apache.org/jira/browse/IO-513
>             Project: Commons IO
>          Issue Type: New Feature
>          Components: Utilities
>            Reporter: Behrang Saeedzadeh
>            Priority: Minor
>              Labels: beginner, features, github-import, newbie
>
> Add convenience methods to {{IOUtils}} for reading class path resources and returning them as {{String}}, {{byte[]}}, and {{URL}} respectively.
> Github PR: https://github.com/apache/commons-io/pull/17



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)