10 Configuring Resource Overrides

This chapter describes resource overrides and how to configure them. You can use Fusion Middleware Control (FMWC), the WLS Administration Console, or WLST to configure resource overrides, as described in this chapter. The chapter refers to the Fusion Middleware and WebLogic Server documentation sets and online help for additional information as appropriate.

This chapter includes the following sections:

Resource Overrides: Overview

Resource overriding allows administrators to customize resources at the partition level. If you create a partition with a resource group that extends a resource group template, you can override settings for certain resources defined in that resource group template. If you create a resource group within the partition that does not extend a resource group template and then create resources within this resource group, you don't need overrides; you can just set partition-specific values for these resources. Overrides are used mainly when there is a common definition for the resource, such as in a resource group template.

Resource group templates are particularly useful in SaaS environments where WebLogic Server Multitenant activates the same applications and resources multiple times, once per domain partition. Some of the information about such resources is the same across all domain partitions, while some of it, such as JMS queues and database connections, varies from one partition to the next. For example, you would need to customize the URL, user name, and password used to connect to a data source among different partitions.

Administrators can override resource definitions in partitions using the following techniques:

  • Resource override configuration MBeans—a configuration MBean which exposes a subset of attributes of an existing resource configuration MBean. Any attribute set on an instance of an overriding configuration MBean will replace the value of that attribute in the corresponding resource configuration MBean instance.

  • Resource deployment plans—an XML file which identifies resources within a partition and overrides attribute settings on those resources.

  • Partition-specific application deployment plans—similar to application deployment plans, it allows administrators to specify a partition-specific application deployment plan for each application deployment in a partition. For information about partition-specific application deployment plans, see Using Partition-Specific Deployment Plans.

Administrators can combine any of these resource overriding techniques. The system applies them in the following, ascending order of priority:

  • config.xml and external descriptors, including partition-specific application deployment plans

  • Resource deployment plans

  • Overriding configuration MBeans

    If an attribute is referenced by both a resource deployment plan and an overriding configuration MBean, the overriding configuration MBean takes precedence.

Using Configuration MBean Overrides

Overriding configuration MBeans allow you to customize "frequently-tailored" attributes, such as the attributes of a JMS queue or of a DB connection. An attribute in an overriding configuration MBean might override the config.xml settings for the resource or it might override a setting from the resource's external descriptor, depending on where the attribute resides.

In this release, WebLogic Server MT provides the following resource override configuration MBeans:

  • JDBCSystemResourceOverrideMBean

  • JMSSystemResourceOverrideMBean

  • ForeignServerOverrideMBean

  • ForeignConnectionFactoryOverrideMBean

  • ForeignDestinationOverrideMBean

  • MailSessionOverrideMBean

Resource configuration override MBeans typically work by matching the name of the overriding configuration MBean with the name of the resource MBean. For more information, see Configuring Resource MBean Overrides: Main Steps and WLST Examples.

Using Resource Deployment Plans

A resource deployment plan is an XML file that overrides attributes for one or more resources within a single partition. Each partition can have at most one resource deployment plan which can override any resources in that partition. This includes resources defined in resource group templates to which the partition's resource groups refer as well as resources declared directly in the resource groups.

When a server restarts, changes to non-dynamic attributes from the resource deployment plan (and from overriding configuration MBeans), will be applied before the resource is active. Once a given resource is running, changes to the resource deployment plan that would affect non-dynamic attributes of that resource will not take effect until the partition is restarted.

Resource deployment plans can be used to with the following resources to override options that are configured in config.xml or external descriptor files:

  • CoherenceClusterSystemResource

  • FileStore

  • ForeignJNDIProvider

  • JDBCStore

  • JDBCSystemResource

  • JMSBridgeDestination

  • JMSServer

  • JMSSystemResource

  • MailSession

  • ManagedExecutorService

  • ManagedScheduledExecutorService

  • ManagedThreadFactory

  • MessagingBridge

  • PathService

  • SAFAgent

  • WLDFSystemResource

resource-deployment-plan Syntax

Resource deployment plans are based on the weblogic-resource-deployment-plan.xsd file and possess a similar syntax to WebLogic Server application deployment plans. Resource deployment plans identify the resource and attribute values to be changed; they support replacing values, adding new ones, and removing existing ones.

The following is a summary of the resource-deployment-plan syntax:

resource-deployment-plan (@global-variables)
  description
  version
  variable-definition
    variable*
      name
      value
  external-resource-override*
    resource-name
    resource-type
    root-element
    variable-assigment*
      name
      xpath
  config-resource-override*
    resource-name
    resource-type
    variable-assigment*
      name
      xpath
      operation

