Skip navigation.
Downloads | Product Documentation | Support

Deploying WebLogic Platform Applications

# Creating and Configuring the WebLogic Domain

A domain is the basic administration unit for WebLogic Server. To run WebLogic Platform applications, you must create a domain that includes the appropriate WebLogic Platform resources. For more detailed information about WebLogic Server domains, see Overview of WebLogic Server Domains in Configuring and Managing WebLogic Server.

This section lists the tools that you can use to configure a WebLogic domain; provides considerations for configuring WebLogic resources, clusters, and targets; and describes how to set up and start the servers.

Topics include:

- Tools for Configuring the Target Domain
- Considerations for Configuring and Targeting Resources
- Adding Application Resources Required by the WebLogic Workshop Runtime
- Configuring Servers to Start in Production Mode
- Setting the SDK
- Setting Up the Managed Servers on Remote Machines

The following examples illustrate how to configure a WebLogic domain using scripts. Scripts facilitate controlled and repeatable creation of domains in different target environments.

- Example: How to Configure a Single-Cluster Platform Domain Using WLST Offline
- Example: How to Configure a Multi-Domain Environment Using WLST Offline
- Example: How to Configure a Multi-Domain Environment Using the Configuration Wizard in Silent Mode
- Example: How to Configure a Multi-Cluster Platform Domain Using WLST Offline

Note: Before proceeding, review your promotion plan to understand the configuration and targeting requirements of each resource required for your application. For more information about promotion plans, see Planning the Promotion.

# Tools for Configuring the Target Domain

The tools used to configure the target domain depend on whether you are creating a new target domain or the domain already exists. The tools are summarized in the following table.

Table 3-1 Tools for Configuring the WebLogic Domain

To... | Do the following...
--- | ---
Create a new WebLogic domain | Create the WebLogic domain and define the required WebLogic resources using the Configuration Wizard or WebLogic Scripting Tool (WLST) Offline. A set of predefined configuration templates is provided to help get you started. The Configuration Wizard or WLST Offline configures many of the resources for you, as explained in the following sections. For more information about creating the WebLogic domain using: Configuration Wizard, see Creating a New WebLogic Domain in Creating WebLogic Configurations Using the Configuration Wizard WLST Offline, see the instructions for setting up and using WLST Offline, as well as sample scripts for configuring domains, at the following URL: `https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=97` After you create a new WebLogic domain, you can update it using one of the methods described below in Update an existing WebLogic domain.
Update an existing WebLogic domain | Update an existing WebLogic domain using one of the following tools: WebLogic Server Administration Console (or the equivalent command-line interface), as described in Configuring and Managing WebLogic Server Configuration Wizard, as described in Extending Domains in Creating WebLogic Configurations Using the Configuration Wizard WLST Offline, as described in the WLST Offline help kit at the following URL: `https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=97`

# Considerations for Configuring and Targeting Resources

When creating a WebLogic domain, you need to configure and specify targets for the system resources. Table 3-2 provides tips for configuring and targeting resources in a production environment.

Note: The Configuration Wizard and WLST Offline have an autoconfiguration feature that streamlines the process of configuring resources in multi-server (e.g., clustered) domains. See Autoconfiguration Using the Configuration Wizard and WLST Offline.

Table 3-2 Considerations for Configuring and Targeting Resources

