1. Using Oracle WebLogic Server Multitenant (Deprecated)
  2. Deploying Applications

11 Deploying Applications

Deploying applications and modules in a multitenant environment is similar to deploying them in non-multitenant environments. To make deployments partition-specific, you can restrict them to a partition scope and override their configuration by specifying partition-specific deployment plans.

Note:

Many new Oracle WebLogic Server Multitenant (MT) features, such as resource groups, resource group templates, and application overrides, are also available in the 12.2.1 and later versions of WebLogic Server. This chapter refers to the WebLogic Server documentation where appropriate for these features.

Note that WebLogic Server Multitenant domain partitions, resource groups, resource group templates, virtual targets, and Resource Consumption Management are deprecated in WebLogic Server 12.2.1.4.0 and will be removed in the next release.

This chapter includes the following sections:

About Deployment Scopes

Three deployment scopes make applications and libraries available at the domain level, whereas only one restricts them to a partition.

  • Global. This is the equivalent of the domain level in a nonpartitioned environment.

  • Resource group template. This is always at the domain level. Whether or not the application or library that you deploy to a resource group template is available at the domain level or a partition depends on the scope of the resource group that references the resource group template.

  • Resource group in a partition. This is the only scope that is limited to a partition.

  • Resource group at the domain level.

For more information about deployment scopes, see About Scope.

Deploying Applications to Resource Group Templates

You can deploy a common set of applications and libraries to resource group templates to simplify application configuration across a domain or domain partitions. When a resource group references a resource group template, it obtains its own runtime copies of the resources defined in the template. All the applications and libraries deployed to the resource group template then deploy to the resource group.

Resource group templates provide a convenient way to deploy the same collection of applications across multiple domain partitions. To customize application configuration, you can override the default resource group template configuration by specifying a different deployment plan for a particular application in a resource group.

For general information about deploying applications to resource group templates, including information about supported deployment operations and available deployment clients, see Application Deployment with Resource Group Templates in Deploying Applications to Oracle WebLogic Server.

Deploying Applications to Resource Group Templates: Main Steps

Only WebLogic Server system administrators can deploy applications and libraries to a resource group template. The main steps are as follows:

  1. Specify the resource group template in which you want to deploy the application or library.
  2. Specify the application or library name and directory path.
  3. If using a deployment plan, then specify the deployment plan path.
  4. (Optional) Specify additional deployment options. Do not specify the targets option, because the application uses the targets associated with the referencing resource group.

    After an application is deployed to a resource group template, you can perform additional deployment operations.

  5. Redeploy or update the application.

    When you update an application, you can specify that WebLogic Server redeploy the original archive file or exploded directory, or you can specify that WebLogic Server deploy a new archive file in place of the original one. You can also change the deployment plan associated with the application.

  6. Distribute the application.

    The distribute operation copies deployment files to the targets associated with the referencing resource groups (or the default targets at the partition level if no targets exist at the resource group level) and places the application in a prepared state. You can then start the application in administration mode so you can perform final testing without opening the application to external client connections or disrupting connected clients.

  7. Undeploy the application.

    The undeploy operation removes the application from the resource group template and the targets associated with the referencing resource groups.

You cannot start or stop applications deployed to a resource group template, because you must perform these operations from the resource group that references the resource group template.

Note:

After you perform a deployment operation for a resource group template, the operation is immediately carried out across all resource groups that reference the template. For example, if you undeploy an application from a resource group template, then the application is undeployed from all resource groups that reference that resource group template.

To deploy applications to a resource group template using Fusion Middleware Control, see Configure resource group template deployments in the online help.

Deploying Applications to Resource Group Templates: Examples

The following examples demonstrate how to perform deployment operations with resource group templates using WLST.

Deploying Applications to Resource Group Templates: WLST Example

The following example deploys the sampleapp application to the resource group template myRGT: 

edit()
startEdit()
deploy(appName='sampleapp', path='path_to_application', resourceGroupTemplate='myRGT')
activate()
Redeploying Applications to Resource Group Templates: WLST Example

