JBoss Application Server的部署架构

         JBoss 的部署架构可以分为三个部分：热部署机制、部署的通用流程、部署的过程。

热部署机制，使得我们在不需要重启JBoss的情况下，可以增加、修改和删除部署单元。JBoss会在运行时“察觉”到这些变化，并做出相应的处理。

部署的通用流程，是一个对不同类型的部署单元都适用的部署过程。JBoss支持多种部署单元，包括jar格式的EJB组件、war格式的Web组件、ear格式的企业应用组件、sar格式的服务组件、har格式的hibernate应用等等。不同类型组件的部署过程是不同，但从宏观的角度看，它们还有一个通用的流程。

部署的过程，就是每种类型组件自己独特的部署操作。每种类型的组件都由一个特定的子部署器来完成部署过程。子部署器都是org.jboss.deployment.SubDeployer的子类。

部署单元可以是一个压缩包，也可能一个目录。JBoss使用DeploymentInfo对象来封装部署单元的相关信息，在部署的过程，对DeploymentInfo对象进行操作。

在这篇文章中，我将介绍热部署机制和部署的通用流程。由于可部署组件的类型太多，我就不一一介绍每种组件部署的过程。

首先，我先介绍部署的通用流程。

每种组件的部署都有三个阶段，依次是init、create和start。这三个阶段构成了部署的通用流程。整个流程由org.jboss.deployment.MainDeployer负责管理。MainDeployer作为一个MBean，在JBoss启动时被创建。部署一个组件，从调用MainDeploy的deploy方法开始。Deploy首先会调用MainDeploy的init方法，进入init阶段。如果这一阶段执行成功，则接着调用MainDeploy的create方法，进入create阶段。如果这一阶段也执行成功，则调用MainDeploy的start方法，进入start阶段。如果这一阶段也执行成功，那么整个部署就成功了。现在让我们看看MainDeploy在每个阶段都做了什么事情。

Init阶段：

首先，MainDeployer需要判断部署单元是否要被解压缩和拷贝到临时目录。一般来说，部署单元是被方法${JBOSS_HOME}/server/default/deploy目录下。如果部署单元是一个目录，那么就直接部署。如果部署单元是一个压缩包，就需要将它解压到${JBOSS_HOME}/server/

default/tmp/deploy。解压缩是可以理解的，为什么需要拷贝到临时目录呢？如果直接解压缩到deploy目录，那么JBoss就会将解压后的目录视为一个新的部署单元。这样，一个部署单元被部署两次，这是不可以的。

         然后，MainDeployer将为部署单元查找能够部署它的SubDeployer。例如，MainDeployer会为EJB组件找到EJBDeployer。所有的SubDeployer同MainDeployer一样，都是在JBoss启动时创建的。而且，每个SubDeployer都被注册到MainDeployer中，这样MainDeloyer就能找到它们。那么，MainDeployer是如何查找的呢？每种SubDeployer都会实现一个accepts方法，这个方法接收DeploymentInfo对象作为参数，并判断自己能不能部署它。如果能，返回true，否则返回false。MainDeployer就依次调用每个SubDeployer的accepts方法，MainDeplpyer将第一个返回true的SubDeployer，作为部署单元的SubDeployer。

         接着，MainDeployer将部署单元添加到部署等待队列中。这个队列的作用是，如果某个部署单元因为依赖关系不满足，而不能被部署，则将它暂存起来。但依赖关系满足时，MainDeployer就可以从等待队列中将它取出，并重新部署。

         再接着，MainDeployer将调用部署单元的SubDeployer的init方法，进行特定于组件类型的初始化工作。

         接着，MainDeployer为部署单元创建一个统一类加载器UCL，这个与JBoss的类加载器架构有关。

         再接着，MainDeployer读取MANIFEST.MF文件，如果有引用的jar，将它们作为子部署单元，添加到部署单元中。

         最后，调用MainDeployer.init方法（这是一个递归的过程），初始化所有的子部署单元。

 

         Create阶段：

         首先，调用MainDeployer.create方法，创建所有的子部署单元。

         然后，调用部署单元的SubDepoyer的create方法（这是一个递归的过程），进行特定于组件类型的创建工作。

        

         Start阶段：

         首先，调用MainDeployer.start方法，启动所有的子部署单元。

         然后，调用部署单元的SubDeployer的start方法（这是一个递归的过程），进行特定于组件类型的启动工作。

         最后，检查部署单元关联的所有MBean是不是都已经启动。如果没有的话，整个部署就失败了。

 

         下面，我再介绍一下热部署机制。热部署机制的实现是很比较复杂的，有很多技术问题需要解决。但是它的结构是很简单的。所有需要热部署的部署单元都方法deploy目录下，有一个专门监视该目录的线程，它定期扫描目录下的部署单元。如果有新的部署单元被添加进来，或者某个部署单元被删除掉，该线程就会通知MainDeloyer部署或销毁该部署单元。如果某个部署单元被修改，该线程就会通知MainDeployer充新部署该部署单元。该线程是通过文件的修改时间，来判断某个部署单元是否被修改。

         org.jboss.deployment.scanner.URLDeploymentScanner负责热部署的执行。它作为一个MBean，在JBoss启动时被创建。JBoss启动时，会调用它的createService方法。该方法又会其父类AbstractDeploymentScanner的createService方法。其父亲的createService方法会创建一个ScannerThread线程，这个线程每隔一段时间就会调用URLDeploymentScanner的scan方法。scan方法的工作就是检查deploy目录下的变化，并调用MainDeployer的相应方法来进行重新部署、销毁等操作。