Resource | Configuration Considerations | Targeting Considerations
--- | --- | ---
Administration Server | Set the name, address, and ports for the Administration Server using the guidelines specified in Guidelines for Specifying the Names and Addresses of the Members in a Cluster. Enable the Secure Sockets Layer (SSL) protocol if you wish to enable secure communication between applications connected through the Web. For additional information about security considerations, see Configuring Security. Enable HTTP tunneling to enable a stateful connection by simulating a T3Connection. For more information, see Setting Up WebLogic Server for HTTP Tunneling in "Configuring Web Server Functionality for WebLogic Server" in Configuring and Managing WebLogic Server. Related topics: For an example using WLST Offline, see Configure the Administration Server. | Ensure that the Administration Server IP address is not included in the cluster-wide DNS name. You should not include the Administration Server in the cluster for the following reasons: There is no benefit to doing so. The administrative objects are not clusterable, and will not fail over to another cluster member if the Administration Server fails. The Administration Server should not be configured to handle client requests.
Managed Servers | Set the name, address, and ports for each Managed Server using the guidelines specified in Guidelines for Specifying the Names and Addresses of the Members in a Cluster. When using the WebLogic Server as a Web proxy server, add a Managed Server to function as the proxy. For more information see Load Balancing with a Web Proxy Server. Increase the thread count value based on your performance requirements. See Tuning the Default Execute Queue Threads in WebLogic Server Performance and Tuning. Related topics: For an example using WLST Offline, see Configure the Cluster, Managed Servers, and Machines. | If you added a Managed Server to act as a proxy server, do not include it in the cluster. Avoid deploying server instances in a cluster across a firewall. For more information, see "Firewalls Can Break Multicast Communication" in "One-to-Many Communication Using IP Multicast" in "WebLogic Server Communication in a Cluster" in Communications in a Cluster in Using WebLogic Server Clusters.
Cluster | Identify the address and port for multicast communications in the cluster. Multiple clusters on a network may share a multicast address and multicast port combination if necessary. Ensure that the multicast address for a cluster is not used for any purpose other than cluster communications. Set the name, address, and ports for each member in the cluster using the guidelines specified in Guidelines for Specifying the Names and Addresses of the Members in a Cluster. Failover for entity beans and EJB handles requires that the cluster address be specified as a DNS name that maps to all server instances in the cluster and only server instances in the cluster. For more information, see "Failover for Entity Beans and EJB Handles" in "Replication and Failover for EJBs and RMIs" in ``Failover and Replication in a Cluster in Using WebLogic Server Clusters. Related topics: Using WebLogic Server Clusters Load Balancing in a Cluster and Failover and Replication in a Cluster in Using WebLogic Server Clusters For an example using WLST Offline, see Configure the Cluster, Managed Servers, and Machines. | To review considerations for targeting applications to the cluster, see Application Targets.
Machines | Define machine names if: You are running Node Manager on a machine that does not also host the Administration Server (e.g., a remote machine). In this case, do not set the Node Manager to `localhost`. If you identify the Listen Address by IP address, you must disable `HostNameVerification` on Administration Servers and Managed Servers that use Node Manager. You are running more than one server instance per machine so that WebLogic Server does not replicate a session on the same machine. Related topics: For an example using WLST Offline, see Configure the Cluster, Managed Servers, and Machines. | N/A
JDBC Connection Pools | For each JDBC connection pool, set the database type and related information, such as the host and port information, to specify the production database. For a description of the predefined JDBC configuration information for the WebLogic Platform domain, see Deployment Targeting Reference. Please note the following: Configure all default connection pools (such as `cgPool`, `cgJMSPool-nonXA`, `bpmArchPool`, and so on). If you change the name of a connection pool, target the existing data sources to the new connection pool. Configure the `cgJMSPool-nonXA` pool with a nonXA driver. If the reporting data tables are referenced through a different pool than `cgPool`, then when configuring `bpmArchPool`, configure it as the Reporting Datastore in the WebLogic Administration Console. For more information, see "Configuring the Reporting DataStore" in System Configuration in Managing WebLogic Integration Solutions. When creating XA domains to support global transactions, review the JDBC configuration guidelines in Creating XA Domains Using Configuration Templates in Creating WebLogic Configurations Using the Configuration Wizard. Related topics: For a list of supported database drivers, see: Supported Database Configurations in Supported Configurations for WebLogic Platform 8.1. Load Balancing in a Cluster and Failover and Replication in a Cluster in Using WebLogic Server Clusters For an example using WLST Offline, see Configure the JDBC Connection Pools. | Target to the cluster; you can target the same JDBC connection pool to multiple clusters Target to the Administration Server, if required (for example, if a JMS Server is targeted to the Administration Server) Ensure that you target to the same servers and clusters as the related JDBC data sources
JDBC Data Source/ TX Data Source | Configure one JMS JDBC Store for each server that has a JMS Server defined. Please note the following: If you are using an XA driver, configure only one Tx Data Source per XA-compliant JDBC connection pool. Note that you can specify multiple JNDI names per Tx Data Source, separated by semicolons. If you are using distributed transactions with non-XA drivers, configure all Tx Data Sources on the same connection pool. If you are using only local transactions, use a Data Source. Otherwise, use a Tx Data Source, but ensure that you suspend and subsequently resume any global transaction currently associated with your thread around your local transaction boundary. If you create multiple domains that share the same database, each domain must reference unique database schemas. You should not edit the JNDI name of the JDBC data sources or Tx data sources. When creating XA domains to support global transactions, review the JDBC configuration guidelines in "Creating XA Domains Using Configuration Templates" in How Do I...? in Creating WebLogic Configurations Using the Configuration Wizard. When creating XA domains to support Oracle RAC, review the JDBC configuration guidelines in "How Do I: Create XA domains with MultiPools and an Oracle RAC Database?" in How Do I...? in Creating WebLogic Configurations Using the Configuration Wizard. Related topics: For a description of the predefined JDBC configuration information for the WebLogic Platform domain, see Deployment Targeting Reference. | Target the same servers and clusters as the related JDBC connection pool You can target the same JDBC data source to multiple clusters
JDBC MultiPools | Create JDBC MultiPools to provide additional load balancing support. MultiPools are not required to be used in a cluster. | Target to the cluster; you can target the same JDBC MultiPool to multiple clusters Target to the Administration Server, if required Ensure that you target to the same servers and clusters as the related JDBC data sources and connection pools
JMS Servers | To support JMS failover, target JMS Servers to migratable Managed Servers. This targeting is done automatically, when using the Configuration Wizard or WLST Offline to create the domain. WebLogic JMS takes advantage of the migration framework implemented in the WebLogic Server core for clustered environments by configuring migratable targets for JMS Servers. This framework enables JMS to properly respond to migration requests and bring a JMS server online and offline in an orderly fashion. If you do not configure a migratable target in a cluster, you can still migrate migratable services manually to any server instance in the cluster. For more information, see "Configuring Migratable JMS Server Targets" in Managing WebLogic JMS in Programming WebLogic JMS. If you add a JMS server when creating a domain, autoconfiguration is not performed. For more information about autoconfiguration, see Autoconfiguration Using the Configuration Wizard and WLST Offline. Note: WebLogic Integration system queues can be mixed with application queues on the same JMS server. | Target one JMS Server per Managed Server, as required Target to the Administration Server, as required (for example, to support WebLogic Portal applications)
JMS Destinations/ Distributed Destinations | Create JMS distributed destinations when using a cluster to support high availability and load balancing of physical destinations. When using the Configuration Wizard or WLST Offline, by creating the destinations before you create the cluster, the destination will be configured automatically as a distributed destination with the same JNDI name, and the members will be configured as well. Create one JMS distributed destination member for each Managed Server. Set the `RedeliveryLimit` to a number of messages that is practical for the environment. By default, a JMS queue will redeliver error messages and warnings an infinite number of times. Create an error destination for undeliverable messages.The error destination can be either a queue or a topic destination. It must be configured on the same JMS server as the destination for which it is defined. If no error destination is configured, then undeliverable messages are simply deleted. You should set the `RedeliveryLimit` to 0 for a JMS queue. For more information, see ``JMS Destination Tasks in the Administration Console Online Help. Configure the asynchronous dispatcher queues, if necessary, as described in Adding Application Resources Required by the WebLogic Workshop Runtime. Note: If you add a JMS Server and subsequently add a JMS destination to it when creating a domain, autoconfiguration is not performed. For more information about autoconfiguration, see Autoconfiguration Using the Configuration Wizard and WLST Offline. Related topics: Load Balancing in a Cluster and Failover and Replication in a Cluster in Using WebLogic Server Clusters | Target to a single cluster. By default, the Configuration Wizard automatically assigns each JMS distributed destination to the first cluster in the domain. Once the domain is created, you can modify the target using the WebLogic Server Administration Console (or equivalent tool).
JMS File/JDBC Store | Define JMS file stores or JDBC stores for each of the Managed Servers and the Administration Server, as required. Configure the JMS JDBC Store with a non-XA JDBC connection pool. | N/A

## Guidelines for Specifying the Names and Addresses of the Members in a Cluster

When configuring a cluster, you specify name and address information for the cluster and its members—the server instances that comprise it—using either IP addresses or DNS names. Consider the following when configuring the names and addresses:

- Each cluster member must have a unique name.
- When specifying the listen address for each server instance in a cluster, it is recommended that you use DNS names rather than IP addresses. IP addresses can result in translation errors if you use firewalls. For more information, see "Firewall Considerations" in Clustering Best Practices in Using WebLogic Server Clusters.
- If the internal and external DNS names of a WebLogic Server instance are not identical, use the `ExternalDNSName` attribute for the server instance to define the server external DNS name. However, the `ExternalDNSName` attribute should not be used if clients are accessing WebLogic Server over the default channel and T3.

For more information on the above, see "Identify Names and Addresses" in "Before You Start" in Setting up WebLogic Clusters in Using WebLogic Server Clusters.