The following example redeploys the sampleapp application to the resource group template myRGT using the deployment plan file plan.xml: 

edit()
startEdit()
redeploy(appName='sampleapp', planPath='path_to_plan.xml', resourceGroupTemplate='myRGT')
activate()
Undeploying Applications from Resource Group Templates: WLST Example

The following example undeploys the sampleapp application from the resource group template myRGT: 

edit()
startEdit()
undeploy (appName='sampleapp', resourceGroupTemplate='myRGT')
activate()
Updating Applications in Resource Group Templates: WLST Example

The following example updates the sampleapp application in the resource group template myRGT using the deployment plan file plan.xml: 

edit()
startEdit()
updateApplication(appName='sampleapp', planPath='path_to_plan.xml', resourceGroupTemplate='myRGT')
activate()
Distributing Applications to Resource Group Templates: WLST Example

The following example distributes the sampleapp application to the resource group template myRGT: 

edit()
startEdit()
distributeApplication (appPath='path_to_sampleapp', resourceGroupTemplate='myRGT')
activate()

Deploying Applications to Resource Group Templates: Related Tasks and Links

Deploying Applications to Partition Resource Groups

You can deploy applications and libraries to resource groups at the domain or partition level and perform deployment operations on those applications, including start and stop. Resource groups conveniently group together Java EE applications and their resources into a distinct administrative unit and can be defined at the domain level, or be specific to a domain partition. A resource group can either contain resources directly or reference a resource group template containing the resources.

The resources and applications in a resource group are fully qualified in that you provide all the necessary information to start or connect to those resources. All of the applications deployed to a resource group use the targets associated with that resource group.

Partition resource groups allow each partition to contain a different set of resources and applications. You can perform the following deployment operations for applications and libraries with partition resource groups:

  • Deploy

  • Undeploy

  • Redeploy

  • Update

  • Distribute

  • Start

  • Stop

If the operation succeeds, then the application or library deploys (or redeploys, starts, or so forth) to the targets associated with the specified partition resource group. If no targets exist for the partition resource group, then the application or library deploys to the default targets for the partition.

Note the following considerations for application deployment with partition resource groups:

  • When performing deployment operations, you specify the partition name with the partition option. The specified partition must exist or the operation fails.

  • Application names must be unique within each partition.

  • For deploy and distribute operations, you must specify the partition resource group name with the resourceGroup option, unless one and only one resource group exists in the partition, in which case, resourceGroup is optional.

    For other deployment operations, you do not specify the resourceGroup option. WebLogic Server derives the resource group from the partition name and unique application name. If the specified partition resource group does not exist, or you do not specify the resourceGroup option if required, then the deployment operation fails.

  • The deployment operation fails if you specify the targets option when performing deployment operations for applications at the resource group level. You cannot target individual applications in the resource group, because applications use the targets associated with the resource group.

  • You can deploy a specific library to a partition only once, because resources need to be unique across resource groups of a partition. Applications in the same partition resource group or other resource groups in the partition can reference the library if the targets match. Applications deployed to a partition cannot reference a library in another partition or another library in the domain.

  • Resource groups can inherit application configuration from a resource group template. If a resource group references a resource group template, then any applications or libraries deployed to the resource group template immediately deploy to the referencing resource group. If needed, you can override the default resource group template application configuration to customize a particular application in a resource group. See Overriding Application Configuration.

  • Partition administrators can use WLST to perform deployment operations only on applications in their own partitions, not on global applications or applications in other partitions. The partition option is optional for partition administrators. If partition administrators use the partition option to specify a partition, and the partition does not match their associated partition, then the operation fails. For more information about deploying applications as a partition administrator using WLST, see Configuring Security.

For information about deploying applications to domain resource groups, see Application Deployment with Domain Resource Groups in Deploying Applications to Oracle WebLogic Server.

Deploying Applications to Partition Resource Groups: Main Steps