The @ symbol indicates an XML attribute, an asterisk (*) means the element can be repeated. The operation element is optional but allowed in any variable-assignment, whether in an external-resource-override or a config-resource-override.

The basic elements in the resource deployment plan serve the following functions:

  • resource-deployment-plan is the root element; it encapsulates all of the resource deployment plan's contents.

  • variable-definition defines one or more variable elements. Each variable defines the name of a variable used in a plan and a value to assign (which can be null). The sample plan shown in Sample Resource Deployment Plan contains variable definitions for changes to the mail session user name, mail session JavaMail properties, and JDBC connection pool params, test table name properties.

  • Each external-resource-override and config-resource-override element (and their child elements) does these three things:

    1. Identifies the resource to affect (resource-name and resource-type).

      The resources in a partition must have unique names within the partition.

    2. Identifies where the attributes are defined.

      All the attributes in the config-resource-override element reside in the config.xml file. Attributes in the external-resource-override element are stored in external descriptor files. For resource deployment plans, the descriptor path is relative to the partition's config/ directory

    3. Specifies some number of attributes of that resource to override (variable-assignment elements).

      After the attributes for the resource are located, the variable-assignments are applied. An XPath expression tells where, relative to the identified resource's bean, the attribute to be affected appears in the bean tree. The name refers to a previously-defined variable definition. That variable also sets the value that should replace whatever is in the original attribute setting.

      By default, the values in variable-assignment elements are added to the values that are already defined in the descriptor. You can change this behavior and cause the variable-assignment element to replace or remove the values that are defined in the descriptor by setting the operation sub-element in the variable-assignment element to the value replace or remove, respectively.

For more information about the contents of a WebLogic Server resource deployment plan, see http://xmlns.oracle.com/weblogic/resource-deployment-plan/1.0/resource-deployment-plan.xsd. For more information about WebLogic Server application deployment plans, see "Understanding Deployment Plan Contents" in Deploying Applications to Oracle WebLogic Server.

Sample Resource Deployment Plan

The following shows a sample resource deployment plan.

<resource-deployment-plan 
  xmlns="http://xmlns.oracle.com/weblogic/resource-deployment-plan" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema" 
  xsi:schemaLocation="http://xmlns.oracle.com/weblogic/resource-deployment-plan http://xmlns.oracle.com/weblogic/resource-deployment-plan/1.0/resource-deployment-plan.xsd"
>
  <description>Example RDP</description>
  <variable-definition>
    <variable>
      <name>mailNewSessionUsername</name>
      <value>aaron</value>
    </variable>
    <variable>
      <name>mailNewProps</name>
      <value>mail.user=someoneElse;mail.host=myMailServer.oracle.com</value>
    </variable>
    <variable>
      <name>jdbcTableToTest</name>
      <value>JUNK_TABLE</value>
    </variable>
  </variable-definition>
  <external-resource-override>
    <resource-name>myjdbc</resource-name>
    <resource-type>jdbc-system-resource</resource-type>
    <root-element>jdbc-data-source</root-element>
    <variable-assignment>
      <name>jdbcTableToTest</name>
      <xpath>/jdbc-data-source/jdbc-connection-pool-params/test-table-name</xpath>
    </variable-assignment>
  </external-resource-override>
  <config-resource-override>
    <resource-name>myMail</resource-name>
    <resource-type>mail-session</resource-type>
    <variable-assignment>
      <name>mailNewSessionUsername</name>
      <xpath>/mail-session/session-username</xpath>
    </variable-assignment>
    <variable-assignment>
      <name>mailNewProps</name>
      <xpath>/mail-session/properties</xpath>
    </variable-assignment>
  </config-resource-override>
</resource-deployment-plan>

Configuring Resource MBean Overrides: Main Steps and WLST Examples

Prior to creating resource overrides in a domain partition, you must have first defined the resource you want to override in a resource group template.

Configuring a JDBC System Resource Override: Main Steps

The main steps for configuring a JDBC system resource override are as follows:

  1. Create the JDBC system resource override with the name of the datasource that you want to override.

  2. Optionally, provide partition-specific URL, user name, and password values.

  3. If the resource is running, restart the partition for the overrides to take effect.

Configuring a JDBC System Resource Override: WLST Example

The following example shows how to configure a JDBC system resource override using WLST:

edit()
startEdit()
cd('/Partitions/myPartition')
cmo.createJDBCSystemResourceOverride('myGDS')
 
cd('/Partitions/myPartition/JDBCSystemResourceOverrides/myJDBCSystemResourceOverride')
cmo.setURL('jdbc:oracle:thin:@lcr01156:1521:wldevdb2')
cmo.setUser('admin')
setEncrypted('Password', 'Password_1440013198602', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Config', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Secret')
activate()