## Autoconfiguration Using the Configuration Wizard and WLST Offline

The Configuration Wizard and WLST Offline provide an autoconfiguration feature that streamlines the process of configuring resources in multi-server (e.g., clustered) domains.

When you add Managed Servers during domain creation, the Configuration Wizard and WLST Offline will automatically distribute resources on those servers.

When you use WLST Offline to create the queues in a domain, the tool automatically configures each queue as a distributed queue and creates associated member queues on each Managed Server in the cluster. This must be done when creating the domain and before the cluster is created; this feature is not supported when updating an existing domain.

For more information about autoconfiguration, see "Autoconfiguration of Applications and Services" in Configuring Targets in Creating WebLogic Configurations Using the Configuration Wizard.

For a list of default targets for the predefined resources, see:

- Deployment Targeting Reference
- "Understanding Portal Resources" in Configuring a Portal Cluster in the WebLogic Portal Production Operations User Guide
- "Deploying WebLogic Integration Resources" in "Designing a Clustered Deployment" in Understanding WebLogic Integration Clusters in Deploying WebLogic Integration Solutions

Note: Autoconfiguration for a cluster only works when you add the cluster when you create a domain, or when you add it when you update a domain using an extension template. This feature is not supported when updating an existing domain (without an extension template).

The Configuration Wizard and WLST Offline support autoconfiguration for single-cluster domains. When creating two clusters, you need to manually correct the targets assigned for the resources, services, and applications, as illustrated in Example: How to Configure a Multi-Cluster Platform Domain Using WLST Offline.

# Adding Application Resources Required by the WebLogic Workshop Runtime

If Web services are configured to support asynchronous requests, WebLogic Workshop creates asynchronous request and error queues in the development environment to handle the requests. For each pair of queue elements, you must create a pair of corresponding JMS queues on the target server, and associate the asynchronous error queue with the asynchronous queue.

WebLogic Workshop defines the asynchronous queues in the `/META-INF/wlw-manifest.xml` file with the following element names: `<con:async-request-queue>` and `<con:async-request-error-queue>.` The queues are named using the following format: `web_app``.queue.AsyncDispatcher` and `web_app``.queue.AsyncDispatcher_error`, where `web_app` specifies the name of the Web application.

If the target domain is clustered, you must configure the queues as distributed queues. If you are using multiple clusters, you must create an additional set of queues for each cluster.

Note: When you use WLST Offline to create the queues in a domain, the tool automatically configures each queue as a distributed queue and creates associated member queues on each Managed Server in the cluster. This must be done when creating the domain and before the cluster is created; this feature is not supported when updating an existing domain. For more information, see Autoconfiguration Using the Configuration Wizard and WLST Offline.

For an example of setting asynchronous dispatcher queues, see Configure the Asynchronous Dispatcher Queues Required by the Application.

You can configure the server dispatch policy for asynchronous requests using the `<async-dispatch-policy>` element in the `wlw-config.xml` configuration file. The `<async-dispatch-policy>` element associates a project's asynchronous requests with a server-defined dispatch policy. The dispatch policy designates which server execute thread pool the EJB should run in. The value provided for this element is used to generate an `<async-dispatch-policy>` entry in the `weblogic-ejb-jar.xml` configuration file for the AsyncDispatcher and AsyncErrorDispatcher message-driven beans. For more information, see the `<asynch-dispatch-policy>` element description in WebLogic Workshop Online Help.

# Configuring Servers to Start in Production Mode

Set the startup mode to `prod`. For information about the differences between development and production modes, see Differences Between Configuration Startup Modes in Creating WebLogic Configurations Using the Configuration Wizard. For an example of configuring the server startup mode, see Set Domain Options.

# Setting the SDK

Set the SDK to one that is supported on the platform you are using, and that is optimized for production-level performance. Ensure that you configure the same SDK across all server instances in a cluster. For a list of the Java SDKs that are supported for a specific platform, see Supported Configurations for WebLogic Platform 8.1. For an example of configuring the SDK see Set Domain Options.

# Setting Up the Managed Servers on Remote Machines

Once you have configured the target domain, you need to set up the Managed Server directories on remote machines and optionally configure Node Manager.

- Setting Up the Managed Server Directories
- Configuring the Managed Server Start Attributes
- Configuring Node Manager

## Setting Up the Managed Server Directories

To set up the Managed Server directories that run on remote machines:

1. If you will not be using Node Manager to manage a remote Managed Server, create a domain on that server. Ensure that you configure the same JDK across all server instances in a cluster and that you set the mode to `prod`.

If you will be using Node Managed, a remote Managed Server directory does not require the complete set of files that are located in the Administration Server directory, as the Administration Server maintains the configuration information for all Managed Servers within a domain.

2. If you use WebLogic Workshop `wlw-runtime-config.xml` configuration file, you must copy it to the root directory of each Managed Server in the cluster.
3. Ensure the key stores for the following security services are made available to the Managed Server.

Security Service Requiring Key Stores | Description
--- | ---
WebLogic Server security | Enables SSL transport traffic. For more information about WebLgoic Server security, see: "Secure Sockets Layer (SSL)" in Security Fundamentals in Introduction to WebLogic Security Configuring SSL in Managing WebLogic Security
Web service security | Enables message-level security for Web services. You must also ensure that the related WSSE policy files are made available to the Managed Servers. For more information about Web service security, see: Web Service Security in WebLogic Workshop Online Help "Overview of Web Services Security" in Configuring Security in Programming WebLogic Web Services Building a Secure Web Service using BEA's WebLogic Workshop at: `http://dev2dev.bea.com/products/wlworkshop81/articles/sws_wlw.jsp`
WSRP security | Enables security for the Web Services for Remote Portlets (WSRP) feature of WebLogic Portal. By default, the WSRP security keystore is stored in the `wsrpKeystore.jks` file. For more information about WSRP security, see Establishing WSRP Security in Using WSRP With WebLogic Portal.
Trading Partner security | Enables the security for Trading Partners. For more information, see Trading Partner Integration Security in Introducing Trading Partner Integration.

## Configuring the Managed Server Start Attributes

You need to configure the `ServerStart` attributes for each Managed Server if you want to start the Managed Server remotely using Node Manager.

The following table defines the attributes that need to be set for each Managed Server. For information about the start attributes that can be set for a server using the WebLogic Server Administration Console, see ServerStart in WebLogic Server Configuration Reference.

Table 3-3 ServerStart Attributes for the Managed Server

