Introduction to the XL Deploy WebLogic plugin

The XL Deploy Oracle WebLogic server (WLS) plugin allows you to manage deployments and resources on a WebLogic server. It can deploy and undeploy application artifacts, as well as datasources and other JMS resources. You can easily extend the plugin to support more deployment options or management of new artifacts or resources on WebLogic.

For information about WebLogic requirements and the configuration items (CIs) that the plugin supports, refer to the WebLogic Plugin Reference.

Features

Deploy applications:

Enterprise application (EAR)

Web application (WAR)

Enterprise JavaBean (EJB)

J2EE Shared library

Staging modes:

Stage

NoStage

Deployment strategies:

Classical

Versioned

Side by side

Deploy resources:

Datasource

JMS Queue

JMS Topic

JMS uniform distributed Queue

JMS uniform distributed Topic

JMS connection factory

Mail Session

Persistence Store (file and JDBC)

Deploy files and folders

Discover middleware containers

Use in deployment packages

The WebLogic plugin works with the standard deployment package (DAR) format. The following is a sample deployit-manifest.xml file that can be used to create a WebLogic-specific deployment package. It contain declarations for an EAR file (wls.Ear), a datasource (wls.DataSourceSpec), and two JMS resources.

Deploying applications

You can influence the way an application is deployed to a container by modifying the properties of the corresponding deployed. For example, if an EAR file is to be deployed as a versioned application using nostage mode, you can specify these properties in the deployed EAR module (wls.EarModule):

retire timeout = Interval (in seconds) if a timeout period is needed to retire the previous version of the application

Note: If retired timeout is set to -1 and deployment strategy is set to SIDE_BY_SIDE, the WebLogic plugin handles retiring the versioned application and does not handle the application undeployment or the removal of artiacts.

Updating shared libraries

When updating a shared library (wls.SharedLibraryWarModule or wls.SharedLibraryJarModule), the plugin will query the repository to find all the applications (wls.Ear and wls.War, property sharedLibraries) that depends on it. For each of them, the plugins will add stop, undeploy, deploy, and start steps before and after the library update.

The wls.War and wls.Ear types have a SharedLibraries property whose default value could be set to {{SHARED_LIBRARIES}} in the deployment package. So a dictionary may contain the value and this value can be a list of configuration item IDs.

For example, a deployed EAR module wants to link two deployed shared libraries, libfoo and libbar. The target is a wls.Cluster (/Infrastructure/wlsDomain-103/cluster-1). The dictionary can be set up as follows:

Key

Value

SHARED_LIBRARIES

{{TARGET}}/libfoo,{{TARGET}}/libbar

TARGET

/Infrastructure/wlsDomain-103/cluster-1

Targeting multiple containers

Certain deployables can be targeted to multiple containers. For example, an EAR file can be targeted to two clusters. Similarly, a datasource can be targeted to two clusters.

Create steps

To handle multiple targets, the WebLogic plugin generates steps for each targeting. For example, if a datasource is targeted to Cluster-1 and Cluster-2, XL Deploy will create two datasource creation steps:

The first step will create the datasource on Cluster-1, with all the properties of the deployed datasource.

The second step will add Cluster-2 to the target list of the datasource created in first step. If there are difference in the datasource values of this deployed, it overrides the previous value.

Because the second targeting overrides the properties of the first targeting, ensure that the properties of the deployeds (of the same deployable) are uniform across each other.

Destroy steps

Similar to creation, the following sequence of steps occurs if destroy operation takes place for such a multiple targeted datasource:

The first step will remove Cluster-1 from datasource target’s list

The second step will remove Cluster-2 from datasource target’s list, and since the datasource has no target set on it, it destroys the datasource

Note that the actual datasource destruction takes place in the second step, and the first step simply removes the first container from datasource targets.

Deploy steps

When deploying wls.Ear, wls.War, wls.EjbJar, and shared library artifacts to multiple target servers, the WebLogic plugin will create a separate deployment step for each target server (by default). For example:

Deploy PetClinic-1.0.ear on wlserver-1

Deploy PetClinic-1.0.ear on wlserver-2

Multi-target deployment mode

The WebLogic also supports targeting multiple managed servers in one command by setting the dDeployment mode on the wls.Domain to MULTI_TARGET. In this case, the plugin will generate a deployment plan containing only one deployment step for all target servers in the domain. For example:

Deploy PetClinic-1.0.ear on wldomain: wlserver-1, wlserver-2

Creating resources

XL Deploy handles the creation of resources in the same way it handles deploying an application. If needed, you can trigger a restart by setting the restartTarget parameter to “true”.

Copying files

XL Deploy handles the copy of files targeted on a wls.Server or wls.Cluster. If needed, you can trigger a restart by setting the restartTarget parameter to true.

Managing JMS resources

The WebLogic plugin greatly simplifies the management of JMS resources by automatically managing JMS modules and sub-deployments needed for JMS resources, allowing you to focus on the actual JMS resource you need to manage.

For example, the followings is the sequence of steps that happens behind the scene when a JMS resource such as a queue is created:

You specify the JMS module name in a deployed resource (for example, the jmsModuleName property of wls.Queue)

The WebLogic plugin automatically creates the module if it is not present; otherwise, the plugin adds the deployed container to existing module targets

The WebLogic plugin automatically creates a subdeployment if is not present; otherwise the plugin adds the deployed container to existing sub-deployment targets

The WebLogic plugin creates/updates the JMS resource and assigns the sub-deployment created in the previous step as the resource sub-deployment

Similarly, the destruction of a JMS resource is handled as follows:

The resource container is removed from its sub-deployment targets

Destroy the JMS resource only if its sub-deployment targets list is empty (if it is the last one)