The main steps for deploying applications and libraries to a resource group in a partition are as follows:

  1. Specify the partition resource group in which you want to deploy the application or library.
  2. Specify the application or library name and directory path.
  3. If you are using a deployment plan, then specify the deployment plan path.
  4. (Optional) Specify additional deployment options. Do not specify the targets option, because the application uses the targets associated with the resource group. If no targets exist for the resource group, then the application uses the default targets for the partition.

    After an application is deployed to a resource group, you can perform additional deployment operations.

  5. Start or stop the application.

    Starting an application or module makes it available to WebLogic Server clients. Stopping an application or module makes it unavailable to WebLogic Server clients until you restart it.

  6. Redeploy or update the application.

    When you update an application, you can specify that WebLogic Server redeploy the original archive file or exploded directory, or you can specify that WebLogic Server deploy a new archive file to replace the original one. You can also change the deployment plan associated with the application.

  7. Distribute the application.

    The distribute operation copies deployment files to the targets associated with the resource group (or the default targets at the partition level if no targets exist at the resource group level) and places the application in a prepared state. You can then start the application in administration mode so you can perform final testing without opening the application to external client connections or disrupting connected clients.

  8. Undeploy the application.

    The undeploy operation removes the application from the resource group and the targets associated with the resource group.

To deploy applications to a partition resource group using Fusion Middleware Control, see Control domain partition application deployments in the online help.

Deploying Applications to Partition Resource Groups: Examples

The following examples demonstrate how to perform deployment operations to partition resource groups using WLST.

Deploying Applications to Partition Resource Groups: WLST Example

The following example deploys the sampleapp application to the resource group myRG in the partition myPartition: 

edit()
startEdit()
deploy(appName='sampleapp', partition='myPartition', resourceGroup='myRG', path='path_to_application')
activate()
Redeploying Applications to Partition Resource Groups: WLST Example

The following example redeploys the sampleapp application to the partition myPartition using the deployment plan file plan.xml.

You do not need to specify the partition resource group, because WebLogic Server derives the resource group from the unique application name and partition name.

edit()
startEdit()
redeploy(appName='sampleapp', planPath='path_to_plan.xml', partition='myPartition')
activate()
Undeploying Applications from Partition Resource Groups: WLST Example

The following example undeploys the sampleapp application from the partition myPartition.

You do not need to specify the partition resource group, because WebLogic Server derives the resource group from the unique application name and partition name.

edit()
startEdit()
undeploy (appName='sampleapp', partition='myPartition')
activate()
Updating Applications in Partition Resource Groups: WLST Example

The following example updates the sampleapp application in the partition myPartition using the deployment plan file plan.xml.

You do not need to specify the partition resource group, because WebLogic Server derives the resource group from the unique application name and partition name.

edit()
startEdit()
updateApplication(appName='sampleapp', planPath='path_to_plan.xml', partition='myPartition')
activate()
Distributing Applications to Partition Resource Groups: WLST Example

The following example distributes the sampleapp application to the resource group myRG in the partition myPartition: 

edit()
startEdit()
distributeApplication (appPath='path_to_sampleapp', resourceGroup='myRG', partition='myPartition')
activate()
Starting Applications on Partition Resource Groups: WLST Example

The following example starts the sampleapp application on the partition myPartition.

You do not need to specify the partition resource group, because WebLogic Server derives the resource group from the unique application name and partition name.

edit()
startEdit()
startApplication (appName='sampleapp', partition='myPartition')
activate()
Stopping Applications on Partition Resource Groups: WLST Example

The following example stops the sampleapp application on the partition myPartition.

You do not need to specify the partition resource group, because WebLogic Server derives the resource group from the unique application name and partition name.

edit()
startEdit()
stopApplication (appName='sampleapp', partition='myPartition')
activate()

Deploying Applications to Partition Resource Groups: REST Example

For an example of a partition user in the Deployer role deploying applications using the Representational State Transfer (REST) APIs, see Deploying Partition-Scoped Applications in Administering Oracle WebLogic Server with RESTful Management Services.

Deploying Applications to Partition Resource Groups: Related Tasks and Links

Deploying Applications as the Partition Administrator

Partition administrators can perform deployment operations only on applications in their own partition, not on global applications or applications from other partitions. Likewise, they can call deployment APIs only on applications in their partition. When calling deployment APIs that return a list of applications or targets, only applications and targets in their partition will be returned.