Attribute | Description
--- | ---
Arguments | Startup arguments to use when starting this server.
BEA Home | Location of the WebLogic Platform installation.
ClassPath | Classpath to use when starting the server. For sample classpath settings for default domains, see Table 3-4.
JavaHome | Java home directory.
Name | Name of the configuration.
Notes | Optional information that you can include to describe the configuration.
Password | Password of the username used to boot the server and perform server health monitoring.
RootDirectory | Root directory to be used to start the server.
SecurityPolicyFile | Security policy file to use when starting this server.
Username | Username to use when booting the server and performing server health monitoring.

The following table identifies the required `CLASSPATH` settings for the default domains.

Note: The classpath value may differ from that defined in the table, depending on your environment. To access the `CLASSPATH` information for your environment, start the Administration Server and capture the `CLASSPATH` information that displays to the command window (`stdout`).

Table 3-4 CLASSPATH Settings for Default Domains

Domain | CLASSPATH Value
--- | ---
Basic WebLogic Platform | `%WL_HOME%\server\lib\weblogic_knex_patch.jar; %WL_HOME%\common\lib\log4j.jar; %WL_HOME%\server\lib\debugging.jar; %WL_HOME%\server\lib\knex.jar; %WL_HOME%\javelin\lib\javelin.jar; %WL_HOME%\server\lib\wlw-lang.jar; %JAVA_HOME%\lib\tools.jar; %WL_HOME%\server\lib\weblogic_sp.jar; %WL_HOME%\server\lib\weblogic.jar; %WL_HOME%\server\lib\ant\ant.jar; %JAVA_HOME%\jre\lib\rt.jar; %WL_HOME%\server\lib\webserviceclient.jar; %WL_HOME%\server\lib\webserviceclient+ssl.jar; %WL_HOME%\server\lib\xbean.jar; %WL_HOME%\server\lib\wlxbean.jar; %WL_HOME%\server\lib\xqrl.jar; %WL_HOME%\server\lib\netui\netui-compiler.jar; %WL_HOME%\server\lib\wli.jar; %WL_HOME%\server\lib\fop.jar; %WL_HOME%\integration\adapters\sample\lib\sample-eis.jar; %WL_HOME%\portal\lib\wps_system.jar`
Basic WebLogic Server | `%JAVA_HOME%\lib\tools.jar; %WL_HOME%\server\lib\weblogic_sp.jar; %WL_HOME%\server\lib\weblogic.jar; %JAVA_HOME%\jre\lib\rt.jar; %WL_HOME%\server\lib\webservices.jar` For more information, see Setting the CLASSPATH in WebLogic Server Command Reference.
Basic WebLogic Portal | `%WL_HOME%\server\lib\weblogic_knex_patch.jar; %WL_HOME%\common\lib\log4j.jar; %WL_HOME%\server\lib\debugging.jar; %WL_HOME%\server\lib\knex.jar; %WL_HOME%\javelin\lib\javelin.jar; %WL_HOME%\server\lib\wlw-lang.jar; %JAVA_HOME%\lib\tools.jar; %WL_HOME%\server\lib\weblogic_sp.jar; %WL_HOME%\server\lib\weblogic.jar; %WL_HOME%\server\lib\ant\ant.jar; %JAVA_HOME%\jre\lib\rt.jar; %WL_HOME%\server\lib\webserviceclient.jar; %WL_HOME%\server\lib\webserviceclient+ssl.jar; %WL_HOME%\server\lib\xbean.jar; %WL_HOME%\server\lib\wlxbean.jar; %WL_HOME%\server\lib\xqrl.jar; %WL_HOME%\server\lib\netui\netui-compiler.jar; %WL_HOME%\server\lib\wli.jar; %WL_HOME%\server\lib\fop.jar; %WL_HOME%\integration\adapters\sample\lib\sample-eis.jar; %WL_HOME%\portal\lib\wps_system.jar`
Basic WebLogic Integration | `%WL_HOME%\server\lib\weblogic_knex_patch.jar; %WL_HOME%\common\lib\log4j.jar; %WL_HOME%\server\lib\debugging.jar; %WL_HOME%\server\lib\knex.jar; %WL_HOME%\javelin\lib\javelin.jar; %WL_HOME%\server\lib\wlw-lang.jar; %JAVA_HOME%\lib\tools.jar; %WL_HOME%\server\lib\weblogic_sp.jar; %WL_HOME%\server\lib\weblogic.jar; %WL_HOME%\server\lib\ant\ant.jar; %JAVA_HOME%\jre\lib\rt.jar; %WL_HOME%\server\lib\webserviceclient.jar; %WL_HOME%\server\lib\webserviceclient+ssl.jar; %WL_HOME%\server\lib\xbean.jar; %WL_HOME%\server\lib\wlxbean.jar; %WL_HOME%\server\lib\xqrl.jar; %WL_HOME%\server\lib\netui\netui-compiler.jar; %WL_HOME%\server\lib\wli.jar; %WL_HOME%\server\lib\fop.jar; %WL_HOME%\integration\adapters\sample\lib\sample-eis.jar`
Basic WebLogic Workshop | `%WL_HOME%\server\lib\weblogic_knex_patch.jar; %WL_HOME%\common\lib\log4j.jar; %WL_HOME%\server\lib\debugging.jar; %WL_HOME%\server\lib\knex.jar; %WL_HOME%\javelin\lib\javelin.jar; %WL_HOME%\server\lib\wlw-lang.jar; %JAVA_HOME%\lib\tools.jar; %WL_HOME%\server\lib\weblogic_sp.jar; %WL_HOME%\server\lib\weblogic.jar; %WL_HOME%\server\lib\ant\ant.jar; %JAVA_HOME%\jre\lib\rt.jar; %WL_HOME%\server\lib\webserviceclient.jar; %WL_HOME%\server\lib\webserviceclient+ssl.jar; %WL_HOME%\server\lib\xbean.jar; %WL_HOME%\server\lib\wlxbean.jar; %WL_HOME%\server\lib\xqrl.jar; %WL_HOME%\server\lib\netui\netui-compiler.jar; %WL_HOME%\server\lib\wli.jar; %WL_HOME%\server\lib\fop.jar; %WL_HOME%\integration\adapters\sample\lib\sample-eis.jar`

## Configuring Node Manager

Node Manager enables you to perform common operations for a Managed Server, regardless of its location with respect to its Administration Server. You can use Node Manager to perform the following operations:

- Start and stop remote Managed Servers.
- Monitor the health of Managed Servers and automatically kill server instances whose health state is "failed."
- Automatically restart Managed Servers that have failed, or have shutdown unexpectedly due to a system crash or reboot.

To take advantage of Node Manager capabilities, you must run a Node Manager process on each machine that hosts Managed Servers, and configure Node Manager to:

