前几日使用 Jetty (9.2)部署公司一个 web 项目,这个项目原本部署在 Tomcat server上,一切正常,可是部署到 Jetty 后,启动报错.关键错误信息为"java.lang.NoClassDefFoundError: Could not initialize class org.apache.tomcat.jdbc.pool.DataSource"
项目使用了 Tomcat jdbc connection pool 当中有两个 jar 包 tomcat-jdbc.jar 和 tomcat-juli.jar, 后者是前者的 maven 依赖,后者也是 tomcat 的日志抽象层,tomcat server自带这个 jar 在 tomcat_home 的 bin 文件夹下.依据异常信息推断错误是因为载入和初始化org.apache.tomcat.jdbc.pool.DataSource导致的,为了更easy分析问题,我创建了一个简单的 web 项目仅仅依赖于这两个
jar 包.部署到同一个 Jetty server中,报错"java.util.ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype"
查看源码org.eclipse.jetty.apache.jsp.JuliLog非常明白是org.apache.juli.logging.Log的子类,但为什么会报这种错误呢,结合之前的java.lang.NoClassDefFoundError和java.util.ServiceConfigurationError能够确定问题是因为类载入引起的,依据对类载入的了解,同一个类被不同的类载入器实例载入得到的
Class 对象是不同的.所以我判断可能是因为 Jetty server使用了不同的类载入器实例载入了两个累,导致继承关系不存在了.查看java.util.ServiceConfigurationError相关的API文档发现,这个 Error 是在 ServiceLoader载入 Service Provider 时发生的.查看 ServiceLoader 的源码发现这样一段
private S nextService() {
if (!hasNextService())
throw new NoSuchElementException();
String cn = nextName;
nextName = null;
Class<?
> c = null;
try {
c = Class.forName(cn, false, loader);
} catch (ClassNotFoundException x) {
fail(service,
"Provider " + cn + " not found");
}
if (!service.isAssignableFrom(c)) {
fail(service,
"Provider " + cn + " not a subtype");//我遇到的错误信息刚好是这里.
}
try {
S p = service.cast(c.newInstance());
providers.put(cn, p);
return p;
} catch (Throwable x) {
fail(service,
"Provider " + cn + " could not be instantiated",
x);
}
throw new Error(); // This cannot happen
}
为了验证我的猜測,參考这段代码我写了个小程序来測试.主要代码例如以下
public class Main {
public static void main(String[] args) throws ClassNotFoundException {
final ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
final CustomClassLoader customClassLoader
= new CustomClassLoader("target/classes", "自己定义载入器", systemClassLoader);//第一个參数的路径是类的编译路径
//使用系统类载入器载入 Child
//由于 Child 依赖 Parent 所以系统类载入器会自己主动载入 Parent,这个行为与 jetty 的 WebAppClassCloader 相同
Class<?> child = Class.forName("Child", true, systemClassLoader);
//由于之前载入过,不会反复载入直接返回 Parent 类实例
Class<?> parent = Class.forName("Child", true, systemClassLoader);
//使用自己定义载入器载入 Child
//自己定义载入器会优先尝试自己载入,失败后使用父载入器
Class<?
> customChild = Class.forName("Child", true, customClassLoader);
Class<?
> customParent = Class.forName("Parent", true, customClassLoader);//相同不会反复载入
//測试
//相同使用系统载入器载入的两个类,继承关系正常
System.out.println("parent.isAssignableFrom(child) = " + parent.isAssignableFrom(child));//true
//使用自己定义载入器载入的 Child 却不是系统类载入器载入的 Parent 的子类
System.out.println("parent.isAssignableFrom(customChild) = " + parent.isAssignableFrom(customChild));//false
//相同使用自己定义载入器载入的两个类,集成关系正常
System.out.println("customParent.isAssignableFrom(customChild) = " + customParent.isAssignableFrom(customChild));//true
}
}
这段代码中 Child 是 Parent 的子类.这个简单的測试验证了我的猜測.查看文档发现 Jettty 在9.2版本号中的 jsp 引擎使用的是 tomcat 的.在 Jetty 的 lib 里面能够发现例如以下jar
org.eclipse.jetty.apache-jsp-9.2.3.v20140905.jar
org.eclipse.jetty.orbit.org.eclipse.jdt.core-3.8.2.v20130121.jar
org.mortbay.jasper.apache-el-8.0.9.M3.jar
org.mortbay.jasper.apache-jsp-8.0.9.M3.jar
org.mortbay开头的两个 jar 里面是 apache 的 jsp 实现类当中包括org.apache.juli.logging这个包,org.eclipse.jetty.apache-jsp-9.2.3.v20140905.jar这个 jar 中提供了 logging 的详细实现,终于通过 ServiceLoader 载入.问题就出在这里,由于我的项目中有 tomcat-juli.jar 当中也包括org.apache.juli.logging这个包.
查看了一下 Jetty 的文档中有关类载入的内容,发现 Jetty 对每一个部署的 web 应用使用单独的WebAppClassLoader实例进行类载入.通常实现自己定义类载入器的时候会优先托付给父载入器(一般为系统类载入器,能够通过 ClassLoader.getSystemClassLoader() 得到),然后再尝试自己载入类.但 Jetty 的这个 WebAppClassLoader 正相反,除了对于系统类和server类(什么是系统类和server类能够查看文档),会优先尝试自己载入,然后才托付父载入器.
依据这个行为基本能够确认了,server载入 jsp 引擎是会使用自己的类载入器载入server lib 中上述的类(org.apache.juli.logging.Log及事实上现org.eclipse.jetty.apache.jsp.JuliLog),应用部署时会使用WebAppClassLoader载入应用
lib 中的org.apache.juli.logging.Log.载入过程是这种, WebAppClassLoader实例载入org.apache.tomcat.jdbc.pool.DataSource,其依赖org.apache.juli.logging.Log,优先尝试自己载入,所以会从应用的
lib 中载入到这个类,而尝试载入事实上现的时候发现应用 lib 中没有,再托付给父类载入器,也就是 Jetty server的载入器,成功载入到org.eclipse.jetty.apache.jsp.JuliLog,这样就是使用两个不同的载入器实例载入了子类和父类,依据之前的測试结果,两个类之间的继承关系是不成立的.所以导致发生错误.
清楚了问题的解决办法,怎么解决呢?
方案一,在 maven 配置中将 tomcat-juli 的依赖 scope 改为 provided,Jetty server已经提供了. 这样在WebAppClassLoader 尝试自己载入org.eclipse.jetty.apache.jsp.JuliLog时会失败,进而托付父类载入器,这样org.apache.juli.logging.Log及事实上现org.eclipse.jetty.apache.jsp.JuliLog两个类就是同一个载入器载入了.
方案二,更改 WebAppClassLoader 的父类载入器的优先级,使其优先使用父类载入器.详细配置方式能够參考文档.目标是调用 setParentLoaderPriority(true)
使用这两个方案,相同能够解决原始项目中的问题,可是为什么測试用的简单 web 项目和原始项目的错误信息不同呢?
回到原始项目的错误信息发现,"java.lang.NoClassDefFoundError: Could not initialize class org.apache.tomcat.jdbc.pool.DataSource"这个错误是因为在载入类的时候无法初始化,那么看org.apache.tomcat.jdbc.pool.DataSource中,在类载入后要做的初始化操作有什么,通过查看源代码发现private static
final Log log = LogFactory.getLog(DataSource.class);仅仅有这句代码是须要在类载入后进行的初始化,跟踪这个语句发现终于会进入上文中提到的nextService方法,所以根源错误依旧是上面描写叙述的.
至此问题得到比較圆满的解释和解决.
总结:
本文涉及到的知识点
1.Java虚拟机的类载入机制
2.JavaServiceProvider 载入机制
3.Java 类的初始化过程
4.Jetty server的配置方式