总结和对比一下(jboss,tomcat,jetty)容器的classloader机制

---

 

总结和对比一下(jboss,tomcat,jetty)容器的classloader机制

容器	jboss(4.05)	tomcat(6.0.30)	jetty(7.1.20)
支持child/parent first设置(默认值)	Java2ClassLoadingCompliance=false	delegate=false	_parentLoaderPriority=false
过滤package配置	FilteredPackages 默认值：　javax.servlet,org.apache.commons.logging	packageTriggers 默认配置：org.apache.commons.logging	systemClasses 默认配置：java.  javax. org.xml. org.w3c. org.apache.commons.logging. org.eclipse.jetty.continuation. org.eclipse.jetty.jndi. org.eclipse.jetty.plus.jaas. org.eclipse.jetty.websocket. org.eclipse.jetty.servlet.DefaultServlet.
特殊性	1. UseJBossWebLoader=false时,过滤packages才能生效 2. UseJBossWebLoader=true时,不支持过滤packages 3. jboss 5.0以后UseJBossWebLoader参数将不支持	1. 在执行child/parent判断之前，会委托system classloader装载系统class，比如jdk的lib库	1. 多了一个serverclass配置，如果是serverclass优先采用child first 2. systemclass默认的配置，多了javax,org.xml,org.w3c配置。
相关文档	svn url : http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_4_0_5_GA_CP18 jboss社区classloader文档: http://community.jboss.org/wiki/ClassLoadingConfiguration	svn url : http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk 官方classloader机制： http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html	svn url : http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/jetty/tags/jetty-7.2.0.v20101020/ classloader 官方文档： http://docs.codehaus.org/display/JETTY/Classloading

 

 

---

 

最后(相关问题分析)

 

问题1：

　　是一个jar sealed问题，　官方说明：　http://download.oracle.com/javase/tutorial/deployment/jar/sealman.html

 

Package Sealing: A package within a JAR file can be optionally sealed, which means that all classes defined in that package must be archived in the same JAR file.
A package might be sealed to ensure version consistency among the classes in your software or as a security measure.
To seal a package, a Name header needs to be added for the package, followed by a Sealed header, similar to this:
Name: myCompany/myPackage/
Sealed: true

The Name header's value is the package's relative pathname. Note that it ends with a '/' to distinguish it from a filename.
Any headers following a Name header, without any intervening blank lines, apply to the file or package specified in the Name header.
In the above example, because the Sealed header occurs after the Name: myCompany/myPackage header,
with no blank lines between, the Sealed header will be interpreted as applying (only) to the package myCompany/myPackage.

This code doesn't work.

Package Sealing: A package within a JAR file can be optionally sealed, which means that all classes defined in that package must be archived in the same JAR file. 
A package might be sealed to ensure version consistency among the classes in your software or as a security measure.
To seal a package, a Name header needs to be added for the package, followed by a Sealed header, similar to this:
Name: myCompany/myPackage/
Sealed: true

The Name header's value is the package's relative pathname. Note that it ends with a '/' to distinguish it from a filename. 
Any headers following a Name header, without any intervening blank lines, apply to the file or package specified in the Name header. 
In the above example, because the Sealed header occurs after the Name: myCompany/myPackage header, 
with no blank lines between, the Sealed header will be interpreted as applying (only) to the package myCompany/myPackage. 

This code doesn't work.

 

说白了就是jdk在jar层面上做的一层控制，避免出现两个不同版本的实现类同时在应用中被装载。

理清了sealed的含义，再看一下出错的堆栈：com.sun.media.jai.util，这个类是jai相关处理

• jai_core.jar
• jai_codec.jar
• jai_imageio.jar

几个jar包的META-INF/MANIFEST.MF中都定义了sealed :true。而我们的应用中刚好有两个jar包，那为什么在jboss运行中没问题，jetty运行却出了问题。

 

最后的原因：

1. 我们使用的是javax.media.jai.JAI.create(String opName,ParameterBlock args)，该类刚好依赖了com.sun.media.jai.util.ImagingListenerImpl等相关类。

2. 注意看jetty的特殊性，针对javax.media.jai.JAI是属于systemclass，所以会优先使用jdk去装载，而com.sun则通过应用容器装载，很巧的是公司的jdk下的jre/lib/ext下刚好增加了jai的相关jar，最终导致了sealed冲突。

 

解决方案：

   处理起来相对暴力，增加配置systemclass配置，添加jai的相关package，所有的jai都采取parent first加载。