- Accept commands from a remote host

For example, you must configure a machine to use Node Manager and specify a value other than localhost for the listen address, as described in Considerations for Configuring and Targeting Resources.

- Support production security components
- Tailor the shutdown and monitoring behavior

For complete details about each of the steps required to configure Node Manager in a production environment, see "Configuration Checklist (Production Environment)" in "Configuring Node Manager" in Configuring, Stopping, and Starting Node Manager in Configuring and Managing WebLogic Server.

# Example: How to Configure a Single-Cluster Platform Domain Using WLST Offline

The following example illustrates how to create a WebLogic Platform domain that contains a single cluster, as illustrated in Single-Cluster Platform Domain Example, using WLST Offline.

Steps include:

- Define WLST Variables
- Open the Template for Domain Creation
- Configure an Administrative Username and Password
- Configure the Administration Server
- Configure the Asynchronous Dispatcher Queues Required by the Application
- Configure the JDBC Connection Pools
- Configure the Cluster, Managed Servers, and Machines
- Set Domain Options
- Write the Domain and Close the Template

For more information about WLST Offline, see the documentation and examples provided with the WLST Offline kit at the following URL: `https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=97`

#### Define WLST Variables

You can define variables in the WLST Offline script and reference them using the WLST Offline commands to facilitate reuse of the scripts in different target environments. For example, you can "hard-code" the variable values within the script or pass the values to the WLST Offline script from the command line.

For example, if you define the following variables within the WLST Offline script to specify the WebLogic home directory, domain name, and domain template name:

>     weblogic_home="/bea/weblogic81"
>     domain_template="platform.jar"

You can then reference the variables in the script instead of the values. For example:

`readTemplate(``weblogic_home``+` '`/common/templates/domains`'`+` `domain_template``)`

Note: For readability, the following code excerpts use actual values and not variables.

#### Open the Template for Domain Creation

The following code excerpt opens the Basic WebLogic Platform Domain template for domain creation and sets the name of the domain using the `cmo` variable. The `cmo` variable stores the Current Management Object, which is set to the configuration bean instance to which you navigate using WLST Offline—in this case the root of all configuration management objects, `DomainMBean`.

>     readTemplate('/bea/weblogic81/common/templates/domains/platform.jar')

#### Configure an Administrative Username and Password

The following code excerpt sets the password for the pre-configured administrative account.

>     cd('/Security/platform/User/weblogic')
>     cmo.setPassword('password')

#### Configure the Administration Server

The following code excerpt configures the Administration Server by setting the listen address and port, enabling SSL, and setting the SSL port. To review considerations for configuring the Administration Server, see Considerations for Configuring and Targeting Resources.

>     cd('/Server/cgServer')
>     cmo.setListenAddress('host')
>     cmo.setListenPort(9301)

>     cd('SSL/cgServer')
>     cmo.setEnabled(1)
>     cmo.setListenPort(9302)

#### Configure the Asynchronous Dispatcher Queues Required by the Application

The following code excerpt configures a set of asynchronous dispatcher queues and their associated error queues, as required by the application. To determine if you need to create asynchronous dispatcher queues, review the contents of the `wlw-manifest.xml` file, which provides information about the server resources referenced by the application, as described in Adding Application Resources Required by the WebLogic Workshop Runtime.

Tip | By creating the asynchronous queues before you create the cluster, the queue will be configured automatically as a distributed queue with the same JNDI name.

>       queueNames = 'IntApp.queue.AsyncDispatcher', \
>         'PortApp.queue.AsyncDispatcher'

>       # Predefined  JMS Server included in the domain template
>       cd ('/JMSServer/cgJMSServer')

>       for qName in queueNames:
>         errqName = qName + "_error"

>         # Create asynchronous dispatcher error queue
>         create(errqName, 'JMSQueue')
>         cd ('JMSQueue/' + errqName)
>         cmo.setJNDIName(errq	Name)
>         errqMBean = cmo
>         cd ('../..')

>         # Create asynchronous dispatcher queue
>         create(qName, 'JMSQueue')
>         cd ('JMSQueue/' + qName)
>         cmo.setJNDIName(qName)

>         # Associate asynchronous dispatcher error queue
>         cmo.setErrorDestination(errqMBean)
>         cd ('../..')

#### Configure the JDBC Connection Pools

The following code excerpt configures the database type and related information to specify the production database for each of the four default JDBC connection pools, including `bpmArchPool`, `cgJMSPool-nonXA`, `cgPool`, and `portalPool`. To review considerations for configuring JDBC connection pools, see Considerations for Configuring and Targeting Resources.

>     cd ('/JDBCConnectionPool')
>     nonXApools = 'cgJMSPool-nonXA',
>     for pool in nonXApools:
>        cd (pool)
>        cmo.setDriverName('oracle.jdbc.driver.OracleDriver')
>        cmo.setUserName('username')
>        cmo.setPassword('password')
>        cmo.setDbmsHost('myDBHost')
>        cmo.setDbmsPort('1521')
>        cmo.setDbmsName('myDB')
>        cd ('..')

