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 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
.
|
