You can use the common deployment framework to add additional logic
to application management operations. The additional logic can do such tasks
as code generation, configuration operations, additional validation, and so
on. This topic demonstrates, through programming, how to plug into the common
deployment framework to extend application management operations.
Before you begin
This task assumes a basic familiarity with Java application programming
interfaces (APIs). Read about the Java APIs in the application programming
interfaces documentation.
Before you can extend application
management operations, you must first install WebSphere Application Server.
About this task
Use this example to extend application management through programming.
The tasks that the extensions provide are available through all the administrative
clients, such as the wsadmin tool, the administrative console, or through
programmatic APIs that the AppManagement MBean provides.
Procedure
- Define your extension as an Eclipse plug-in and add a plugin.xml file
to register your extension provider with the deployment framework.
- In the plugin.xml file, provide an extension provider
implementation class for the common-deployment-framework-extensionprovider
extension point.
- Put the plug-in Java archive (JAR) file in the plugins directory
of your WebSphere Application Server installation.
<?xml version="1.0" encoding="UTF-8"?>
<plugin
id=“com.ibm.myproduct.MyExtensionProvider”
name=“My Extension"
version="1.0.0">
<extension point=“common-deployment-framework-extensionprovider”>
<action class=“com.acme.MyExtendProviderImpl“/>
</extension>
</plugin>
- Provide an extension provider.
An extension provider
class provides steps for a given operation on an application Enterprise archive
(EAR) file. Before an operation runs, the deployment framework queries all
the registered extension providers for additional steps. A single list of
steps is passed to each provider. Each provider can add steps to the list.
The default provider that the deployment framework provides is called first
to populate the list with default steps. Other extension providers are called
next.
Various operations that you can extend through the common deployment
framework are defined as constants in the DeploymentConstants class. These
operations are described in the following table. Some operations are split
on multiple lines for printing purposes.
Table 1.
Operation |
Description |
DeploymentConstants.CDF_OP_INSTALLJ2EE |
Installs a Java 2 Platform, Enterprise Edition (J2EE)
EAR file |
DeploymentConstants.CDF_OP_EDITJ2EE |
Edits a deployment application configuration |
DeploymentConstants.CDF_OP_UPDATEJ2EE |
Applies a fine-grained update to an application such
as addition, removal, or update of a file or a module; or partial update of
an application |
DeploymentConstants.CDF_OP_UNINSTALLJ2EE |
Uninstalls a J2EE application |
DeploymentConstants.
CDF_OP_CREATE_EAR_WRAPPERJ2EE
|
Wraps the contents input to the application installation
into an EAR file |
The
AppManagement MBean, which is responsible for deploying and managing J2EE
applications on WebSphere Application Server, runs all the operations except
the CDF_OP_CREATE_EAR_WRAPPERJ2EE operation. Deploy the extensions that extend
these operations in the plugins directory of the deployment
manager.
Either the wsadmin utlity or the administrative console runs
the CDF_OP_CREATE_EAR_WRAPPERJ2EE operation when the input contents that are
supplied to the CDF_OP_INSTALLJ2EE operation are not packaged as an EAR file.
Deploy an extension that extends the CDF_OP_CREATE_EAR_WRAPPERJ2EE operation
in the plugins directory of the wsadmin installation.
The
following example provides an extension provider that does the following tasks:
- Adds two additional steps for the application installation operation
- Adds one step for wrapping input contents into an EAR file
package com.acme;
import com.ibm.websphere.management.deployment.registry.ExtensionProvider;
import com.ibm.websphere.management.deployment.core.DeploymentConstants;
public class MyExtensionProviderImpl extends ExtensionProvider {
public void addSteps (String type, String op, String phase,
List steps)
{
if (op.equals (DeploymentConstants.CDF_OP_INSTALLJ2EE))
{
// Add a code generation step.
steps.add (0, new com.acme.CodeGenStep());
// Add a configuration step.
steps.add (new com.acme.ConfigStep());
}
else if (op.equals (DeploymentConstants.CDF_OP_CREATE_EAR_WRAPPERJ2EE))
{
// Add an ear-wrapper step.
steps.add (new com.acme.EarWrapperStep());
}
}
}
- Provide the deployment step implementation.
An extension
provider adds a deployment step. The step contains logic that performs additional
processing in an application management operation. The logic provides the
step access to the deployment context and the deployable object. The deployment
context provides information, such as the name of the operation, the configuration
session ID, a temporary location for creating temporary files, operation parameters,
and so on. The deployable object wraps the deployment content input to the
operation. For example, the deployable object wraps the J2EE EAR file for
the installation operation or a file, a module, or a partial application for
the update operation.
The following example illustrates how an extension during installation
entirely changes an EAR file that is input to the installation operation.
The example provides a deployment step during the installation operation that
does the following tasks:
- Runs code generation to generate a new EAR file.
- Calls the setContentPath method in the DeployableObject class to set the
new EAR file path. The default installation logic, such as steps that the
default installation logic adds, uses this new EAR file for installation in
the configuration repository.
package com.acme;
import com.ibm.websphere.management.deployment.core.DeploymentStep;
import com.ibm.websphere.management.deployment.core.DeployableObject;
public class CodeGenStep extends DeploymentStep
{
public void execute (DeployableObject dObject)
{
EARFile earFile = (EARFile)dObject.getHandle();
String newEARPath = null;
// Use step specific logic to create another EAR file after code generation.
…
newEARPath = _context.getTempDir() + "new.ear";
dObject.setContentPath (newEARPath);
}
}
The following example provides a deployment step that:
- Reads the contents of the input EAR file.
- Manipulates the configuration session accessed through the context instance,
_context.
package com.acme;
public class ConfigStep extends DeploymentStep
{
public void execute (DeployableObject dObject)
{
EARFile earFile = (EARFile) dObject.getHandle();
// Use the following example code to perform the configuration.
String sessionID = _context.getSessionID();
com.ibm.websphere.management.Session session = new
com.ibm.websphere.management.Session (sessionID, true);
// Use the configuration service to perform the configuration steps.
…
// Read the application configuration.
Application appDD = earFile.getDeploymentDescriptor();
…
String newEARPath = null;
}
}
The following example provides a deployment step to wrap arbitrary
content around an EAR file. Application management logic accepts only the
EAR file for deployment. An extension is required if you want to input anything
other than an EAR file to the deployment process.
package com.acme;
import com.ibm.websphere.management.deployment.core.DeploymentStep;
import com.ibm.websphere.management.deployment.core.DeployableObject;
public class EarWrapperStep extends DeploymentStep
{
public void execute (DeployableObject dObject)
{
Archive archive = (Archive) dObject.getHandle();
String newEARPath = null;
// provide your logic to wrap the jar with the ear
…
newEARPath = //;
// Set the new ear path back into DeploymentContext
this.getContext().getContextData()
.put(DeploymentContext.RETURN_Object_key, newEARPath);
}
}
Results
Through programming, you have plugged into the common deployment framework
to extend application management operations.
What to do next
You can extend other application management operations, or do any
other administrative operations you choose.