The JBoss Deployer Architecture

JBoss has an extensible deployer architecture that allows you to incorporate components into the bare JBoss JMX microkernel. MainDeployer is the deployment entry point. Requests to deploy a component are sent to MainDeployer, which determines whether there is a subdeployer capable of handling the deployment; if there is, it delegates the deployment to the subdeployer. (You saw an example of this earlier in this chapter, when you looked at how MainDeployer uses the SARDeployer to deploy MBean services.) The following are some of the deployers provided with JBoss:

• AbstractWebDeployer This subdeployer handles WARs. It accepts deployment archives and directories whose names end with the .war suffix. WARs must have a WEB-INF/web.xml descriptor and may have a WEB-INF/jboss-web.xml descriptor.

• EARDeployer This subdeployer handles EARs. It accepts deployment archives and directories whose names end with the .ear suffix. EARs must have a META-INF/application.xml descriptor and may have a META-INF/jboss-app.xml descriptor.

• EJBDeployer This subdeployer handles Enterprise Bean JARs. It accepts deployment archives and directories whose names end with the .jar suffix. EJB JARs must have a META-INF/ejb-jar.xml descriptor and may have a META-INF/jboss.xml descriptor.

• JARDeployer This subdeployer handles library JAR archives. The only restriction it places on an archive is that it cannot contain a WEB-INF directory.

• RARDeployer This subdeployer handles JCA RARs. It accepts deployment archives and directories whose names end with the .rar suffix. RARs must have a META-INF/ra.xml descriptor.

• SARDeployer This subdeployer handles JBoss MBean SARs. It accepts deployment archives and directories whose names end with the .sar suffix, as well as standalone XML files that end with service.xml. SARs that are JARs must have a META-INF/jboss-service.xml descriptor.

• XSLSubDeployer This subdeployer deploys arbitrary XML files. JBoss uses XSLSubDeployer to deploy ds.xml files and transform them into service.xml files for SARDeployer. However, it is not limited to just this task.

• HARDeployer This subdeployer deploys HARs. It accepts deployment archives and directories whose names end with the .har suffix. HARs must have a META-INF/hibernate-service.xml descriptor.

• AspectDeployer This subdeployer deploys AOP archives. It accepts deployment archives and directories whose names end with the .aop suffix as well as aop.xml files. AOP archives must have a METAINF/jboss-aop.xml descriptor.

• ClientDeployer This subdeployer deploys J2EE application clients. It accepts deployment archives and directories whose names end with the .jar suffix. J2EE clients must have a META-INF/application-client.xml descriptor and may have a META-INF/jboss-client.xml descriptor.

• BeanShellSubDeployer This subdeployer deploys bean shell scripts as MBeans. It accepts files whose names end with the .bsh suffix.

MainDeployer, JARDeployer, and SARDeployer are hard-coded deployers in the JBoss server core. All other deployers are MBean services that register themselves as deployers with the MainDeployer by using the addDeployer(SubDeployer) operation.

MainDeployer communicates information about the component to be deployed to the SubDeployer by using a DeploymentInfo object. The DeploymentInfo object is a data structure that encapsulates the complete state of a deployable component.

When MainDeployer receives a deployment request, it iterates through its registered subdeployers and invokes the accepts(DeploymentInfo) method on the subdeployer. The first subdeployer to return true is chosen. The MainDeployer will delegate the init, create, start, stop, and destroy deployment life cycle operations to the subdeployer.

Deployers and Class Loaders

Deployers are the mechanism by which components are brought into a JBoss server. Deployers are also the creators of the majority of UCL instances, and the primary creator is MainDeployer. MainDeployer creates the UCL for a deployment early on during its init method. The UCL is created by calling the DeploymentInfo.createClassLoaders() method. Only the topmost DeploymentInfo actually creates a UCL. All subdeployments add their classpaths to their parent DeploymentInfo UCL. Every deployment does have a standalone URLClassLoader that uses the deployment URL as its path. This is used to localize the loading of resources such as deployment descriptors. Figure 2.20 provides an illustration of the interaction between deployers, DeploymentInfos, and class loaders.

Figure 2.20. The class loaders involved with an EAR deployment.

Figure 2.20 illustrates an EAR deployment with EJB and WAR subdeployments. The EJB deployment references the lib/util.jar utility JAR via its manifest. The WAR includes classes in its WEB-INF/classes directory as well as in WEB-INF/lib/jbosstest-web-util.jar. Each deployment has a DeploymentInfo instance that has a URLClassLoader pointing to the deployment archive. The DeploymentInfo associated with some.ear is the only one to have a UCL created. ejbs.jar and web.war DeploymentInfos add their deployment archives to the some.ear UCL classpath, and they share this UCL as their deployment UCL. The EJBDeployer also adds any manifest JARs to the EAR UCL.

The WARDeployer behaves differently than other deployers in that it only adds its WAR archive to the DeploymentInfo UCL classpath. The loading of classes from the WAR WEB-INF/classes and WEB-INF/lib locations is handled by the servlet container class loader. The servlet container class loaders delegate to the WAR DeploymentInfo UCL as their parent class loader, but the server container class loader is not part of the JBoss class loader repository. Therefore, classes inside a WAR are not visible to other components. Classes that need to be shared between web application components and other components such as EJBs and MBeans need to be loaded into the shared class loader repository either by including the classes in a SAR or EJB deployment or by referencing a JAR containing the shared classes through a manifest Class-Path entry. In the case of a SAR, the SAR classpath element in the service deployment serves the same purpose as a JAR manifest Class-Path.