commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stian Soiland-Reyes (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (IO-513) Add convenience methods for reading class path resources
Date Wed, 14 Sep 2016 16:39:20 GMT

    [ 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)

Mime
View raw message