Configuring a JMS System Resource Override: Main Steps

The main steps for configuring a JMS system module/foreign server override are as follows:

  1. Provide a name for the foreign server override.

    The system matches overrides using the name of the overriding configuration MBean with the name of the actual resource to be overridden.

  2. Optionally, provide partition-specific initial context factory, connection URL, JNDI properties credential, and JNDI properties values.

  3. If the resource is running, restart the partition for the overrides to take effect.

The main steps for configuring a JMS foreign server/foreign destination override are as follows:

  1. Provide a foreign JMS destination name for the foreign destination override.

    The name of this foreign destination override must match the name of the actual resource to be overridden.

  2. Optionally, provide a partition-specific remote JNDI name value.

  3. If the resource is running, restart the partition for the overrides to take effect.

The main steps for configuring a JMS foreign server/foreign connection factory override are as follows:

  1. Provide a foreign JMS connection factory name for the foreign connection factory override.

    The name of this foreign connection factory override must match the name of the actual resource to be overridden.

  2. Optionally, provide partition-specific remote JNDI name, user name, and password values.

  3. If the resource is running, restart the partition for the overrides to take effect.

Configuring a JMS System Resource Override: WLST Example

The following example shows how to configure a JMS system resource override using WLST:

edit()
startEdit()
cd('/Partitions/myPartition')
cmo.createJMSSystemResourceOverride('myJMSmoduleOverride')
activate()
 
startEdit()
cd('/Partitions/myPartition/JMSSystemResourceOverrides/myJMSmoduleOverride')
cmo.createForeignServer('newJMSforeignServer')
 
cd('/Partitions/myPartition/JMSSystemResourceOverrides/myJMSmoduleOverride/ForeignServers/newJMSforeignServer')
setEncrypted('JNDIPropertiesCredential', 'JNDIPropertiesCredential_1440013308523', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Config', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Secret')
cmo.setConnectionURL('java.naming.provider.url')
cmo.setInitialContextFactory('weblogic.jndi.WLInitialContextFactory')
activate()
 
startEdit()
cmo.createForeignDestination('myForeignDestinationOverride')
cd('/Partitions/myPartition/JMSSystemResourceOverrides/myJMSmoduleOverride/ForeignServers/newJMSforeignServer/ForeignDestinations/myForeignDestinationOverride')
cmo.setRemoteJNDIName('/remote')
activate()
 
startEdit()
cd('/Partitions/myPartition/JMSSystemResourceOverrides/myJMSmoduleOverride/ForeignServers/newJMSforeignServer')
cmo.createForeignConnectionFactory('myJMSconnectionFactoryOverride')
 
cd('/Partitions/myPartition/JMSSystemResourceOverrides/myJMSmoduleOverride/ForeignServers/newJMSforeignServer/ForeignConnectionFactories/myJMSconnectionFactoryOverride')
setEncrypted('Password', 'Password_1440013370283', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Config', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Secret')
cmo.setUsername('wlsqa')
cmo.setRemoteJNDIName('/remote')
activate()

Configuring a Mail Session Override: Main Steps

The main steps for configuring a mail session override are as follows:

  • Provide a name for the mail session override.

    The system matches overrides using the name of the overriding configuration MBean with the name of the resource MBean.

  • Optionally, provide partition-specific session user name, session password, and JavaMail properties values.

  • If the resource is running, restart the partition for the overrides to take effect.

Configuring a Mail Session Override: WLST Example

The following example shows how to configure a mail session override using WLST:

edit()
startEdit()
cd('/Partitions/myPartition')
cmo.createMailSessionOverride('myMailSessionOverride')
cd('/Partitions/myPartition/MailSessionOverrides/myMailSessionOverride')
cmo.setSessionUsername('wlsqa')
setEncrypted('SessionPassword', 'SessionPassword_1440013452297', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Config', 'C:/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain/Script1440013057535Secret')
cmo.setProperties({})
activate()

Configuring Resource Deployment Plans: Main Steps and WLST Example

The main steps for configuring a resource deployment plan are as follows:

  1. Using an XML editor, create a resource deployment plan. See resource-deployment-plan Syntax and Sample Resource Deployment Plan.

  2. Associate the resource deployment plan with a partition by providing the path to the resource deployment plan file.

  3. If the resource is running, restart the partition.

The following shows the WLST commands for associating a resource deployment plan with a pre-existing partition:

edit()
startEdit()
partition=cmo.lookupPartition(partitionName)
partition.setResourceDeploymentPlanPath('/path/to/the/file.xml')
save()
activate()

Configuring Resource Overrides: Related Tasks and Links

For additional information, see the following: