JAVA2 & Jetty Class Loading

前段时间做Jetty迁移项目过程中，遇到的与ClassLoading有关的两个问题的总结与分析，不对的地方，请指正，欢迎拍砖。

问题：Jar包信赖冲突，即项目中依赖的一个类有两个实现版本，我们的JVM、Web容器到底载入的是哪一个呢？

现象：这种问题是很难发现的,也是比较随机的,可能本地编译、运行都没有问题，可是部署到服务器上就有问题，经常：MethodNotFound exception.有时你在eclipse中去查看这个方法时,又是存在的,这时候就感觉比较诡异.

解析:解决方法非常简单,你可能一下就想到了,只要装载的是我们需要的那个版本就可以了,因此你可能想到的有两种方法:

方法一:只保留一份实现，这个不用解释，只有一份当然不会冲突了。

方法二:你可能想到Jvm的classloader的特性,即:同一个类只载入一次.只要保证我们需要的类先载入不就行啦,这种想法是没错的,你可能想到:在lib下的载入顺序是按照文件名的字母顺序,通过修改jar包的名字的方式来更改载入的顺序,我也在测试环境下试过确实好用.但是依然不能下定论,我们要看看Jvm到底是如何载入的,它的载入顺序是怎样的?

　　我们都知道ClassLoader委托体系,我们看一下URLClassLoader中是如何载入一类的：

1.classLoader在URLClassPath下查找资源文件：

public URL findResource(String name, boolean check) {

Loader loader;

for (int i = 0; (loader =getLoader(i)) != null; i++) {

URL url =loader.findResource(name, check);

if (url !=null) {

return url;

}

}

return null;

}

其中getLoader(i)函数是按照classPath的定义顺序来获取每一个资源的Loader，这个时候我们的问题都归结到了classPath的构建上来了。

先看看java2中的classLoader的体系是如何构建的：

ExtClassLoader的classPath构建过程：

1.获取extDirs，即系统属性：“java.ext.dirs”

2.遍历extDirs下的每一个文件，并生成对应的URL，存入urls数组。

3.用urls构建ucp(URLClassPath)。

注：在ucp中的顺序即为载入类时的顺序。这个顺序是严格按照urls中的顺序。因此，对于由ExtClassLoader来装载的类是顺序是由上面第2部来决定的，即这个URL的数组的构建，下面我们来看一下源码：

private static URL[] getExtURLs(File[] dirs) throwsIOException {

Vector urls = new Vector();

for (int i = 0; i < dirs.length; i++) {

String[] files = dirs[i].list();

if (files != null) {

for (int j = 0; j < files.length; j++) {

if (!files[j].equals("meta-index")){

File f = new File(dirs[i], files[j]);

urls.add(getFileURL(f));

}

}

}

}

URL[] ua = new URL[urls.size()];

urls.copyInto(ua);

return ua;

}

我们看到extURL的构建是dirs[i].list()产生的，但是看到这个File.list()函数，我们就要吐血了，它不保证列出的文件顺序，尤其是不保证它们按照fileName字母顺序出现。 也就是说对于在extdirs下放置的类的载入顺序是依赖于系统实现的（即File.list())，因此在ExtClassLoader中，如果我们采用方法二是行不通的。

AppClassLoader的classPath构建过程：

1.获取classPath,即系统属性：“java.class.path”

2.将classPath按分分隔符来拆分构建URL，并存储到:urls数组

3.用urls构建ucp(URLClassPath)。

注意：这里面与ext稍有不同的是第二步，这里的没有对classPath的目录进行扩展。因此在“java.class.path”中的顺序即定义了载入的顺序，可以利用这个来控制载入类顺序。

在jetty容器中的WebAppClassLoader我们的web-inf/lib目录的构建webAppClassLoader时采用的方式与ExtClassLoader相同的方式：

