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 version of WebLogic Server. This chapter refers to the WebLogic Server documentation where appropriate for these features.
This chapter includes the following sections:
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.
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.
Only WebLogic Server system administrators can deploy applications and libraries to a resource group template. The main steps are as follows:
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.
The following examples demonstrate how to perform deployment operations with resource group templates using WLST.
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()
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()
The following example undeploys the sampleapp
application from the resource group template myRGT
:
edit() startEdit() undeploy (appName='sampleapp', resourceGroupTemplate='myRGT') activate()
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()
Configuring Resource Group Templates for general information about resource group templates
Application Deployment with Resource Group Templates in Deploying Applications to Oracle WebLogic Server for general information about deploying applications to resource group templates
Application Deployment in Administering Oracle WebLogic Server with Fusion Middleware Control for online help about deploying applications using Fusion Middleware Control
WebLogic Server Resource Group Templates in Administering Oracle WebLogic Server with Fusion Middleware Control for online help about configuring resource group templates using Fusion Middleware Control
weblogic.Deployer Command-Line Reference in Deploying Applications to Oracle WebLogic Server for information about deploying applications using weblogic.Deployer
Deployment Commands in WLST Command Reference for WebLogic Server for information about deploying applications using WLST
wldeploy Ant Task Attribute Reference in Developing Applications for Oracle WebLogic Server for information about deploying applications using the wldeploy
Ant task
Maven Plug-In Goals in Developing Applications for Oracle WebLogic Server for information about deploying applications using Maven
Understanding the WebLogic Deployment API for information about deploying applications using the JSR-88 Deployment API
DeploymentManagerMBean
in MBean Reference for Oracle WebLogic Server for information about deploying applications using the JMX Deployment API
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.
The main steps for deploying applications and libraries to a resource group in a partition are as follows:
To deploy applications to a partition resource group using Fusion Middleware Control, see Control domain partition application deployments in the online help.
The following examples demonstrate how to perform deployment operations to partition resource groups using WLST.
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()
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()
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()
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()
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()
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()
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()
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.
Configuring Domain Partitions for general information about partitions
Configuring Resource Groups for general information about resource groups
Application Deployment with Domain Resource Groups in Deploying Applications to Oracle WebLogic Server for information about deploying applications to resource groups at the domain level
Application Deployment in Administering Oracle WebLogic Server with Fusion Middleware Control for online help about deploying applications using Fusion Middleware Control
WebLogic Server Domain Partitions in Administering Oracle WebLogic Server with Fusion Middleware Control for online help about configuring partitions using Fusion Middleware Control
WebLogic Server Resource Groups in Administering Oracle WebLogic Server with Fusion Middleware Control for online help about configuring resource groups using Fusion Middleware Control
weblogic.Deployer Command-Line Reference in Deploying Applications to Oracle WebLogic Server for information about deploying applications using weblogic.Deployer
Deployment Commands in WLST Command Reference for WebLogic Server for information about deploying applications using WLST
wldeploy Ant Task Attribute Reference in Developing Applications for Oracle WebLogic Server for information about deploying applications using the wldeploy
Ant task
Maven Plug-In Goals in Developing Applications for Oracle WebLogic Server for information about deploying applications using Maven
Understanding the WebLogic Deployment API for information about deploying applications using the JSR-88 Deployment API
DeploymentManagerMBean
in MBean Reference for Oracle WebLogic Server for information about deploying applications using the JMX Deployment API
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', 'welcome1', '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 welcome1 -adminurl t3://localhost:7001/partition1 -name foo /scratch/user/foo.war
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.
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:
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.
The following examples demonstrate:
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()
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 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
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.
The main steps for removing an application override from a resource group are as follows:
removePlanOverride
option.removePlanOverride
option.To remove an application override using Fusion Middleware Control, see Remove application configuration overrides in the online help.
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 in Deploying Applications to Oracle WebLogic Server for information about removing an application override at the domain level
Configuring Resource Overrides for information about overriding resource configuration, such as JMS and JDBC
Remove application configuration overrides in Administering Oracle WebLogic Server with Fusion Middleware Control for online help about removing application overrides using Fusion Middleware Control
weblogic.Deployer Command-Line Reference in Deploying Applications to Oracle WebLogic Server for information about removing application overrides using weblogic.Deployer
Deployment Commands in WLST Command Reference for WebLogic Server for information about removing application overrides using WLST
wldeploy Ant Task Attribute Reference in Developing Applications for Oracle WebLogic Server for information about removing application overrides using the wldeploy
Ant task
Maven Plug-In Goals in Developing Applications for Oracle WebLogic Server for information about removing application overrides using Maven
Understanding the WebLogic Deployment API for information about removing application overrides using the JSR-88 Deployment API
DeploymentManagerMBean
in MBean Reference for Oracle WebLogic Server for information about removing application overrides using the JMX Deployment API
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.
The main steps for using partition-specific deployment plans are as follows:
The following examples demonstrate:
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()
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()
Configuring Resource Overrides for information about overriding resource configuration, such as JMS and JDBC
Deployment Commands in WLST Command Reference for WebLogic Server for information about removing application overrides using WLST
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.