(这个编辑工具不太会用,样式难看点,凑合看了)每个容器都有自己的类加载器,在默认情况下都是StandardClassLoader的实例。委托机制也和标准的java实现没什么两样。接着往下看项目对应的类加载StandardContext.start();调用WebappLoader.start()开始加载项目,WebappLoader又通过创建一个WebappClassLoader实例进行类加载。WebappClassLoader.loadClass()实现依然波澜不惊,规规矩矩的先从缓存找,找不到调用findClass()进行加载。果然这里实现有点不同,是先自己找,找不到再委托上级查找。和java默认的加载方式不同。见源代码,只留下原理部分,日志和调试信息都去掉了。
据此可以认为,在web项目WEB-INF\lib下的jar包优先级高于jboss,tomcat 下的lib.两处版本不一致的话会导致程序异常。比较省事的办法是WEB-INF\lib下不再保留重复的jar包,实在闲着没事的话可以自己写个类加载器替换tomcat下WebappClassLoader改变加载顺序。但是还可能有隐患,WebappClassLoader权限较低,它加载的类只能访问web应用下的资源,如果servlet-api.jar等包用到其他资源时可能出现异常。这个没实际测过,只是推测。但是catalina要提供对整个容器的支持,servlet-api实现对http协议的封装转换用到外部资源的可能性很大。图三 类加载器结构图总结:sevlet-api.jar,jsp-api.jar,el-api.jar这类容器提供的jar包web项目下没必要再保留一份了,容易出现版本不一致。附录:查看tomcat源码的时候可以看看how tomcat works这本书,很不错,虽然老了点。作者:zyskm http://www.blogjava.net/zyskm
posted on 2011-12-06 13:43 zyskm 阅读(10675) 评论(3) 编辑 收藏
讲得不错 学习了 回复 更多评论
linux的就是强大。 回复 更多评论
这内容跟linux没啥关系呀@雪地靴 回复 更多评论
Powered by: BlogJava Copyright © zyskm