JBoss uses the org.jboss.deployment.MainDeployer to deploy the various elements (EAR, JAR, SAR, ...). For each kind of deployed target, a specific deployer is defined. This deployer is a subclass of org.jboss.deployment.SubDeployerSupport.
The MainDeployer and SubDeployerSupport classes use the org.jboss.deployment.DeploymentInfo class to store information about the deployment. It contains information such as:
Every mobicents deployment starts by the DeploymentMBeanImpl. It is called (using JMX) by the client to deploy a DeployableUnit (using the "install" method). This will cause a DeploymentManager to be created and used to deploy the DeployableUnit (DU). This will copy the DU file locally, and then use a DeployableUnitDeployer to perform the actual deployment.
The 'deploy' static method creates a DeployableUnitDeployer, initializes it, and then 'deployUnitContent'.
The 'deployUnitContent' is where the actual deployment starts. First, the "deployable-unit.xml" file is parsed. For each JAR file indicated in the deployement descriptor, an instance of AbstractComponentDeployer. The actual instance created depends on the type of component being deployed.
The different types of AbstractComponentDeployer are:
The deployment of the various elements is done in several steps. First, all the EventTypeComponentDeployer are called, and then the others are called. Finally, ServiceDeployers are created for all the <service> tags.
Each sub-deployer is first initialized (initDeployer) and then deployAndInstall is called.
The 'initDeployer' method is in charge of parsing the XML descriptor to create. The parsing is performed by a specific parser (XXXXDeploymentDescriptorParser) and will create a list of XXXXDescriptorImpl instances.
The 'deployAndInstall' method is in charge to extract the JAR contents into the classpath. It then takes all the XXXXDescriptorImpl instances and casts them as DeployedComponent. Each is then checked (DeployedComponent.checkComponent()) and then installed using the SleeContainer's install(DeploymentComponent) method.
TODO: explain this - install(DeployedComponent) method - all the DeployableUnit-related methods
This class is the implementation of the DeploymentMBean, which is accessed via JMX to install a new DeployableUnit (DU). It delegates all the DeployableUnit related methods to the DeployableUnitManager class.
The DeployableUnitManager handles everything that relates to DeployableUnits. It keeps tracks of all the DeployableUnits. It implements the following methods of the DeploymentMBean:
Note: Part of this API was implemented by SleeContainer before. It is centralized in the DeployableUnitManager, which makes the SleeContainer simplier.
To install the DU, the DeployableUnitManager uses the standard JBoss mechanism by calling the MainDeployer 'deploy' method.
JNG: For the uninstall, need to define exactly how it is going to be implemented. Start with MainDeployer.undeploy
The MainDeployer is used as is. The only thing is that new SubDeployers are registered to handle all the SLEE deployment features. All those SubDeployers inherit from AbstractSleeDeployer.
Those deployers are installed in JBoss via the jboss-service.xml file in the jboss-slee.sar. TODO: detail more here
This class (subclass of SubDeployerSupport) provides common features to all the deployers:
The org.jboss.deployment.DeploymentInfo is central to JBoss's deployment architecture as it holds all the information about a deployment. Here is a table rassembling information about each field of DeploymentInfo and how it is used in the particular case of Mobicents. When the field is used exactly the same way as in JBoss, the indication "Standard JBoss" is used.
Field Name | Description |
url | URL used for the deployment. This is basically the one provided when deploying. (Standard JBoss) |
localUrl | URL of the local copy of the deployed target. (Standard JBoss) |
watch | This contains the URL that will be watched to know if the target has changed and should be redeployed. QUESTION: What is the behavior we want here ? I suppose that at best, only the DeployableUnit.jar should be watched (when expanded directory, watching the META-INF/deployable-unit.xml). However, this may not be a good idea so your input is welcome. For other types of deployers, I think it would be better not to allow redeployment (no watch) |
shortName | Short name of the file containing the deployed target. (Standard JBoss) |
lastDeployed | TODO: give a little explaination (self explainatory) (Standard JBoss) |
lastModified | TODO: give a little explaination (self explainatory) (Standard JBoss) |
status | String indicating the current status of the deployment. This can contain some text description. (Standard JBoss) |
state | Field indicating the current state of the deployment. (Standard JBoss) |
deployer | Deployer that is associated with this deployment. Depending on the type of the component deployed, this will vary. (Standard JBoss) |
ucl | UnifiedClassLoader. TODO: get a better understanding of the UCL for the various components |
localCl | URLClassLoader that is used for metadata loading (the XML files). It is (always ???) based on di.localUrl and is setup by the JBoss standard mechanisms. This is the ClassLoader that needs to be used when parsing the XML files to generate the XXXXDescriptorImpl instances. |
classpath | TODO: explain how it works and how it will be used |
mbeans | TODO: explain how it works and how it will be used |
subdeployments | This contains the subdeployments associated with this deployment.
This is only used by the DeployableUnitDeployer to contain the DeploymentInfo
for all the components in the DU.
For all the other deployers, this will not contain anything as there are no subdeployments. |
parent | DeploymentInfo of the parent deployment. This is null for the DeployableUnitDeployer (because it is the root deployer). For the other deployers, this is the DeploymentInfo associated with the DeployableUnitDeployer. |
webContext | This is null (no Web context for any SLEE deployment) |
manifest | TODO: will probably be needed in order to be able to reference JARs as 'Class-Path:' in the Manifest (see 3.1.9, page 27) |
document | DOM Document of the XML file of the deployment. QUESTION: should it be the "official" XML file (standard) or the Mobicents one ? (just like ejb-jar.xml and jboss.xml) |
documentUrl | TODO: See how this is used |
metaData | This is where JBoss stores all the metadata that was parsed from the XML
descriptors. The deployers will put here the XXXXDescriptorImpl instances
produced by the XXXXDeploymentDescriptorParser.
TODO: see if should be directly the XXXXDescriptorImpl instances or if it should be in a List (if there are several) |
context | TODO: See how this is used |
isXML | Indicates whether the deployed target is an XML file. (Standard JBoss) |
isScript | Indicates whether the deployed target is a script (.bsh file). (Standard JBoss) |
isDirectory | Indicates whether the deployed target is a directory. (Standard JBoss) |
deployedObject | TODO: See how this is used |
repositoryConfig | This is the configuration to define the classes repository used with the UnifiedClassLoader. TODO: See how this is used |
server | MBeanServer used for JMX operations. (Standard JBoss) |
Concrete class generation is done using Javassist API. The implementation relies on a ClassPool instance to provide representations of classes (CtClass objects).
In order for this generation code to work properly, it is important that the lifecycle of the ClassPool object is related to the lifecycle of a DeployableUnit. When the DU is uninstalled and reinstalled, a new ClassPool should be used in order to have the new version of the classes available.
TODO: see where to store the ClassPool object (how about in the 'context' field of the DeploymentInfo ?)