WebLogic Server system administrators can deploy applications to partitions on behalf of partition administrators. When using the JMX API to deploy applications in a partition, you must obtain the DeploymentManagerMBean instance under the relevant partition (instead of using the domain-level DeploymentManagerMBean instance). The following examples show how system administrators and partition administrators perform deployment operations in a partition using the JMX Deployment API.

  • When a system administrator connects to a global domain (for example, t3://localhost:7001):

    • The JMX lookup must include DomainPartitionRuntime=partition_name to get the DeploymentManagerMBean for the partition.

    • Using WLST, they must go to the partition's DomainPartitionRuntimeMBean to get the DeploymentManagerMBean for partition_name. For example: 

      connect('system_admin', 'gumby1234', 't3://localhost:7001')
domainRuntime()
cd('DomainPartitionRuntimes/partitionA')
cd('DeploymentManager/partitionA')
props=java.util.Properties()
props.setProperty("resourceGroup", "partitionAResourceGroup")
path="/scratch/user/foo.war"
cmo.deploy("foo", path, None, None, props)

  • When a partition administrator connects to a domain partition (for example, t3://localhost:7001/partitionA):

    • The JMX lookup does not need to include PartitionDomainRuntime=partitionA to get the DeploymentManagerMBean for partitionA. It is added by the JMX container.

    • Using WLST, running the domainRuntime() command sets the cmo to the DomainPartitionRuntimeMBean for the partition. 

      connect('partitionA_admin', 'password', 't3://localhost:7001/partitionA')
domainRuntime()
cd('DeploymentManager/partitionA')
props=java.util.Properties()
props.setProperty("resourceGroup", "partitionAResourceGroup")
path="/scratch/user/foo.war"
cmo.deploy("foo", path, None, None, props)

When using other deployment clients, the partition option is optional for partition administrators. Using weblogic.Deployer: 

java weblogic.Deployer -deploy -adminurl <partition_url> -username <partition_admin_user> -password <partition_admin_password> -name <application_name> path_to_application

For example:

java weblogic.Deployer -deploy -username partition1_admin -password password -adminurl t3://localhost:7001/partition1 -name foo /scratch/user/foo.war

Overriding Application Configuration

When a resource group references a resource group template, it obtains its own runtime copy of the resources and applications defined in the resource group template. Because the resource group inherits the application configuration defined in the resource group template, you do not need to manually deploy and configure each application. Applications and libraries deployed to a resource group template immediately deploy to the referencing resource group (or undeploy, redeploy, and so forth, depending on the performed deployment operation).

If you need to customize a particular application in a resource group, then you can override the default application configuration by specifying a different deployment plan. In that deployment plan, you override the resource group template deployment parameters with the values that you want to use for the particular application. The entire deployment plan file is overridden, not just an individual entry inside of the original deployment plan file. The application or module is then updated or redeployed using the new deployment plan for its application configuration instead of the values set in the resource group template.

Note:

If you undeploy an application from a resource group template, then any application configuration overrides defined in the referencing resource group are removed.

If you redeploy an application to a resource group template, then any application configuration overrides defined in the referencing resource group from the previous deployment of that application are removed. In this scenario, you must override the application configuration again for the resource group to preserve the override values.

Whether you update or redeploy the application to use the override deployment plan depends on the type of properties that you are overriding. Use the update command only when overriding dynamic properties; the update command does not cause any disruption to the application. Use the redeploy command when overriding dynamic and nondynamic properties; the redeploy command does cause disruption to the application.

You can override application configuration for resource groups at the domain or partition level. For information about overriding application configuration for domain resource groups, see Overriding Application Configuration in Deploying Applications to Oracle WebLogic Server.

Overriding Application Configuration: Main Steps

The main steps for customizing a particular application in a resource group by overriding the default application configuration defined in the inherited resource group template are as follows:

  1. Create a different deployment plan to use for the application that you want to customize.
  2. In the new deployment plan, define the values for the attributes that you want to override for that application.
  3. Specify the new override deployment plan when redeploying or updating the application.

The application now uses the override deployment plan for its configuration instead of the default template configuration.

If multiple resource groups reference the same resource group template, then ensure that you override the application configuration for all necessary resource groups.

Overriding Application Configuration: WLST Example

The following examples demonstrate:

  1. Deploying the application sampleapp to the resource group template myRGT using the deployment plan file plan.xml. 

    edit()
startEdit()
deploy(appName='sampleapp', resourceGroupTemplate='myRGT', path='path_to_application', planPath='path_to_plan.xml')
activate()

  2. Updating or redeploying the application sampleapp to use the override deployment plan override_plan.xml for the referencing partition resource group in the partition myPartition.

    You do not need to specify the partition resource group, because WebLogic Server derives the resource group from the unique application name and partition name.

    Use the update command only when overriding dynamic attributes for an application. Use the redeploy command when overriding dynamic or nondynamic attributes for an application. 

    edit()
startEdit()
updateApplication(appName='sampleapp', planPath='path_to_override_plan.xml', partition='myPartition')
activate()

edit()
startEdit()
redeploy(appName='sampleapp', planPath='path_to_override_plan.xml', partition='myPartition')
activate()

Overriding Application Configuration: Related Tasks and Links

  • Overriding Application Configuration in Deploying Applications to Oracle WebLogic Server for information about overriding application configuration at the domain level

  • Configuring Resource Overrides for information about overriding resource configuration, such as JMS and JDBC

  • Override application configuration in Administering Oracle WebLogic Server with Fusion Middleware Control for online help about overriding application configuration using Fusion Middleware Control

  • weblogic.Deployer Command-Line Reference in Deploying Applications to Oracle WebLogic Server for information about overriding application configuration using weblogic.Deployer

  • Deployment Commands in WLST Command Reference for WebLogic Server for information about overriding application configuration using WLST

  • wldeploy Ant Task Attribute Reference in Developing Applications for Oracle WebLogic Server for information about overriding application configuration using the wldeploy Ant task

  • Maven Plug-In Goals in Developing Applications for Oracle WebLogic Server for information about overriding application configuration using Maven

  • Understanding the WebLogic Deployment API for information about overriding application configuration using the JSR-88 Deployment API

  • DeploymentManagerMBean in MBean Reference for Oracle WebLogic Server for information about overriding application configuration using the JMX Deployment API

Removing an Application Override

If you no longer need to customize a particular application in a resource group, then you can remove an application override by removing the deployment plan containing the overridden attributes.

Then, the application configuration returns to its default configuration.

Removing an Application Override: Main Steps

The main steps for removing an application override from a resource group are as follows:

  1. Select the application containing the override.
  2. To remove existing overrides for dynamic attributes, update the application and specify the removePlanOverride option.
  3. To remove existing overrides for dynamic and nondynamic attributes, redeploy the application and specify the removePlanOverride option.

To remove an application override using Fusion Middleware Control, see Remove application configuration overrides in the online help.

Removing an Application Override: WLST Example

The following example redeploys the application sampleapp to remove an existing overridden deployment plan using the removePlanOverride option: 

edit()
startEdit()
redeploy(appName='sampleapp', removePlanOverride, partition='myPartition')
activate()

Removing an Application Override: Related Tasks and Links

Using Partition-Specific Deployment Plans

You can use partition-specific deployment plans to customize an application deployed to a resource group template or resource group within a partition. Partition-specific deployment plans are especially useful in environments with different partitions that share the same set of applications, but require some customization for each partition.

You specify partition-specific deployment plans at the resource group level within a partition, not at the partition level. When WebLogic Server applies a partition-specific deployment plan to a specified application, the changes prescribed by the plan affect only the application deployment within that partition.

Note:

If you specify an application deployment plan in a resource group template, and specify a partition-specific deployment plan for the same application, then the partition-specific deployment plan overrides the resource group template plan and the partition-specific deployment plan is used.

To specify partition-specific application deployment plans, use the redeploy or updateApplication WLST commands.

Using Partition-Specific Deployment Plans: Main Steps

The main steps for using partition-specific deployment plans are as follows:

  1. Create the partition-specific application deployment plan that you want to use.
  2. Use the redeploy or updateApplication WLST command to redeploy or update the application using the partition-specific deployment plan.

    Use the redeploy command when changes made to the application or module from the partition-specific deployment plan are nondynamic or dynamic. Use the updateApplication command only when the changes made to the application or module from the partition-specific deployment plan are dynamic.

  3. Identify the scope containing the application deployment for which you want to use the partition-specific deployment plan by specifying the corresponding WLST option:
    Scope WLST option

    resource group template

    resourceGroupTemplate

    domain resource group

    none

    You do not need to identify the resource group name for domain resource groups. Because application names must be unique within the domain, WebLogic Server derives the resource group from the application name.

    partition resource group

    partition

    You do not need to identify a resource group name for partition resource groups. Because application names must be unique within a partition, WebLogic Server derives the resource group from the application name and partition name.
  4. Use the WLST options planPath and appName to identify the partition-specific deployment plan location and the name of the application deployment to modify.
  5. Activate your changes.

    The specified application now uses the partition-specific deployment plan for its configuration.

Using Partition-Specific Deployment Plans: WLST Example

The following examples demonstrate:

  1. Deploying the application sampleapp to the resource group template myRGT. The partition myPartition references the resource group template myRGT. 

    edit()
startEdit()
deploy(appName='sampleapp', resourceGroupTemplate='myRGT', path='path_to_application')
activate()

  2. Updating or redeploying the application sampleapp to use the partition-specific deployment plan partition_plan.xml in partition myPartition.

    Use the update command only when changing dynamic attributes for an application. Use the redeploy command when changing dynamic or nondynamic attributes for an application. 

    edit()
startEdit()
updateApplication(appName='sampleapp', planPath='path_to_partition_plan.xml', partition='myPartition')
activate()

edit()
startEdit()
redeploy(appName='sampleapp', planPath='path_to_partition_plan.xml', partition='myPartition')
activate()

Using Partition-Specific Deployment Plans: Related Links and Tasks

Enabling Parallel Deployment in Multitenant Environments

Parallel deployment improves performance for use cases involving the deployment of multiple applications, the deployment of a single application with multiple modules, or the deployment of one or more applications across multiple partitions.

When an application is deployed to multiple partitions, WebLogic Server views each instance of the application as an independent application. Without parallel deployment enabled, each instance of the application is deployed to each partition sequentially.

To improve performance, you can enable parallel deployment so that the instances of the application deploy in parallel to each other:

  • To enable parallel deployment of applications across partitions, configure the ParallelDeployApplications attribute of the PartitionMBean.

    With this attribute enabled, applications with the same deployment order will deploy in parallel to each other. The partition-level setting overrides the domain-level setting for applications in a partition.

    The overall deployment order of resources and applications remains unchanged, so deployment types that precede applications in the standard deployment order (for example, JDBC system resources and Java EE libraries) are guaranteed to be fully deployed before applications are deployed.

  • To enable parallel deployment of modules within applications deployed in the partition, configure the ParallelDeployApplicationModules attribute of the PartitionMBean.

  • To enable parallel deployment of modules on a per-application basis, configure the ParallelDeployModules attribute of the AppDeploymentMBean. Setting this attribute overrides the domain and partition value for an individual application.

For domains created with WebLogic Server 12.2.1 or later, the ParallelDeployApplications and ParallelDeployApplicationModules attributes are enabled by default. For domains created prior to WebLogic Server 12.2.1, these attributes are disabled by default.

Note:

Only applications with no cross-dependencies should deploy in parallel. If an application depends on other applications, then this application needs to have a higher dependency order than the applications it depends on. Otherwise, parallel deployment may cause dependency failures when the dependent application attempts to deploy prior to the activation of applications on which it depends. Similarly, enable parallel deployment of modules only for applications that contain modules with no cross-dependencies.

For more information about parallel deployment, see Enabling Parallel Deployment for Applications and Modules in Deploying Applications to Oracle WebLogic Server.