J2EE应用部署（三）：高级篇 (1)

提纲: 
=================================== 

一、模块次序问题 

二、依赖库的问题 

    2.1 解决方案之一 

    2.2 解决方案之二 

    2.3 依赖库应用实例 

=================================== 
正文: 
=================================== 

在前面两篇文章中，我们了解了J2EE应用封装和部署的基本概念和实践操作，下面我们来看看几个可能遇到的问题。 

一、模块次序问题 

J2EE规范没有对EAR文件内的J2EE模块应该如何部署作出任何规定。特别地，J2EE规范没有明确规定部署模块的次序。如果一个模块中的某个组件要用到另一个待部署模块的组件，它可能会带来问题。 

因此，必须注意大多数应用服务器以如下步骤部署EAR文件： 

EAR文件内的所有资源适配器作为基本连接器部署。如果存在多个资源适配器，则它们的部署次序就是它们在application.xml部署描述器中列出的次序。 

部署所有EJB模块。由于EJB可能在初始化期间用到某些资源适配器，所以EJB的部署在资源适配器之后。如果存在多个EJB模块，它们的部署次序将是它们在application.xml中列出的次序。 

部署所有Web应用模块。由于Web应用初始化期间可能用到资源适配器和EJB，所有Web应用在这两者之后部署。如果存在多个Web应用模块，它们部署次序就是它们在application.xml中列出的次序。 

二、依赖库的问题 

在J2EE应用封装和部署过程中，最常见的问题出现在工具类和支持类上。封装Web应用或EJB应用时，这些库应该放在哪里？Web应用和EJB应用一般都有被“卸出”（这里指装入的反向过程）的能力，这种能力由部署时装入它们的类装载器支持。如果我们把工具类和支持类放入应用服务器的标准类路径，这些类很可能完全失去被卸出的能力。这样，如果Web应用或EJB应用要更新某个库的版本，重新部署Web应用或EJB应用时，包含工具类和支持类的依赖库也要重新部署。在这种情形下，把工具类放入应用服务器标准类路径很不方便，因为每次部署Web应用和EJB应用时，都要重新启动整个应用服务器，这显然不是理想的选择。 

那么，在J2EE标准定义中，假定依赖库放在哪里才能实现运行时的重新部署（热部署）呢？有两个简单的方案，但从根本上来说两者都不甚合理： 

以JAR文件形式封装的依赖库可以放入Web应用的WEB-INFlib目录。一般地，WEB-INFlib目录基本上只用来存放Servlet，JSP页面和Servlet会在读取新类时寻找该目录。如果工具类库只供一个Web应用的JSP页面和Servlet使用，应该说这个方案已经足够。然而，如果EJB组件、JMS消费者、启动应用的类和关闭应用的类也要用到同一工具类库，这种方案不再有效，因为对于它们来说，WEB-INFlib目录是不可见的。 

除了把工具类库放入WEB-INFlib目录之外，同时在每一个EJB JAR文件中包含一份完整的拷贝。部署EJB时，EJB类装载器将只在它自己的JAR文件中寻找被引用的工具类，不去查看其他已部署EJB应用的JAR文件和WEB-INFlib目录。如果有几个EJB应用都要用到同一个工具类库，则在每一个JAR文件中放入该类库的一份拷贝就能解决问题。虽然这种方案实现了依赖库的热部署能力，但它明显地不够完善。封装JAR文件的目的是为了提高应用的模块化程度，把同一个类文件放入多个JAR包正好是背其道而行之。此外，多次复制同一组类无谓地加大了应用的体积。最后，即使只改变一个库，每一个JAR文件也都要重新构造，从而使构造