>     XApools = 'cgPool', 'bpmArchPool', 'portalPool'
>     for pool in XApools:
>       cd (pool)
>       cmo.setDriverName('oracle.jdbc.xa.client.OracleXADataSource')
>       cmo.setUserName(`user')
>       cmo.setPassword(`password')
>       cmo.setDbmsHost('myDBHost')
>       cmo.setDbmsPort('5321')
>       cmo.setDbmsName('myDB')
>       cmo.setSupportsLocalTransaction(1)
>       cmo.setKeepXAConnTillTxComplete(1)
>       cd ('..')

#### Configure the Cluster, Managed Servers, and Machines

The following code excerpt performs the following tasks:

- Configures one cluster.
- Configures two machines.
- Configures the Node Manager name, listen address, start properties—including `BEA_HOME`, `JAVA_HOME`, the directory root, and the `CLASSPATH` values—and the file containing the security policy for starting the server. For more information about configuring Node Manager, see Configuring Node Manager.
- Configures four Managed Servers, targeting them to a machine, and enables SSL to enable secure access to application resources.
- Tunes the default execution threads. For more information, see Tuning the Default Execute Queue Threads in WebLogic Server Performance and Tuning.

>     cd ('/')
>     # Define the servers
>     clusterConfig = 'platformCluster','multicast_addr',9101
>     ms1 = 'ms1','host1',9111,9112,'machine1'
>     ms2 = 'ms2','host2',9121,9122,'machine2'
>     ms3 = 'ms3','host3',9131,9132,'machine1'
>     ms4 = 'ms4','host4',9141,9142,'machine2'
>     mss = ms1, ms2, ms3, ms4

>     #Create the cluster
>     cl_name, mc_addr, mc_port = clusterConfig
>     cluster = create(cl_name, 'Cluster')

>     #Configure the machines
>     machine = None
>     prev_ms_machine = ""
>     cl_addr = ""
>     for msConfig in mss:
>        ms_name, ms_addr, ms_port, ms_ssl_port, ms_machine = msConfig
>        if ms_machine != "" and ms_machine != prev_ms_machine:
>          prev_ms_machine = ms_machine
>          machine = create(ms_machine, 'Machine')

>          #Configure the Node Manager name and listen address
>          cd('Machine/' + ms_machine + '/NodeManager/' + ms_machine)
>          cmo.setName(ms_machine)
>          cmo.setListenAddress(ms_addr)
>          cd('../../../..')

>        #Configure the Managed Server, target it to a machine
>        ms = create(ms_name,'Server')

>        cd('Server/' + ms_name)
>        cmo.setListenAddress(ms_addr)
>        cmo.setListenPort(ms_port)
>        if machine != None:
>           cmo.setMachine(machine)
>        cd('SSL/' + ms_name)
>        cmo.setEnabled(1)
>        cmo.setListenPort(ms_ssl_port)
>        cd('../..')
>        assign('Server', ms_name, 'Cluster', cl_name)

>        # Configure Node Manager StartServer properties
>        create(ms_name, 'ServerStart')
>        cd('ServerStart/' + ms_name)
>        cmo.setBeaHome('/bea')
>        cmo.setJavaHome('/bea/weblogic81/jrockit81sp4_142_05')
>        cmo.setRootDirectory('/bea/user_projects/domains/platform')
>        # See Table 3-4 for CLASSPATH settings
>        cmo.setClassPath(`classpath')
>        cmo.setSecurityPolicyFile('/bea/weblogic81/server/lib/weblogic.policy')
>        cmo.setArguments('-Xms512m -Xmx512m -da -Dwlw.iterativeDev=false
>      -Dwlw.testConsole=false -Dwlw.logErrorsToConsole=true -Dweblogic.ProductionModeEnabled=true')
>        cmo.setUsername('user')
>        cmo.setPassword('password')

>        cd('../..')
>        # Tune execution threads
>        cd('ExecuteQueue/weblogic.kernel.Default')
>        cmo.setThreadCount(15)
>        cmo.setThreadsIncrease(5)

>        cd('../..')
>        # Accumulate addresses and ports for setting cluster address
>        cl_addr = cl_addr + ms_addr + ':' + str(ms_port) + ','

>     # Set the cluster address, multicast address, and multicast port
>     cl_addr = cl_addr[:-1] # slice off trailing','
>     cluster.setClusterAddress(cl_addr)
>     cluster.setMulticastAddress(mc_addr)
>     cluster.setMulticastPort(mc_port)

#### Configure the Web Proxy Server

The following code excerpt configures the Web proxy server. For more information, see Using Load Balancers and Web Proxy Servers.

>     create('platproxy','Server')
>     cd('/Server/platproxy')
>     cmo.setListenAddress('host')
>     cmo.setListenPort(9431)
>     # Set this server as the proxy server for the cluster
>     cd ('/Cluster/platformcluster')
>     cmo.setProxyServer('platproxy')

#### Set Domain Options

The following code excerpt sets the following domain options:

- `CreateStartMenu`—Specifies whether to create a Start Menu shortcut on a Windows platform.
- `JavaHome`—Specifies the home directory for the SDK to be used when starting the server.
- `OverwriteDomain`—Specifies whether to allow an existing domain to be overwritten. The default is `false`.
- `ServerStartMode`—Specifies the mode to use when starting the server for the newly created domain. This value can be `dev` (development) or `prod` (production). This value should be set to `prod`.

>     setOption('OverwriteDomain','true')
>     setOption('CreateStartMenu','false')
>     setOption('ServerStartMode','prod')
>     setOption('JavaHome','/bea/weblogic81/jrockit81sp4_142_05')

#### Write the Domain and Close the Template

The following code excerpt writes the domain to the specified directory and closes the configuration template.

>     writeDomain('/bea/user_projects/domains/platform')
>     closeTemplate()

# Example: How to Configure a Multi-Domain Environment Using WLST Offline

This section describes how to configure an environment that consists of two domains—a Basic WebLogic Integration Domain and a Basic WebLogic Portal Domain—as illustrated in Multi-Domain Example.

Steps include:

- Create the Basic WebLogic Integration Domain
- Create the Basic WebLogic Portal Domain

For more information about using WLST Offline, see the documentation and examples provided with the WLST Offline kit at the following URL: `https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=97`

#### Create the Basic WebLogic Integration Domain

The process used to configure the Basic WebLogic Integration domain using WLST Offline is similar to the process illustrated in Example: How to Configure a Single-Cluster Platform Domain Using WLST Offline, with the following exceptions:

- When opening the template to create the domain, as described in Open the Template for Domain Creation, specify the Basic WebLogic Integration Domain template. For example:

>     readTemplate('/bea/weblogic81/common/templates/domains/wli.jar')

- When configuring the asynchronous dispatcher queues required by the application, as described in Configure the Asynchronous Dispatcher Queues Required by the Application, define the `queueNames` list as follows:

>     queueNames = 'IntApp.queue.AsyncDispatcher',

- When configuring the JDBC connection pools, as described in Configure the JDBC Connection Pools, define the XA connection pools list as follows:

>     XApools = 'cgPool', 'bpmArchPool'

#### Create the Basic WebLogic Portal Domain

The process used to configure the Basic WebLogic Portal domain using WLST Offline is similar to the process illustrated in Example: How to Configure a Single-Cluster Platform Domain Using WLST Offline, with the following exceptions:

- When opening the template to create the domain, as described in Open the Template for Domain Creation, specify the Basic WebLogic Portal Domain template. For example:

>     readTemplate('/bea/weblogic81/common/templates/domains/wlp.jar')

- When configuring the asynchronous dispatcher queues required by the application, as described in Configure the Asynchronous Dispatcher Queues Required by the Application, define the `queueNames` list as follows:

>     queueNames = 'PortApp.queue.AsyncDispatcher',

- When configuring the JDBC connection pools, as described in Configure the JDBC Connection Pools, define the `XAPools` list as follows:

>     XApools = 'cgPool', 'portalPool'

# Example: How to Configure a Multi-Domain Environment Using the Configuration Wizard in Silent Mode

Clusterizing End2End on WebLogic Platform 8.1 on the dev2dev Web site provides an example of configuring a target domain using the Configuration Wizard in silent mode. You can access this article, and download its associated samples files at: `http://dev2dev.bea.com/products/wlplatform81/articles/clusterizing_E2E.jsp`

Note: Code samples and utilities are posted on dev2dev for your convenience. They are not products supported by BEA.

This article describes how to promote and extend the WebLogic Platform Tour from a development to a production environment, and describes how to configure the following two domains using the Configuration Wizard silent mode:

- WebLogic Portal domain for hosting WebLogic Portal applications
- WebLogic Integration domain for hosting WebLogic Integration applications

Note: This environment is depicted in Multi-Domain Example.

To view the Configuration Wizard silent mode scripts, download the `E2ECluster.zip` file that contains the sample code and extract the following files:

- `integration_cluster_domain.cws`—Creates a clustered domain for the sample using the Basic WebLogic Integration Domain template.
- `portal_cluster_domain.cws`—Creates a clustered domain for the sample using the Basic WebLogic Portal Domain template.

Note: The scripts are designed to be called from an Ant script. They reference properties, such as `@DOMAIN_TEMPLATE@`, that are resolved in a properties file imported to the Ant script. Using Ant scripting and properties in this way facilitates automation and reuse of the scripts in different target environments.

# Example: How to Configure a Multi-Cluster Platform Domain Using WLST Offline

When you want to configure more than one cluster in a WebLogic Platform domain, you must explicitly retarget some of the resources, services, and applications. You must do this because of the following:

- The Configuration Wizard and WLST Offline support autoconfiguration for a single-cluster domain only. Autoconfiguration for a second cluster is not supported.
- There can be only one WebLogic Integration cluster in a domain. That is, there can be no WebLogic Integration resources in a second cluster.

Tip | A strategy for configuring two clusters in a WebLogic Platform domain is to leverage autoconfiguration for a single cluster as much as possible. You can designate the first cluster in the domain to be the WebLogic Integration cluster and the second cluster to be the WebLogic Portal cluster. Because a WebLogic Integration cluster requires JMS queues and topics, this strategy leverages autoconfiguration to set up these resources. You then target the remaining resources, services, and applications correctly. And, finally, you edit the `config.xml` file to add JMS resources for the second, WebLogic Portal cluster.

The following example illustrates how to create a WebLogic Platform domain that contains two clusters, as illustrated in Multi-Cluster Platform Domain Example, using WLST Offline.

Steps include:

- Create a Domain With Two Clusters
- Correct Targets for the Resources, Services, and Applications
- Manually Edit the config.xml File to Add JMS Resources for the Second Cluster

Note: For readability, the following code excerpts use actual values and not variables. For information about using WLST variables, see Define WLST Variables.

For more information about using WLST Offline, see the documentation and examples provided with the WLST Offline kit at the following URL: `https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=97`

#### Create a Domain With Two Clusters

The process used to configure a multi-cluster domain using WLST Offline is similar to the process illustrated in Example: How to Configure a Single-Cluster Platform Domain Using WLST Offline, except that you need to create two clusters rather than a single cluster.

For example, the following code excerpt performs the following tasks:

- Configures two clusters—WebLogic Integration cluster and a WebLogic Portal cluster.
- Configures four machines, two for the WebLogic Integration cluster, two for the WebLogic Portal cluster.
- Configures the Node Manager name, listen address, start properties—including `BEA_HOME`, `JAVA_HOME`, the directory root, and the `CLASSPATH` values—and the file containing the security policy for starting the server. For more information about configuring Node Manager, see Configuring Node Manager.
- Configures the Managed Servers, targeting them to a machine, and enables SSL to enable secure access to application resources.
- Configures the JMS JDBC Store for the WebLogic Portal cluster.

Compare this code excerpt to the equivalent excerpt for the single cluster domain, described in Configure the Cluster, Managed Servers, and Machines.

>     cd ('/')
>     # Define the servers
>     wli_ms1 = 'wlims1','host1',9111,9112,'wlimachine1'
>     wli_ms2 = 'wlims2','host2',9121,9122,'wlimachine2'
>     wli_mss = wli_ms1,wli_ms2
>     wli_clusterConfig = 'wlicluster','multicast1_addr',9101,wli_mss

>     wlp_ms1 = 'wlpms1','host3',9211,9212,'wlpmachine1'
>     wlp_ms2 = 'wlpms2','host4',9221,9222,'wlpmachine2'
>     wlp_mss = wlp_ms1,wlp_ms2
>     wlp_clusterConfig = 'wlpcluster','multicast2_addr',9201,wlp_mss

>     #Create the two clusters
>     clusterConfigs = wli_clusterConfig,wlp_clusterConfig

>     machines_created = ""
>     for clusterConfig in clusterConfigs:
>       cl_name, mc_addr, mc_port,mss = clusterConfig
>       cluster = create(cl_name, 'Cluster')

>       #Configure the machines
>       machine = None
>       cl_addr = ""

>       for msConfig in mss:
>         ms_name, ms_addr, ms_port, ms_ssl_port, ms_machine = msConfig

>         # check for existence of ms_machine
>         create_this_machine = 'yes'
>         if machines_created == "":
>           machines_created = ms_machine
>         else:
>           if machines_created.find(ms_machine) == -1:
>             machines_created = machines_created + "," + ms_machine
>           else:
>             create_this_machine = 'no'

>         if ms_machine != "" and create_this_machine == 'yes'
>           machine = create(ms_machine, 'Machine')

>           #Configure the Node Manager name and listen address
>           cd('Machine/' + ms_machine + '/NodeManager/' + ms_machine)
>           cmo.setName(ms_machine)
>           cmo.setListenAddress(ms_addr)
>           cd('../../../..')

>         #Configure the Managed Server, target it to a machine
>         ms = create(ms_name,'Server')
>         ms.setListenAddress(ms_addr)
>         ms.setListenPort(ms_port)

>         if machine != None:
>           ms.setMachine(machine)

>         cd('Server/' + ms_name + '/SSL/' + ms_name)
>         cmo.setEnabled(1)
>         cmo.setListenPort(ms_ssl_port)
>         cd('../../../..')

>         assign('Server', ms_name, 'Cluster', cl_name)

>         # Configure Node Manager StartServer properties
>         cd('Server/' + ms_name)
>         create(ms_name, 'ServerStart')
>         cd('ServerStart/' + ms_name)
>         cmo.setBeaHome('/bea')
>         cmo.setJavaHome('/bea/weblogic81/jrockit81sp4_142_05')
>         cmo.setRootDirectory('/bea/user_projects/domains/platform')
>         # See Table 3-4 for CLASSPATH settings
>         cmo.setClassPath('classpath')
>         cmo.setSecurityPolicyFile('/bea/weblogic81/server/lib/weblogic.policy')
>         cmo.setArguments('-Xms512m -Xmx512m -da -Dwlw.iterativeDev=false
>      -Dwlw.testConsole=false -Dwlw.logErrorsToConsole=true -Dweblogic.ProductionModeEnabled=true')
>         cmo.setUsername('user')
>         cmo.setPassword('password')
>         cd('../../../..')
>         # Accumulate addresses and ports for setting cluster address
>         cl_addr = cl_addr + ms_addr + ':' + str(ms_port) + ','

>     # Set the cluster address, multicast address, and multicast port
>     cl_addr = cl_addr[:-1] # slice off trailing ','
>     cluster.setClusterAddress(cl_addr)
>     cluster.setMulticastAddress(mc_addr)
>     cluster.setMulticastPort(mc_port)

>     #Configure the JMS JDBC Store for the WebLogic Portal Cluster
>     cd('/JDBCConnectionPool/cgJMSPool-nonXA')
>     connPoolMBean = cmo
>     cd('/JMSTemplate/TemporaryTmplt')
>     jmsTemplateMBean = cmo
>     cd('/')
>     jdbcstorePrefix = "cgJMSStore_wlp_auto_"
>     a = ['1', '2']
>     for n in a:
>       storename = jdbcstorePrefix + n
>       store = create(storename,"JMSJDBCStore")
>       store.setConnectionPool(connPoolMBean)
>       store.setPrefixName('wlp_' + n)

#### Correct Targets for the Resources, Services, and Applications

The Configuration Wizard and WLST Offline support autoconfiguration for single-cluster domains only. When creating two clusters, you need to manually correct the targets assigned for the resources, services, and applications, as described in the following procedure. (For more information about autoconfiguration, see Autoconfiguration Using the Configuration Wizard and WLST Offline.

Note: For default targeting requirements, refer to Deployment Targeting Reference - Single Cluster WebLogic Platform Domain. To identify resources, services, and application product components, see Default Domain Resource Reference - By Product Component.

1. Correct the targets for the system resources.

For example, unassign the `portalPool` and `bpmArchPool` JDBC connection pools from the WebLogic Integration and WebLogic Portal clusters, respectively.

>     unassign('JDBCConnectionPool', 'portalPool', 'Target', wliClusterName)
>     unassign('JDBCConnectionPool', 'bpmArchPool', 'Target', wlpClusterName)

2. Correct the targets for the WebLogic services.

For example, unassign the WebLogic Integration startup and shutdown classes from the WebLogic Portal cluster.

>     WLIStartupShutdownClasses = (('ShutdownClass','WLI Shutdown Class'),\
>        ('StartupClass','WLI Startup Class'),\
>        ('StartupClass','WLI Post-Activation Startup Class'))
>     for classNVpair in WLIStartupShutdownClasses:
>        cname,cvalue=classNVpair
>        unassign(cname, cvalue, 'Target', wlpClusterName)

3. Correct the targets for the applications.

1. Unassign all applications from the following resources: Administration Server, First Managed Server defined for the WebLogic Integration cluster, and WebLogic Integration and WebLogic Portal clusters

For example:

>     unassignAll('Application', 'Target', adminName)
>     unassignAll('Application', 'Target', wlims1Name)
>     unassignAll('Application', 'Target', wliClusterName)
>     unassignAll('Application', 'Target', wlpClusterName)

2. Re-assign the applications to the appropriate targets.

WLST Offline does not support resource names that contain period (".") or slash ("/") characters. Therefore, you must temporarily substitute all period (".") and slash ("/") characters in application names when assigning them to targets. Once assigned, you must restore the original application name for the application to function properly within the domain. For example, in the following excerpt, the following temporary substitutions have been made:

- `.workshop/worklist/EJB/ProjectBeans` has been temporarily renamed as follows:
  `_workshop_worklist_EJB_ProjectBeans`
- `.workshop/worklist/EJB/GenericStateless` has been temporarily renamed as follows:
  _workshop_worklist_EJB_`GenericStateless`

For example:

>     assign('Application', 'B2BDefaultWebApp', 'Target', adminName)
>     assign('Application', 'WLI AI RAR Upload', 'Target', adminName)
>     assign('Application', 'wliconsole', 'Target', adminName)
>     assign('Application', 'B2BDefaultWebApp', 'Target', wliClusterName)
>     assign('Application', '_workshop_worklist_EJB_ProjectBeans',\ 'Target', wliClusterName)
>     assign('Application', '_workshop_worklist_EJB_GenericStateless',\ 'Target', wliClusterName)
>     assign('Application', 'worklist', 'Target', wliClusterName)
>     assign('Application', 'WLIAdmin', 'Target', wliClusterName)
>     assign('Application', 'WLI Admin Helper', 'Target', wliClusterName)
>     ...

#### Manually Edit the config.xml File to Add JMS Resources for the Second Cluster

Manually edit the `config.xml` file to create the following resources for the second cluster, in this example, the WebLogic Portal cluster:

- JMS Server for each Managed Server

For example:

>     <JMSServer Name="cgJMSServer_wlp_auto_1"
>        Store="cgJMSStore_wlp_auto_1" Targets="wlpms1 (migratable)">
>        <JMSQueue JNDIName="jws.queue_wlp_auto_1"
>           Name="cgJWSQueue_wlp_auto_1" RedeliveryLimit="2"
>           StoreEnabled="default"/>
>     </JMSServer>
>     <JMSServer Name="cgJMSServer_wlp_auto_2"
>        Store="cgJMSStore_wlp_auto_2" Targets="wlpms2 (migratable)">
>        <JMSQueue JNDIName="jws.queue_wlp_auto_2"
>           Name="cgJWSQueue_wlp_auto_2" RedeliveryLimit="2"
>           StoreEnabled="default"/>
>     </JMSServer>

- Distributed queues

For example:

>     <JMSDistributedQueue JNDIName="jws.queue"
>        Name="dist_cgJWSQueue_wlp_auto" Targets="wlpcluster">
>        <JMSDistributedQueueMember JMSQueue="cgJWSQueue_wlp_auto_1"
>            Name="cgJWSQueue_wlp_auto_1_OF_cgJMSServer_wlp_auto_1"/>
>        <JMSDistributedQueueMember JMSQueue="cgJWSQueue_wlp_auto_2"
>            Name="cgJWSQueue_auto_2_OF_cgJMSServer_wlp_auto_2"/>
>     </JMSDistributedQueue>