问题描述
- 类加载机制 Tomcat5 shared目录下加载的Spring如何管理Tomcat中部署的多个项目 20C
- 我们知道Tomcat5.x类加载体系结构如下：不同的类加载器加载不同路径上的类或jar包。
Bootstrap
|
System
|
Common
/
Catalina Shared
/
Webapp1 Webapp2
有这样一个场景，在Tomcat5.x下部署了10个项目，每个项目都是用Spring来组织和管理的，可以吧Spring放到Tomcat的Common或Shared目录下让这些程序共享。Spring要对用户程序的类进行管理，自然要能访问到用户程序的类，而用户程序显然是放在WebApp/WEB-INF目录中的，那么背CommonClassLoader或SharedClassLoader加载的Spring如何访问并不在其加载范围内的程序呢。
解决方案
线程上下文类加载器，可以实现父加载器对子加载器的逆向访问。一个线程上下文类加载器是，在默认情况下，设置为其父线程的上下文类加载器。线程的继承关系开始与初始线程（它运行了程序）。初始线程的类加载器被设置为加载应用程序的类加载器。所以，除非显式的变更线程上下文类加载器，线程的上下文类加载器应该是应用程序的类加载器。也就是说，这个上下文类加载器能加载应用程序能加载的类。
解决方案二：
对这个问题我也非常疑惑，我一直搞不懂作者的意思是什么。比如说我将spring的jar包放到了common中，这样spring的jar包肯定就是被commonloder
加载.但是spring的配置文件或者说spring加载配置文件的入口肯定还是web程序，比如web1。这个时候web2肯定是无法访问web1加载的内容了，因为
web1和web2是两个不同webappclassloader加载的。其实这样来看的话，我感觉这是双亲加载才对啊，先是webclassloader加载了web1然后需要spring
相关类，而这些类（Spring中的类）发现是由commonclassloder加载的。这样我web1中的内容（比如bean节点配置的class）还是由webclassloder加载
的。所以这里真的不是很清楚。当然线程上下文类加载器确实是实现了加载器之间的互相访问。可是对于这个问题而言我是搞不懂什么情况。如果楼主
知道了告诉我哦。
解决方案三：
补充一下，难道作者说的是Spring加载配置文件的时候，Spring容器将bean加载完毕这个过程，这样的话应该就可以理解了，因为这个Spring容器中应该有一个参数制定了这是由Web1加载的。然后这样可以通过上下文加载器去加载Web1中的内容，是不是这样。我入行不久，不知道对不对，请指正。