Configuring WebLogic Deployable Applications

This section describes the configuration steps required to configure a WebLogic Deployable Application when you're using the WebLogic plugin for Application Release Automation. This configuration is then used during deployment to create/modify the WebLogic Deployable Application.

A Domain can contain zero or more Deployable Applications; the creation of just one Application is shown here but this is easily extended to multiple Deployable Applications. The Jython variable deployableAppList is used by the plugin to pass the list of zero or more Deployable Applications to be created.

Before you begin

Open or create a new Jython environment-specific configuration file. This file will contain the configuration settings that will describe the WebLogic Deployable Application being created. Any change done to the properties in this file will be reflected in the Deployable Application created/modified by the tool.

About this task

This task creates the minimum set required for the creation of a WebLogic Deployable Application.

Procedure

A pre-requisite is that the configuration for a Domain, AdminServer, and at least one Managed Server or Cluster have already been completed in the Jython file. There can be multiple Deployable Applications and we will show afterwards how a list of them is created.

Change the required set of parameters in the dictionary structure of the Deployable Application template copy using the information in the table below and respecting the Jython syntax. The parameters set will reflect the Deployable Application configuration that you want to create. Once the Deployable Application properties are set, the instance has to be added to the deployableAppList list so it is eligible for creation. The list is what is read by the tool.

Variable Description Valid values Default value
appName Name of the application or standalone J2EE module to be deployed. String examplesWebApp
path Name of the application directory, archive file, or root of the exploded archive directory to be deployed. String j2ee/examplesWebApp.war
targets Comma-separated list targets. Each target may be qualified with a J2EE module name (for example, module1@server1) enabling you to deploy different modules of the application archive on different servers. String GenericCluster
createPlan Boolean value indicating the user would like to create a default Deployment Plan. true, false false
planPath Path to the Deployment Plan file (plan.xml) to be used. It can can be absolute or relative to the project archive root. This file will be copied to the Deployments directory, and the Deployment Plan folder has to be referenced inside this file. If createPlan is true, this field will be ignored and if createPlan is false, and this field is not set, no Deployment Plan is used. String j2ee/plan.xml
deployableAppList = [deployableAppList_1,]

Deployment Plan

The deployment plan file is always in the same path, and this will be the path referenced by the deployed application:

@@wlsDomainRoot@@/Deployments/@@appName_1@@Plan/plan.xml

If you set a deployment plan file in the @@appPlanPath_1@@ property, what it actually does is to copy the content of the file you've set to the path shown above.

Let's expose the different cases:

createPlan planPath Explanation
false '' (unset) Nothing is done.
true '' (unset) A default plan.xml file is created in the plans path.
false 'j2ee/plan.xml' (as an example) The content of the file set is copied to the plans path.
true 'j2ee/plan.xml' (as an example) A default plan.xml file is created in the plans path. And this is why the planPath variable is ignored.

Example

The example below shows the configuration required to create a new Deployable Application with values taken from the dictionary file.

deployableAppList_1 = {'appName' : '@@appName_1@@', 'path' : '@@appPath_1@@', 'targets' : '@@appTargets_1@@', 'createPlan' : '@@appCreatePlan_1@@', 'planPath' : '@@appPlanPath_1@@'}

Different version deployment

If you want to deploy a different version of an already deployed web application what you need is to declare the different version in the MANIFEST.MF file in the META-INF folder in the application archive. It's important that the deployed application also had a version defined in its MANIFEST.MF file. This next example shows the way of declaring the version:

Weblogic-Application-Version: v3-alpha

In this case, the version is v3-alpha.

The version string can be a maximum of 215 characters long, and must consist of valid characters such as: a-z, A-Z, 0-9, period ("."), underscore ("_"), or hyphen ("-") in combination with other characters.

For further information, pleas check the Oracle documentation for Redeploying Applications in a Production Environment.

What to do next

You can now configure the other Domain objects, such as WebLogic DataSources, JMSResources and so on.