关于ClassLoader中getResource与getResourceAsStream的疑问
背景:
某日临近下班,一个同事欲任何类中获取项目绝对路径,不通过Request方式获取,可是始终获取不到预想的路径。于是晚上回家google了一下,误以为是System.getProperty("java.class.path")-未实际进行测试,早上来和同事沟通,提出了使用这个内置方法,结果人家早已验证过,该方法是打印出CLASSPATH环境变量的值。
于是乎,继续google,找到了Class的getResource与getResourceAsStream两个方法。这两个方法会委托给ClassLoader对应的同名方法。以为这样就可以搞定(实际上确实可以搞定),但验证过程中却发生了奇怪的事情。
软件环境:Windows XP、Resin、Tomcat6.0、Myeclipse、JDK1.5
发展:
我的验证思路是这样的:
1、定义一个Servlet,然后在该Servlet中调用Path类的getPath方法,getPath方法返回工程classpath的绝对路径,显示在jsp中。
2、另外在Path类中,通过Class的getResourceAsStream读取当前工程classpath路径中的a.txt文件,写入到getResource路径下的b.txt。
由于时间匆忙,代码没有好好去组织。大致能看出上述两个功能,很简单不做解释。
01 |
Path.java |
02 |
public class Path
{ |
03 |
|
04 |
public String
getPath() throws IOException{ |
05 |
|
06 |
InputStream
is = this .getClass().getResourceAsStream( "/a.txt" ); |
07 |
|
08 |
File
file = new File(Path. class .getResource( "/" ).getPath()+ "/b.txt" ); |
09 |
|
10 |
OutputStream
os = new FileOutputStream(file); |
11 |
int bytesRead
= 0 ; |
12 |
byte []
buffer = new byte [ 8192 ]; |
13 |
while ((bytesRead
= is.read(buffer, 0 , 8192 ))
!= - 1 )
{ |
14 |
os.write(buffer, 0 ,
bytesRead); |
15 |
} |
16 |
os.close(); |
17 |
is.close(); |
18 |
|
19 |
return this .getClass().getResource( "/" ).getPath(); |
20 |
} |
21 |
} |
01 |
PathServlet.java |
02 |
03 |
public class PathServlet extends HttpServlet
{ |
04 |
private static final long serialVersionUID
= 4443655831011903288L; |
05 |
|
06 |
public void doGet(HttpServletRequest
request, HttpServletResponse response) |
07 |
throws ServletException,
IOException { |
08 |
Path
path = new Path(); |
09 |
|
10 |
request.setAttribute( "path" ,
path.getPath()); |
11 |
PrintWriter
out = response.getWriter(); |
12 |
|
13 |
out.println( "Class.getResource('/').getPath():" +
path.getPath()); |
14 |
} |
15 |
|
16 |
public void doPost(HttpServletRequest
request, HttpServletResponse response) |
17 |
throws ServletException,
IOException { |
18 |
doGet(request,
response); |
19 |
} |
20 |
} |
在此之前使用main函数测试Path.class.getResource("/").getPath()打印出预想的路径为:/D:/work/project/EhCacheTestAnnotation/WebRoot/WEB-INF/classes/
于是将WEB应用部署到Resin下,运行定义好的Servlet,出乎意料的结果是:/D:/work/resin-3.0.23/webapps/WEB-INF/classes/ 。特别奇怪,怎么会丢掉项目名称:EhCacheTestAnnotation呢?
还有一点值得注意,getPath方法中使用getResourceAsStream("/a.txt")却正常的读到了位于下图的a.txt。
然后写到了如下图的b.txt中。代码中是这样实现的:File file = new File(Path.class.getResource("/").getPath()+"/b.txt");本意是想在a.txt文件目录下再写入b.txt。结果却和料想的不一样。
请注意,区别还是丢掉了项目名称。
写的比较乱,稍微总结下:
程序中使用ClassLoader的两个方法:getResourceAsStream和getResource。但是事实证明在WEB应用的场景下却得到了不同的结果。大家别误会啊,看名字他们两个方法肯定不一样,这个我知道,但是getResourceAsStream总会获取指定路径下的文件吧,示例中的参数为"/a.txt",正确读取“/D:/work/resin-3.0.23/webapps/EhCacheTestAnnotation/WEB-INF/classes/ ”下的a.txt,可是将文件写到getResource方法的getPath返回路径的b.txt文件。两个位置的差别在项目名称(EhCacheTestAnnotation)。
这样我暂且得出一个结论:通过getResourceAsStream和getResource两个方法获取的路径是不同的。但是为什么呢?
于是查看了ClassLoader的源码,贴出getResource和getResourceAsStream的源码。
01 |
public URL
getResource(String name) { |
02 |
URL
url; |
03 |
if (parent
!= null )
{ |
04 |
url
= parent.getResource(name); |
05 |
} else { |
06 |
url
= getBootstrapResource(name); |
07 |
} |
08 |
if (url
== null )
{ |
09 |
url
= findResource(name); |
10 |
} |
11 |
return url; |
12 |
} |
13 |
|
14 |
15 |
public InputStream
getResourceAsStream(String name) { |
16 |
URL
url = getResource(name); |
17 |
try { |
18 |
return url
!= null ?
url.openStream() : null ; |
19 |
} catch (IOException
e) { |
20 |
return null ; |
21 |
} |
22 |
} |
从代码中看,getResourceAsStream将获取URL委托给了getResource方法。天啊,这是怎么回事儿?由此我彻底迷茫了,百思不得其解。
但是没有因此就放弃,继续回想了一遍整个过程:
1、在main函数中,测试getResource与getResourceAsStream是完全相同的,正确的。
2、将其部署到Resin下,导致了getResource与getResourceAsStream获取的路径不一致。
一个闪光点,是不是与web容器有关啊,于是换成Tomcat6.0。OMG,“奇迹”出现了,真的是这样子啊,换成Tomcat就一样了啊!和预想的一致。
在Tomcat下运行结果如下图:
对,这就是我想要的。
因此我对Resin产生了厌恶感,之前也因为在Resin下程序报错,在Tomcat下正常运行而纠结了好久。记得看《松本行弘的程序世界》中对C++中的多继承是这样评价的(大概意思):多重继承带来的负面影响多数是由于使用不当造成的。是不是因为对Resin使用不得当才使得和Tomcat下得到不同的结果。
最终,在查阅Resin配置文件resin.conf时候在<host-default>标签下发现了这样一段:
1 |
< class-loader > |
2 |
< compiling-loader path = "webapps/WEB-INF/classes" /> |
3 |
< library-loader path = "webapps/WEB-INF/lib" /> |
4 |
</ class-loader > |
其中的compiling-loader很可能与之有关,遂将其注释掉,一切正常。担心是错觉,于是将compiling-loader的path属性改成:webapps/WEB-INF/classes1,然后运行pathServlet,b.txt位置如下图:
确实与compiling-loader有关。
结局:
终于通过将<class-loader>标签注释掉,同样可以在Resin中获取“预想”的路径。验证了的确是使用Resin的人出了问题。
疑问:
但是没有这样就结束,我继续对getResource的源码进行了跟进,由于能力有限,没有弄清楚getResource的原理。
最终留下了两个疑问:
1、如果追踪到getResource方法的最底层(也许是JVM层面),它实现的原理是什么?
2、为何Resin中<class-loader>的配置会对getResource产生影响,但是对getResourceAsStream毫无影响(getResourceAsStream可是将获取路径委托给getResource的啊)。还是这里我理解或者使用错误了?
在这里也请明白人指明。
如果你喜欢本文, 请长按二维码,关注公众号 分布式编程.
作者:分布式编程
出处:https://zthinker.com/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。