<!--for jai_code.jar , jai_codec.jar -->
<Item>com.sun.media.jai.</Item>
<!--for jai_imageio.jar -->
<Item>com.sun.media.imageio.</Item>
<Item>com.sun.media.imageioimpl.</Item>
<Item>jj2000.j2k.</Item>

<!--for jai_code.jar , jai_codec.jar -->
<Item>com.sun.media.jai.</Item>
<!--for jai_imageio.jar -->
<Item>com.sun.media.imageio.</Item>
<Item>com.sun.media.imageioimpl.</Item>
<Item>jj2000.j2k.</Item>

问题2

xml加载的问题，原因也跟jetty的特殊性相关。大家都知道xml解析类有很多种

• xerces
• crimson
• jdk rt.jar
• j2ee.jar

真TMD令人纠结啊，应用容器中一旦同时依赖了这几个xml类库，那麻烦问题就来了。这个SAXParserFactory.newInstance(String factoryClassName, ClassLoader classLoader)在jdk1.6.18版本中有，而在其他的几个包中却没有该接口方法。

 

该问题的原因：

1. 原先应用运行的是tomca，也因为tomcat容器的特殊性，会优先通过system classloader优先装载，正好SAXParserFactory类属于jdk的库，所以也正好装载了jdk的类
2. jetty容器因为特殊systemclass配置，针对javax.打头的package采用parent first，所以这时装载了jdk SAXParserFactory
3. 最后jboss运行时，因为我们使用的是UseJbossWebLoader=true，所以会优先装载应用中的lib，至于用哪个那就看概率了，一般按classpath装载lib的顺序。所以这时没有该方法，就抛出了对应的错误

 

解决方案：

处理方式也比较粗暴，如果该方法存在歧义，那干脆不用这方法不就得了，最后换用了无参的newInstance()方法。但这时得注意了，不同xml类库，对应的xml impl默认配置不一样。比如jdk的配置：就会以他自己的为默认值

 

return (SAXParserFactory) FactoryFinder.find(
                /* The default property name according to the JAXP spec */
                "javax.xml.parsers.SAXParserFactory",
                /* The fallback implementation class name */
                "com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl");

return (SAXParserFactory) FactoryFinder.find(
                /* The default property name according to the JAXP spec */
                "javax.xml.parsers.SAXParserFactory",
                /* The fallback implementation class name */
                "com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl");

 

所以最后为了统一使用，通过设置环境变量：

-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl

-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl

 

问题3:

　该问题是由问题２引出的，正因为设置了xml解析器为xerces，导致在jetty启动的时候出现了一些问题。这次主要的原因就跟共享lib库有关了。

 

最终原因分析：

1. 因为通过环境变量设置了xml解析器的实现类，所以不同的xml类库在创建xml parse时，都会尝试去载入对应的lib库。
2. jetty启动时，其自身需要解析xml文件，这时候就出现问题了，jetty默认是没有xerces xml的解析类的，所以启动就出错了。

 

解决方案：

1. 参照jboss的共享lib的配置，在jetty的ext库里添加了xercesImpl-2.9.1.jar，xml-apis-1.3.04.jar，xml-resolver-1.2.jar
2. 因为我使用的是外部ext库，不想放到jetty软件的lib库下，所以需要通过手工指定，在start.ini中添加：
   

   lib=${jettyserverhome}/ext

   lib=${jettyserverhome}/ext

问题4:

是一个mail邮件发送时发现的问题，从堆栈信息描述看也很见到，对应的javax.mail.event.TransportListener没找到

mail的lib库也是挺让人纠结的

1. xml一样有多个lib库：j2ee.jar，javamail。

2. 但有一点又不同的是j2ee.jar中只有接口申明没有对应的实现类

3. 更纠结的是j2ee-1.4新版本和老的javamail版本接口上还存在差异性(这个是别人告诉我的，个人没仔细验证)

 

看到这，各位看官需要多淡定一下，真是很让人纠结啊

 

最终原先分析：

1. 原先jboss容器运行没问题，主要是和其默认的lib库有关，jboss 4.05在默认的server/default/lib下有个jboss-j2ee.jar，所以即使容器中没有javamail的包也能正常运行。
2. 换成jetty以后，因默认在jetty下没有j2ee这个lib库，所以很悲惨，抛异常了。

 

解决方案：

1. 没必要参合j2ee.jar，直接在原先的工程里添加javamail的依赖，最后在应用中引入javamail的包。

 

 

 

 

---

 结尾

在这次的jetty使用过程，还是遇到了比较多的问题，大部分还是在classloader机制上，希望通过这篇文章能对大家有所帮助，少走弯路。