public void addJars(Resource lib){

if (lib.exists() &&lib.isDirectory()) {

String[]files=lib.list();

for (int f=0;files!=null&& f<files.length;f++){

try {

Resource fn=lib.addPath(files[f]);

String fnlc=fn.getName().toLowerCase();

if (!fn.isDirectory() && isFileSupported(fnlc)) {

String jar=fn.toString();

jar=StringUtil.replace(jar, ",", "%2C");

jar=StringUtil.replace(jar, ";", "%3B");

addClassPath(jar);

}

}

catch (Exception ex) {

Log.warn(Log.EXCEPTION,ex);

}

}

}

}

对于文件FileResource中的定义：

public String[] list(){

String[] list =_file.list();

if (list==null)

return null;

for (int i=list.length;i-->0;){

if (newFile(_file,list[i]).isDirectory() && !list[i].endsWith("/"))

list[i]+="/";

}

return list;

}

因此在jetty应用的lib中jar包在classPath顺序也是依赖于File.list()的实现。同样因为这个File的list()方法，不保证任何顺序。

综上，在我们应用中要保证所有依赖仅保留一个版本，就不会出问题啦，否则不同的运行环境可能就会有问题。

问题：sealingviolation

现象：sealingviolation: packag is sealed

解析：这个涉及到jetty的加载机制 Jetty Classloading

Jetty做为Servlet容器，为了遵守Servlet的规范，类加载体系中重写了loadClass()方法，改变了类加载机制不再是java2中的父委托机制，先把这个loaderClass()方法贴出来：

protected synchronized Class<?> loadClass(Stringname, boolean resolve) throws ClassNotFoundException{

Class<?> c= findLoadedClass(name);

ClassNotFoundException ex= null;

boolean tried_parent= false;

booleansystem_class=_context.isSystemClass(name);

boolean server_class=_context.isServerClass(name);

if (system_class && server_class){

return null;

}

if(c == null && _parent!=null &&(_context.isParentLoaderPriority() || system_class) && !server_class){

tried_parent= true;

try {

c= _parent.loadClass(name);

if (Log.isDebugEnabled())

Log.debug("loaded " + c);

}

catch (ClassNotFoundException e) {

ex= e;

}

}

if (c == null) {

try {

c= this.findClass(name);

}

catch (ClassNotFoundException e) {

ex= e;

}

}

if (c == null && _parent!=null && !tried_parent &&!server_class )

c= _parent.loadClass(name);

if (c == null)

throw ex;

if (resolve)

resolveClass(c);

if (Log.isDebugEnabled())

Log.debug("loaded " + c+ " from "+c.getClassLoader());

return c;

}

对于这段代码，在jetty的官网关于classLoading有这样一段解读，说明了为什么jetty中的要重写这个方法：web容器的classLoader的结构与普通java应用有所不同,每一个web应用应该有自己的一个WebAppClassloader,Parent为systemClassloader,层次结构也遵守java2中的结构,但是Servlet规范对于servlet容器是有规定的,即它不是完全采用parent first机制装载Class,它是这样规定的:

1.对于WEB-INF/lib 和 WEB-INF/classes下的类优先于ParentClassLoader被加载,即child first机制.

2.系统类如:java.lang.String　在子优先的方式中是不允许被WebAppClassLoader加载的,避免了在WEB-INF/lib or WEB-INF/　替换了系统类.但不幸的是,这个规范并没有明确定义哪些是系统类

3.Server的实现类不允许在任何的ClassLoader中访问.但也规范中也没有明确给出哪些是Server实现类.

对于上面的1，2，3都是可以进行配置的，比如：classloader的优先级child first 还是parent first;哪些是System Class，哪些是Server Class，都可以配置的，例如通过jetty-web.xml。

Jetty的这种ClassLoading结构可能会出现一种问题就是：如果应用的web-inf/lib 与 jdk下ext目录有相同的类的Jar包,并且这些jar中的类有被定义为Sealed的，则会出现jar Sealed问题。因为在同一package下有些类是在WebAppClassLoader中加载，有些是在ExtClassLoader中加载。对于这个的解决方法，就是可以利用上面的第2点，我们可以把这些类指定为System Class，采用parent first来加载，这样就不会被WebAppClassLoader加载，也就不会出现sealed
violation。