WebLogic Server Command Reference

Using Command-Line Utilities to Configure a WebLogic Server Domain

WebLogic Server provides several command-line utilities that you can use to automate the creation of domains, servers, and resources. The following sections describe combining shell scripts with the weblogic.Server, weblogic.Admin, and weblogic.Deployer commands to automate typical configuration tasks:

Alternatively, you use one of the following techniques to automate the configuration of a WebLogic Server domain based on your familiarity with the WebLogic Server Template Builder or Ant:

Use the Template Builder to save an application, server configuration, and startup script as a configuration template. Then use the Configuration Wizard to create domains based on the configuration template. The Configuration Wizard includes a silent install option, which enables you to duplicate a domain on multiple machines without user interaction.

See "Creating Configuration Templates Using the Template Builder" in Creating WebLogic Configurations Using the Configuration Wizard and "Starting in Silent Mode" in Configuring WebLogic Platform.

Note: Although the documentation for the Template Builder and Configuration Wizard utilities is part of the WebLogic Platform documentation set, the utilities are installed with WebLogic Server and available for use even if you do not install WebLogic Platform.

Use the WebLogic Server Ant tasks. For almost all configuration needs, the Ant tasks and the weblogic.Server, weblogic.Admin, and weblogic.Deployer commands are functionally equivalent.

See Using Ant Tasks to Configure a WebLogic Server Domain.

Using Command-Line Utilities to Clone the MedRec Domain: Main Steps

The section Sample Korn Shell Script provides a sample script for cloning and slightly modifying the MedRec domain.

To create and configure a domain such as the MedRec sample domain, use a shell script to:

Set the required environment variables.

See Setting Up the Environment.

Create a skeletal domain with the java weblogic.Server command:

See Creating a Domain.

After the skeletal domain's Administration Server has completed its startup cycle, configure resources for the domain by invoking a series of weblogic.Admin commands that instantiate Administration MBeans. See:

For more information about MBeans in WebLogic Server, see "Overview of WebLogic JMX Services" in Programming WebLogic Management Services with JMX.

Invoke multiple weblogic.Deployer commands to deploy J2EE modules such as EJBs and Enterprise applications.

See Deploying Applications.

Setting Up the Environment

All WebLogic Server commands require an SDK to be specified in the environment's PATH variable and a set of WebLogic Server classes to be specified in the CLASSPATH variable.

Use the following script to add an SDK to PATH variable and the WebLogic Server classes to the CLASSPATH variable:

WL_HOME\server\bin\setWLSEnv.cmd (on Windows)
WL_HOME/server/bin/setWLSEnv.sh (on UNIX)

If you want to use JDBC resources to connect to a database, modify the environment as the database vendor requires. Usually this entails adding driver classes to the CLASSPATH variable and vendor-specific directories to the PATH variable. To set the environment that the sample Pointbase database requires as well as add an SDK to PATH variable and the WebLogic Server classes to the CLASSPATH variable, invoke the following script:

WL_HOME\samples\domains\medrec\setMedRecEnv.cmd (on Windows)
WL_HOME/samples/domains/medrec/setMedRecEnv.sh (on UNIX)

Creating a Domain

To create a domain named mymedrec with an Administration Server named myMedRecServer that listens on port 8001:

Create an empty directory named mymedrec.

Change to the empty directory and enter the following command:

java -Dweblogic.management.username=weblogic -Dweblogic.management.password=weblogic -Dweblogic.Domain=mymedrec -Dweblogic.Name=myMedRecServer -Dweblogic.ListenPort=8001 -Dweblogic.management.GenerateDefaultConfig=true weblogic.Server
When you invoke the weblogic.Server class in a directory that does not contain a config.xml file, WebLogic Server creates and starts a domain with an Administration Server. See Default Behavior.
Notes:

The value of the -Dweblogic.Domain option must match the name of the current directory.
The command specifies a listen port of 8001 because the sample MedRec domain that WebLogic Server installs listens on the default port 7001. If the sample MedRec domain is running, the 7001 listen port cannot be used by another server instance.
The -Dweblogic.management.GenerateDefaultConfig=true prevents the weblogic.Server class from prompting you for confirmations.

Creating JDBC Resources

The commands in Listing 2-1 create JDBC resources in the mymedrec domain.

Listing 2-1 Creating JDBC Resources

# Create a JDBC Connection Pool for Applications
CREATE_POOL myMedRecPoolXA 
driver="com.pointbase.xa.xaDataSource",
url=jdbc:pointbase:server://localhost:9093/demo,
props=user=medrec;password=medrec;
DatabaseName=jdbc:pointbase:server://localhost:9093/demo,maxCapacity=10

# Create a Transactional Data Source
CREATE -mbean mymedrec:Name=MedRecTxDataSource,Type=JDBCTxDataSource

# Configure the Transactional Data Source
SET -mbean mymedrec:Name=MedRecTxDataSource,Type=JDBCTxDataSource 
-property JNDIName "MedRecTxDataSource"

SET -mbean mymedrec:Name=MedRecTxDataSource,Type=JDBCTxDataSource 
-property PoolName "myMedRecPoolXA"

# Create another JDBC Connection Pool for the JMS JDBC Store
CREATE_POOL myMedRecPool driver="com.pointbase.jdbc.jdbcUniversalDriver",
url=jdbc:pointbase:server://localhost:9093/demo,
props=user=medrec;password=medrec,
DatabaseName=jdbc:pointbase:server://localhost:9093/demo,maxCapacity=10

When invoked by the weblogic.Admin BATCHUPDATE command, the commands in Listing 2-1 do the following (see BATCHUPDATE):

Create a JDBC connection pool and configure it to connect to the MedRec sample PointBase database, which WebLogic Server installs.

The database listens on port 9093 and is named demo.
The CREATE_POOL command creates an MBean of type JDBCConnectionPool whose object name is mymedrec:Name=myMedRecPoolXA,Type=JDBCConnectionPool.
For more information, see:

CREATE_POOL
"JDBC Configuration Namespace" in Programming WebLogic Management Services with JMX.

Create a JDBC transactional data source by instantiating a JDBCTxDataSourceMBean Administration MBean.

The CREATE -mbean command creates an MBean and specifies the MBean's WebLogicObjectName. In this object name:

mymedrec: specifies the name of the WebLogic Server domain.
Name=MedRecTxDataSource provides a unique name for the JDBC transactional data source you want to create.
Type=JDBCTxDataSource specifies the type of MBean to create.

Configure the transactional data source by setting attributes on the JDBCTxDataSourceMBean that you instantiated.

To see all attributes and legal values of the JDBCTxDataSourceMBean, refer to the Javadoc.

Create an additional JDBC connection pool that uses the universal driver instead of the XA driver. This connection pool will be used by the JMS resources, which do not support the XA driver.

Using the Sample Commands

To create JDBC resources in the mymedrec domain:

Copy the commands in Listing 2-1 and paste them into an empty text file.

Open a command prompt (shell) and invoke WL_HOME\common\bin\startPointBase.sh.

This script starts a PointBase database that the mymedrec domain uses.

If you haven't already started the Administration Server for the mymedrec domain:

Change to the mymedrec directory that you created in Creating a Domain.

Invoke one of the following scripts:

WL_HOME\samples\domains\medrec\setMedRecEnv.cmd (on Windows) WL_HOME/samples/domains/medrec/setMedRecEnv.sh (on UNIX)

Enter the following command:

java -Dweblogic.management.username=weblogic -Dweblogic.management.password=weblogic -Dweblogic.Name=myMedRecServer -Dweblogic.ListenPort=8001 weblogic.Server

Open another command prompt (shell) and do the following:

Invoke WL_HOME\samples\domains\medrec\setMedRecEnv.cmd or setMedRecEnv.sh.

Invoke the following command:

java weblogic.Admin -url localhost:7001 -username weblogic -password weblogic BATCHUPDATE -batchFile c:\myfile -batchCmdVerbose
where c:\myfile is the name of a text file that contains the commands in Listing 2-1.
See BATCHUPDATE.

Creating JMS Resources

The commands in Listing 2-2 create JMS resources in the mymedrec domain.

Listing 2-2 Creating JMS Resources

# Creating a JMS Connection Factory
CREATE -mbean mymedrec:Name=MedRecQueueFactory,Type=JMSConnectionFactory

# Configuring the JMS Connection Factory
SET -mbean mymedrec:Name=MedRecQueueFactory,Type=JMSConnectionFactory 
-property JNDIName "jms/MedRecQueueConnectionFactory"

SET -mbean mymedrec:Name=MedRecQueueFactory,Type=JMSConnectionFactory 
-property XAServerEnabled "true"

#
# Creating and Configuring a JMS JDBC Store
CREATE -mbean mymedrec:Name=MedRecJDBCStore,Type=JMSJDBCStore

SET -mbean mymedrec:Name=MedRecJDBCStore,Type=JMSJDBCStore 
-property ConnectionPool "mymedrec:Name=myMedRecPool,Type=JDBCConnectionPool"

SET -mbean mymedrec:Name=MedRecJDBCStore,Type=JMSJDBCStore 
-property PrefixName "MedRec"

# Creating and Configuring a JMS Server
CREATE -mbean mymedrec:Name=MedRecJMSServer,Type=JMSServer

SET -mbean mymedrec:Name=MedRecJMSServer,Type=JMSServer 
-property Store "mymedrec:Name=MedRecJDBCStore,Type=JMSJDBCStore"

# Creating and Configuring a Queue
CREATE -mbean 
mymedrec:JMSServer=MedRecJMSServer,Name=RegistrationQueue,Type=JMSQueue

SET -mbean 
mymedrec:JMSServer=MedRecJMSServer,Name=RegistrationQueue,Type=JMSQueue 
-property JNDIName "jms/REGISTRATION_MDB_QUEUE"

# Creating and Configuring an Additional Queue
CREATE -mbean mymedrec:JMSServer=MedRecJMSServer,Name=MailQueue,Type=JMSQueue

SET -mbean mymedrec:JMSServer=MedRecJMSServer,Name=MailQueue,Type=JMSQueue 
-property JNDIName "jms/MAIL_MDB_QUEUE"

# Creating and Configuring an Additional Queue
CREATE -mbean mymedrec:JMSServer=MedRecJMSServer,Name=XMLQueue,Type=JMSQueue

SET -mbean mymedrec:JMSServer=MedRecJMSServer,Name=XMLQueue,Type=JMSQueue 
-property JNDIName "jms/XML_UPLOAD_MDB_QUEUE"

When invoked by the weblogic.Admin BATCHUPDATE command, the commands do the following (see BATCHUPDATE):

Create a JMS connection factory by instantiating a JMSConnectionFactoryMBean.

The CREATE -mbean command creates an MBean and specifies the MBean's WebLogicObjectName. (See "JMS Configuration Namespace" in Programming WebLogic Management Services with JMX.) In this object name:

mymedrec: specifies the name of the WebLogic Server domain.
Name=MedRecQueueFactory provides a unique name for the JMS connection factory you want to create.
Type=JMSConnectionFactory specifies the type of MBean to create.

Configure the JMS connection factory by setting attributes on the JMSConnectionFactory that you instantiated.

In the SET command:

The -mbean argument specifies the WebLogicObjectName of the JMSConnectionFactory that you instantiated.
The -property argument specifies an MBean attribute name and its value.

To see all attributes and legal values of the JMSConnectionFactory, refer to the Javadoc.

Create and configure a JMS store that uses JDBC and a database by instantiating and setting values on a JMSJDBCStoreMBean.

The command that sets the value of the ConnectionPool attribute specifies the WebLogicObjectName of a JDBC connection pool because the JMSJDBCStoreMBean Javadoc indicates that the ConnectionPool attribute must be a JDBCConnectionPoolMBean object name:
public void setConnectionPool(JDBCConnectionPoolMBean connectionPool)

Create and configure a JMS Server by instantiating and setting values on a JMSServerMBean.

The command that sets the value of the Store attribute specifies the WebLogicObjectName of a JMS store because the JMSServerMBean Javadoc indicates that the Store attribute must be an object name of type JMSStoreMBean:
public void setStore(JMSStoreMBean store)
JMSJDBCStore is a subtype of JMSStoreMBean.

Create and configure three JMS queues by instantiating and setting values on three MBeans of type JMSQueueMBean.

The queues are named RegistrationQueue, MailQueue and XMLQueue.
To see all attributes and legal values of the JMSQueueMBean, refer to the Javadoc.

Creating Mail Resources

The commands in Listing 2-3 add email capabilities to the MedRec applications in the mymedrec domain by creating and configuring a MailSessionMBean. You can save the commands in a text file and invoke them with the weblogic.Admin BATCHUPDATE command (see BATCHUPDATE).

Note: To see all attributes and legal values of the MailSessionMBean, refer to the Javadoc. For more information about the WebLogic Server mail service, see "Mail" in the Administration Console Online Help.

Listing 2-3 Creating Mail Resources

CREATE -mbean mymedrec:Name=MedicalRecordsMailSession,Type=MailSession

SET -mbean mymedrec:Name=MedicalRecordsMailSession,Type=MailSession 
-property JNDIName "mail/MedRecMailSession"

SET -mbean mymedrec:Name=MedicalRecordsMailSession,Type=MailSession 
-property Properties "mail.user=joe;mail.host=mail.mycompany.com"

Creating and Configuring Managed Servers

In a production environment, BEA recommends that you create one or more Managed Servers to host applications and resources. Use the Administration Server only to configure and manage the domain.

The commands in Listing 2-4 create and configure a Managed Server in the mymedrec domain.

Listing 2-4 Creating and Configuring Managed Servers

# Creating and Configuring a Server
CREATE -mbean mymedrec:Name=MedRecServer1,Type=Server

SET -mbean mymedrec:Name=MedRecServer1,Type=Server 
-property ListenPort "8011"

# Targeting Resources to MedRecServer1
SET -mbean mymedrec:Name=MedRecPoolXA,Type=JDBCConnectionPool 
-property Targets "mymedrec:Name=myMedRecServer1,Type=Server"

SET -mbean mymedrec:Name=MedRecTxDataSource,Type=JDBCTxDataSource 
-property Targets "mymedrec:Name=myMedRecServer1,Type=Server"

SET -mbean mymedrec:Name=myMedRecPoolXA,Type=JDBCConnectionPool 
-property Targets "mymedrec:Name=myMedRecServer1,Type=Server"

SET -mbean mymedrec:Name=MedRecQueueFactory,Type=JMSConnectionFactory 
-property Targets "mymedrec:Name=myMedRecServer1,Type=Server"

SET -mbean mymedrec:Name=MedRecJMSServer,Type=JMSServer 
-property Targets "mymedrec:Name=myMedRecServer1,Type=Server"

SET -mbean mymedrec:Name=MedicalRecordsMailSession,Type=MailSession 
-property Targets "mymedrec:Name=myMedRecServer1,Type=Server"

When invoked by the weblogic.Admin BATCHUPDATE command, the commands do the following (see BATCHUPDATE):

Create a server instance named myMedRecServer1 by instantiating a ServerMBean.

The CREATE -mbean command creates an MBean and specifies the MBean's WebLogicObjectName.

Configure myMedRecServer1 to listen on port 8011 by setting the ListenPort attribute of myMedRecServer1's ServerMBean.

Make resources available to the myMedRecServer1 Managed Server by setting the Targets attribute of the resources' MBeans.

For example, to make the myMedRecPoolXA JDBC connection pool available to myMedRecServer1, you set the Targets attribute of the myMedRecPoolXA's JDBCConnectionPoolMBean. The JDBCConnectionPoolMBean Javadoc indicates that the Targets attribute must be an object name of type ServerMBean:
public void setTargets(TargetMBean[] Targets)
ServerMBean is a subtype of TargetMBean. See Using weblogic.Admin Commands to Target Resources.

Configuring Machines and Node Manager Properties

The commands in Listing 2-5, configure Machines and Node Manager properties in the mymedrec domain.

This is a common task for domains that contain multiple server instances. By configuring machines and Node Manager properties for a server, the server can be started and managed by a Node Manager. See "Overview of Node Manager" in Configuring and Managing WebLogic Server.

Listing 2-5 Configuring Machines and Node Manager Properties

# Create a Machine 
CREATE -mbean mymedrec:Name=WLSHost,Type=Machine

SET -mbean mymedrec:Machine=WLSHost,Name=WLSHost,Type=NodeManager  
-property ListenAddress WLSHost -property ListenPort 5560

# Assign the Machine to a Server
SET  -mbean mymedrec:Name=myMedRecServer1,Type=Server 
-property Machine "mymedrec:Name=WLSHost,Type=Machine"

When invoked by the weblogic.Admin BATCHUPDATE command, the commands do the following (see BATCHUPDATE):

Create a machine by instantiating a MachineMBean.

The CREATE -mbean command creates an MBean and specifies the MBean's WebLogicObjectName. (See "Machines and Node Manager Configuration Namespace" in Programming WebLogic Management Services with JMX.) In this object name:

mymedrec: specifies the name of the WebLogic Server domain.
Name=WLHost1 provides a unique name for the machine you want to create. By convention, the machine name reflects the name of the computer that the machine represents. See "Machines" in the Administration Console Online Help.
Type=Machine specifies the type of MBean to create.

Configure a NodeManagerMBean for the machine. When you create a MachineMBean instance, WebLogic Server also creates a NodeManagerMBean to specify the listen address, listen port, and security information that a server instance uses to communicate with a Node Manager running on a specific machine.

The example commands set non-default values for the ListenAddress and ListenPort properties. In the NodeManagerMBean object name:

mymedrec: specifies the name of the WebLogic Server domain.
Machine=WLSHost indicates that the NodeManagerMBean is a child of the WLSHost MachineMBean. (See "Machines and Node Manager Configuration Namespace" in Programming WebLogic Management Services with JMX.)
Name=WLHost1 follows the WebLogic Server convention of having child objects reflect the object name of the parent.
Type=NodeManager specifies the type of MBean to create.

To see all attributes and legal values of the NodeManagerMBean, refer to the Javadoc.

Assign the machine to myMedRecServer1 by setting the Machine attribute of myMedRecServer1's ServerMBean. Assigning a machine to a server enables the server to be started by the machine's Node Manager.

The ServerMBean Javadoc indicates that the Machine attribute must be an object name of type MachineMBean:
public void setMachine(MachineMBean machine)

Deploying Applications

The weblogic.Deployer commands in Listing 2-6 deploy the sample MedRec applications in the mymedrec domain.

Listing 2-6 Deploying Applications

java weblogic.Deployer -url t3://localhost:8001 -username weblogic 
-password weblogic -targets myMedRecServer1 -name MedRecEAR 
-deploy D:\bea\weblogic81\samples\server\medrec\dist\medrecEar

java weblogic.Deployer -url t3://localhost:8001 -username weblogic 
-password weblogic -targets myMedRecServer1 -name PhysicianEAR 
-deploy D:\bea\weblogic81\samples\server\medrec\dist\physicianEar

java weblogic.Deployer -url t3://localhost:8001 -username weblogic 
-password weblogic -targets myMedRecServer1 -name StartupEAR 
-deploy D:\bea\weblogic81\samples\server\medrec\dist\startupEar

Notes:

The weblogic.Deployer command does not provide an equivalent to the weblogic.Admin BATCHUPDATE command, so you must invoke java weblogic.Deployer separately for each application that you want to deploy.
You must invoke these commands on the computer that hosts the Administration Server for the mymedrec domain.
Because the MedRec applications use JDBC connection pools, you must specify the JDBC driver in the CLASSPATH environment variable. See Setting Up the Environment.
The commands specify the mymedrec domain by providing the listen address for the Administration Server in the mymedrec domain (localhost:8001).
In the sample commands, the application files are located in the D:\bea\weblogic81\samples\server\medrec\src directory.
To deploy the applications onto the myMedRecServer1 Managed Server, include the -targets myMedRecServer1 argument. If the myMedRecServer1 server instance is active when you invoke the weblogic.Deployer command, deployment initiates immediately. Otherwise, deployment initiates when you start the myMedRecServer1 server instance.

See "weblogic.Deployer Utility" in Deploying WebLogic Server Applications.

Sample Korn Shell Script

This section describes an example Korn shell script that creates and configures a domain as described in Using Command-Line Utilities to Clone the MedRec Domain: Main Steps.

To use the sample Korn shell script:

Save Listing 2-7 as a shell script named CreateDomain.sh.

BEA recommends that you save this script in an empty directory. By default, the shell script creates a domain directory named.\mymedrec. That is, the mymedrec directory is a child of the directory from which you invoke the command.

Save Listing 2-8 in a text file named ConfigDomain.txt and locate it in the same directory as CreateDomain.sh.

Open a Korn shell and set up the environment as follows:

Invoke WL_HOME\common\bin\startPointBase.sh.

This script starts a PointBase database that the sample domain uses.

Invoke WL_HOME\samples\domains\medrec\setMedRecEnv.sh.

This script adds the required WebLogic Server classes and PointBase classes to the CLASSPATH variable and other required programs to the PATH variable.

Invoke CreateDomain.sh.

The CreateDomain.sh script:

Creates a domain and starts the domain's Administration Server.
Determines that the mymedrec domain's Administration Server has successfully started by periodically invoking the weblogic.Admin CONNECT command.

The CONNECT command connects to a WebLogic Server instance and returns two numbers representing the total time for each round trip and the average amount of time (in milliseconds) that each connection is maintained. See CONNECT.

Invokes weblogic.Admin BATCHUPDATE to configure resources.

To deploy the MedRec sample applications:

Change to the mymedrec directory that the CreateDomain.sh script created.

Invoke the following command:

java -Dweblogic.Name=myMedRecServer1 
-Dweblogic.management.server=http://localhost:8001 weblogic.Server

&

After the myMedRecServer1 instance starts, invoke the weblogic.Deployer commands described in Deploying Applications.

Listing 2-7 Korn Shell Script for Recreating the MedRec Domain

#!/bin/sh

########################
# Defining Functions   #
########################

# Wrapper function for weblogic.Admin
wladmin() 
{

  java weblogic.Admin -username $ADMINUSER -password $ADMINPASS `
       -adminurl $ADMINHOST:$ASPORT $*
}

# This function waits for a server to boot, if server is running, sets
# SERVERSTATE var to "RUNNING", otherwise, "SHUTDOWN"
#
# Params:
#   $1    Wait interval in seconds
#   $2    Max wait period, in seconds
#

WaitForServer()
{
  WAIT_INTERVAL=${1:-10}
  MAX_WAIT=${2:-120}
  CONNECTCMD="wladmin connect 1"
  CONNECTRESPONSE=
  CONNECTED=

  let total_wait=0
  while test "$CONNECTED" != "Connection" && test total_wait -lt MAX_WAIT
  do
    sleep 10
    let "total_wait=$total_wait+$WAIT_INTERVAL"
    echo Attempting to connect to server...
    CONNECTRESPONSE="\Q$CONNECTCMD\Q"
    CONNECTED="\Qecho $CONNECTRESPONSE | cut -d: -f1\Q"
    echo "Response to connect command: $CONNECTRESPONSE"   
  done

  # Set the status so the caller can check the result
  if [ "$CONNECTED" == "Connection" ]; then
    SERVERSTATE="RUNNING"
    echo Connected to server!
  else
    SERVERSTATE="SHUTDOWN"
    echo Could not connect to server
  fi
}

# This function creates a new domain and starts the Administration
# Server.
#
CreateDomain() {
 Echo "Starting server $SERVERNAME"
  java -Dweblogic.management.GenerateDefaultConfig=true `
    -Dweblogic.management.username=${ADMINUSER} `
    -Dweblogic.management.password=${ADMINPASS} `
    -Dweblogic.Domain=${DOMAIN} `
    -Dweblogic.Name=${SERVERNAME} `
    -Dweblogic.ListenPort=${ASPORT} `
    weblogic.Server > ${SERVERNAME}.out 2>&1 &

  WaitForServer 10 120
}

###########################
# Setting the Environment #
###########################
# Override values in the script with any
# values supplied from the command line.
if [ $# -gt 0 ]; then
  echo Setting environment variables $*
  export $*
fi

# Set script variables.
PROTOCOL=t3
ADMINUSER=${ADMINUSER:-weblogic}
ADMINPASS=${ADMINPASS:-weblogic}
ADMINHOST=${ADMINHOST:-localhost}
ASPORT=${ASPORT:-8001}

DOMAIN=${DOMAIN:-mymedrec}
DOMAINDIR=${DOMAINDIR:-$DOMAIN}
SERVERNAME=${SERVERNAME:-MedRecServer}

# Check for environment variables. 
if [ -z "$WL_HOME" ]; then
  echo "Need to set WL_HOME first!"
  exit 1
fi

###########################
# Invoking the Functions  #
###########################

# Check to see if server is runningConnected 
SERVERSTATE="" # reset result of Wait function
WaitForServer 5 5
if [ "$SERVERSTATE" == "RUNNING" ]; then
  echo "Server is already running on port $ASPORT!"
  exit 1
fi

# Create the domain directory.
mkdir ${DOMAINDIR}
status=$?
 if [ $status != 0 ]; then
    echo "Could not create domain directory ${DOMAINDIR}"
    exit 1
  fi

# CD to the domain directory and create the domain.
startDir=\Qpwd\Q
cd ${DOMAINDIR}
CreateDomain

#Return to starting location
cd $startDir

#Use weblogic.Admin BATCHUPDATE command to configure resources
wladmin BATCHUPDATE -batchFile ConfigDomain.txt -batchCMDVerbose `
-continueOnError

You can save the commands in Listing 2-8 in a text file named ConfigDomain.txt and invoke them with the weblogic.Admin BATCHUPDATE command in Listing 2-7. Make sure that each command is on a separate, single line. For example, "CREATE_POOL myMedRecPoolXA
driver="com.pointbase.xa.xaDataSource",
url=jdbc:pointbase:server://localhost:9093/demo,
props=user=medrec;password=medrec;
DatabaseName=jdbc:pointbase:server://localhost:9093/demo,maxCapacity=10" must be on a single line.

Listing 2-8 Input for BATCHUPDATE Command

# Commands for weblogic.Admin BATCHUPDATE

############################
# Creating JDBC Resources  #
############################

# Create a JDBC Connection Pool for Applications
CREATE_POOL myMedRecPoolXA 
driver="com.pointbase.xa.xaDataSource",
url=jdbc:pointbase:server://localhost:9093/demo,
props=user=medrec;password=medrec;
DatabaseName=jdbc:pointbase:server://localhost:9093/demo,maxCapacity=10

# Create a Transactional Data Source
CREATE -mbean mymedrec:Name=MedRecTxDataSource,Type=JDBCTxDataSource

# Configure the Transactional Data Source
SET -mbean mymedrec:Name=MedRecTxDataSource,Type=JDBCTxDataSource 
-property JNDIName "MedRecTxDataSource"

SET -mbean mymedrec:Name=MedRecTxDataSource,Type=JDBCTxDataSource 
-property PoolName "myMedRecPoolXA"

# Create another JDBC Connection Pool for the JMS JDBC Store
CREATE_POOL myMedRecPool driver="com.pointbase.jdbc.jdbcUniversalDriver",
url=jdbc:pointbase:server://localhost:9093/demo,
props=user=medrec;password=medrec,
DatabaseName=jdbc:pointbase:server://localhost:9093/demomaxCapacity=10

############################
# Creating JMS Resources  #
############################

# Creating a JMS Connection Factory
CREATE -mbean mymedrec:Name=MedRecQueueFactory,Type=JMSConnectionFactory

# Configuring the JMS Connection Factory
SET -mbean mymedrec:Name=MedRecQueueFactory,Type=JMSConnectionFactory 
-property JNDIName "jms/MedRecQueueConnectionFactory"

SET -mbean mymedrec:Name=MedRecQueueFactory,Type=JMSConnectionFactory 
-property XAServerEnabled "true"

#
# Creating and Configuring a JMS JDBC Store
CREATE -mbean mymedrec:Name=MedRecJDBCStore,Type=JMSJDBCStore

SET -mbean mymedrec:Name=MedRecJDBCStore,Type=JMSJDBCStore 
-property ConnectionPool "mymedrec:Name=myMedRecPool,Type=JDBCConnectionPool"

SET -mbean mymedrec:Name=MedRecJDBCStore,Type=JMSJDBCStore 
-property PrefixName "MedRec"

# Creating and Configuring a JMS Server
CREATE -mbean mymedrec:Name=MedRecJMSServer,Type=JMSServer

SET -mbean mymedrec:Name=MedRecJMSServer,Type=JMSServer 
-property Store "mymedrec:Name=MedRecJDBCStore,Type=JMSJDBCStore"

# Creating and Configuring a Queue
CREATE -mbean 
mymedrec:JMSServer=MedRecJMSServer,Name=RegistrationQueue,Type=JMSQueue

SET -mbean 
mymedrec:JMSServer=MedRecJMSServer,Name=RegistrationQueue,Type=JMSQueue 
-property JNDIName "jms/REGISTRATION_MDB_QUEUE"

# Creating and Configuring an Additional Queue
CREATE -mbean mymedrec:JMSServer=MedRecJMSServer,Name=MailQueue,Type=JMSQueue

SET -mbean mymedrec:JMSServer=MedRecJMSServer,Name=MailQueue,Type=JMSQueue 
-property JNDIName "jms/MAIL_MDB_QUEUE"

# Creating and Configuring an Additional Queue
CREATE -mbean mymedrec:JMSServer=MedRecJMSServer,Name=XMLQueue,Type=JMSQueue

SET -mbean mymedrec:JMSServer=MedRecJMSServer,Name=XMLQueue,Type=JMSQueue 
-property JNDIName "jms/XML_UPLOAD_MDB_QUEUE"

############################
# Creating Mail Resources  #
############################
CREATE -mbean mymedrec:Name=MedicalRecordsMailSession,Type=MailSession

SET -mbean mymedrec:Name=MedicalRecordsMailSession,Type=MailSession 
-property JNDIName "mail/MedRecMailSession"

SET -mbean mymedrec:Name=MedicalRecordsMailSession,Type=MailSession 
-property Properties "mail.user=joe;mail.host=mail.mycompany.com"

#############################################
# Creating and Configuring a Managed Server #
#############################################

# Creating and Configuring a Server
CREATE -mbean mymedrec:Name=myMedRecServer1,Type=Server

SET -mbean mymedrec:Name=myMedRecServer1,Type=Server 
-property ListenPort "8011"

# Targeting Resources to myMedRecServer1
SET -mbean mymedrec:Name=myMedRecPool,Type=JDBCConnectionPool 
-property Targets "mymedrec:Name=myMedRecServer1,Type=Server"

SET -mbean mymedrec:Name=MedRecTxDataSource,Type=JDBCTxDataSource 
-property Targets "mymedrec:Name=myMedRecServer1,Type=Server"

SET -mbean mymedrec:Name=myMedRecPoolXA,Type=JDBCConnectionPool 
-property Targets "mymedrec:Name=myMedRecServer1,Type=Server"

SET -mbean mymedrec:Name=MedRecQueueFactory,Type=JMSConnectionFactory 
-property Targets "mymedrec:Name=myMedRecServer1,Type=Server"

SET -mbean mymedrec:Name=MedRecJMSServer,Type=JMSServer 
-property Targets "mymedrec:Name=myMedRecServer1,Type=Server"

SET -mbean mymedrec:Name=MedicalRecordsMailSession,Type=MailSession 
-property Targets "mymedrec:Name=myMedRecServer1,Type=Server"

##############################################
# Configuring Machine and Node Manager Props #
##############################################

# Create a Machine 
CREATE -mbean mymedrec:Name=WLSHost,Type=Machine

SET -mbean mymedrec:Machine=WLSHost,Name=WLSHost,Type=NodeManager  
-property ListenAddress WLSHost -property ListenPort 5560

# Assign the Machine to a Server
SET  -mbean mymedrec:Name=myMedRecServer1,Type=Server 
-property Machine "mymedrec:Name=WLSHost,Type=Machine"

Using weblogic.Admin Commands to Manage Users and Groups

In the WebLogic Security Service, an Authentication provider is the software component that proves the identity of users or system processes. An Authentication provider also remembers, transports, and makes that identity information available to various components of a system when needed. A security realm can use different types of Authentication providers to manage different sets of users and groups. See "Authentication Providers" in Developing Security Providers for WebLogic Server.

You can use the weblogic.Admin utility to invoke operations on the following types of Authentication providers:

The WebLogic Authentication provider, weblogic.management.security.authentication.AuthenticatorMBean.

By default, all security realms use this Authentication provider to manage users and groups.

The LDAP Authentication providers that extend weblogic.management.security.authentication.LDAPAuthenticatorMBean.
Custom Authentication providers that extend weblogic.security.spi.AuthenticationProvider and extend the optional
Authentication SSPI MBeans. See "SSPI MBean Quick Reference" in Developing Security Providers for WebLogic Server.

The following sections describe basic tasks for managing users and groups with the weblogic.Admin utility:

For information about additional tasks that the AuthenticationProvider and the optional MBeans support, refer to the Javadoc for the weblogic.management.security.authentication package.

Finding the Object Name for an AuthenticationProvider MBean

To invoke operations on an Authentication provider, you must specify the object name of the provider's AuthenticationProviderMBean.

The object name of the WebLogic Authentication provider is:
Security:Name=realmNameDefaultAuthenticator

where realmName is the name of a security realm. For example, Security:Name=myrealmDefaultAuthenticator.

The object name of the LDAP Authentication providers is:
Security:Name=realmNameLDAPAuthenticator

BEA recommends that you follow a similar convention when you create your own Authentication providers:

Security:Name=realmNameAuthenticatorName

If you use the Administration Console to add an Authentication provider to the realm, your AuthenticationProviderMBean name will follow the recommended naming convention.

To verify the object name of an AuthenticationProviderMBean, use the weblogic.Admin QUERY command. See QUERY.

Creating a User

To create a user, invoke the UserEditorMBean.createUser method, which is extended by the security realm's AuthenticationProvider MBean. See the Javadoc for the createUser method.

The method requires three input parameters:

username password user-description

Separate the parameters with a space. If any parameter contains a space, surround it with quotes.

The following example invokes createUser on the WebLogic Authentication provider:

java weblogic.Admin -adminurl localhost:8001 -username weblogic -password weblogic invoke -mbean Security:Name=myrealmDefaultAuthenticator -method createUser my-user1 mypassword "my user"

If the command succeeds, it prints OK to standard out.

Adding a User to a Group

To add a user to a group, invoke the GroupEditorMBean.addMemberToGroup method, which is extended by the security realm's AuthenticationProvider MBean. See the Javadoc for the addMemberToGroup method.

The method requires two input parameters:

groupname username

The following example invokes addMemberToGroup on the WebLogic Authentication provider:

java weblogic.Admin -adminurl localhost:8001 -username weblogic -password weblogic invoke -mbean Security:Name=myrealmDefaultAuthenticator -method addMemberToGroup Administrators my-user1

If the command succeeds, it prints OK to standard out.

Verifying Whether a User is a Member of a Group

To verify whether a user is a member of a group, invoke the GroupEditorMBean.isMember method, which is extended by the security realm's AuthenticationProvider MBean. See the Javadoc for the isMember method.

The method requires three input parameters:

groupname username boolean

where boolean specifies whether the command searches within child groups. If you specify true, the command returns true if the member belongs to the group that you specify or to any of the groups contained within that group.

The following example invokes isMember on the WebLogic Authentication provider:

java weblogic.Admin -adminurl localhost:8001 -username weblogic -password weblogic invoke -mbean Security:Name=myrealmDefaultAuthenticator -method isMember Administrators weblogic true

If the user is a member of the group, the command prints true to standard out.

Listing Groups to Which a User Belongs

To see a list of groups that contain a user or a group, invoke the MemberGroupListerMBean.listMemberGroups method, which is extended by the security realm's AuthenticationProvider MBean. See the Javadoc for the listMemberGroups method.

The method requires one input parameter:

memberUserOrGroupName

where memberUserOrGroupName specifies the name of an existing user or a group.

The following example invokes listMemberGroups on the WebLogic Authentication provider:

java weblogic.Admin -adminurl localhost:8001 -username weblogic -password weblogic invoke -mbean Security:Name=myrealmDefaultAuthenticator -method listMemberGroups my-user1

The method returns a cursor, which refers to a list of names. The weblogic.management.utils.NameLister.haveCurrent, getCurrentName, and advance methods iterate through the returned list and retrieve the name to which the current cursor position refers. See the Javadoc for the weblogic.management.utils.NameLister interface.

Limiting Group Membership Searching in an LDAP Server

Unlimited, recursive searches for group membership can take up considerable time and produce a performance bottleneck. To control the depth of group membership searches, you can set the value of GroupMembershipSearching on the WebLogic Authentication provider, LDAP Authentication providers, or any other Authentication provider that implements the AuthenticationProvider interface.

To limit group searches, set the value of GroupMembershipSearching on the WebLogic Authentication provider or LDAP Authentication providers to limited. The GroupMembershipSearching attribute has the following valid values:

unlimited limited

where limited specifies whether the command searches within one or more levels of a nested group hierarchy. If you specify a limited search, the MaxGroupMembershipSearchLevel attribute must be specified. The default is an unlimited search.

The MaxGroupMembershipSearchLevel attribute specifies how many levels of group membership to search. Valid values are 0 and positive integers, where 0 specifies that the command searches only within direct group memberships. A positive integer specifies the number of levels to search.

For example, when searching for membership in Group A, 0 indicates that only direct members of Group A will be found. If Group B is a member of Group A, the members of Group B will not be found by this search. If the attribute is set to 1, a search for membership in Group A will return direct members of Group A and any members of groups which are direct members of Group A. If Group B is a member of Group A, the members of Group B will also be found by this search. However, if Group C is a member of Group B, the members of Group C will not be found by this search.

See the Javadoc for GroupMembershipSearching and MaxGroupMembershipSearchLevel.

The following example gets the GroupMembershipSearching property on the WebLogic Authentication provider:

java weblogic.Admin -adminurl localhost:7001 -username weblogic -password weblogic get -mbean Security:Name=myrealmDefaultAuthenticator -pretty -property GroupMembershipSearching -commotype

Listing Users and Groups in a Security Realm

To see a list of user or group names, you invoke a series of methods, all of which are available through the AuthenticationProvider interface:

The GroupReaderMBean.listGroups and UserReaderMBean.listUsers methods take two input parameters: a pattern of user or group names to search for, and the maximum number of names that you want to retrieve.

Because a security realm can contain thousands (or more) of user and group names that match the pattern, the methods return a cursor, which refers to a list of names.
See Javadoc for the listGroups method or the Javadoc for the listUsers method.

The weblogic.management.utils.NameLister.haveCurrent, getCurrentName, and advance methods iterate through the returned list and retrieve the name to which the current cursor position refers. See the Javadoc for the weblogic.management.utils.NameLister interface.

Because the weblogic.Admin utility does not provide the necessary control structures, you must wrap these methods in a script. See Example: Korn Shell Script for Listing Users.

The weblogic.management.utils.NameLister.close method releases any server-side resources that are held on behalf of the list.

Example: Korn Shell Script for Listing Users

The Korn shell script in Listing 2-9 retrieves up to 10 user names in a security realm.

Listing 2-9 Unix Korn Shell Script for Listing All Users

#!/bin/ksh

HOST=localhost
PORT=8001
USER=weblogic
PASS=weblogic
PROTOCOL=   # can be blank, t3, t3s, http, https, etc.

if [ -z "$PROTOCOL" ]; then
   URL=$HOST:$PORT
else
   URL=$PROTOCOL://$HOST:$PORT
fi

Cursor=$(java weblogic.Admin -adminurl $URL -username $USER `
         -password $PASS invoke `
         -mbean Security:Name=myrealmDefaultAuthenticator `
         -method listUsers \* 10)

haveCurrent="true"

while [[ "$haveCurrent" = "true" ]]; do
    haveCurrent=$(java weblogic.Admin -adminurl $URL `
     -username $USER -password $PASS invoke `
     -mbean Security:Name=myrealmDefaultAuthenticator `
     -method haveCurrent $Cursor)

    if [[ "$haveCurrent" = "true" ]]; then

       Username=$(java weblogic.Admin -adminurl $URL `
            -username $USER -password $PASS invoke `
            -mbean Security:Name=myrealmDefaultAuthenticator `
            -method getCurrentName $Cursor)

        print $Username

        java weblogic.Admin -adminurl $URL -username $USER `
            -password $PASS invoke `
            -mbean Security:Name=myrealmDefaultAuthenticator `
            -method advance $Cursor

    else

       print "No more names in list."
       java weblogic.Admin -adminurl $URL -username $USER `
           -password $PASS invoke `
           -mbean Security:Name=myrealmDefaultAuthenticator `
           -method close $Cursor

      return

fi

done

You can save the script in Listing 2-9 in a text file and invoke it from a Korn shell. When you invoke the script, it does the following:

Invokes the UserReaderMBean.listUsers method and assigns the returned cursor to a variable.

Because the authentication provider extends these MBeans, the script invokes the methods on the security realm's AuthenticationProvider MBean.

Constructs a loop that does the following:

Invokes the weblogic.management.utils.NameLister.haveCurrent method on the cursor variable to determine if the current cursor position refers to a name.

If the cursor refers to a name, haveCurrent prints true to standard out.

If haveCurrent prints true, invokes the weblogic.management.utils.NameLister.getCurrentName method.

The getCurrentName method prints the name to which the cursor refers.

Invokes the weblogic.management.utils.NameLister.advance method on the cursor, which causes the cursor to refer to the next name in the list.

Invokes the weblogic.management.utils.NameLister.close method on the cursor to free any server-side resources that are held on behalf of the list.

Changing a Password

To change a user's password, invoke the UserPasswordEditorMBean.changeUserPassword method, which is extended by the security realm's AuthenticationProvider MBean. See the Javadoc for the changeUserPassword method.

The method requires three input parameters:

username old-password new-password

The following example invokes changeUserPassword on the WebLogic Authentication provider:

java weblogic.Admin -adminurl localhost:8001 -username weblogic -password weblogic invoke -mbean Security:Name=myrealmDefaultAuthenticator -method changeUserPassword my-user1 mypassword my!password

If the command succeeds, it prints OK to standard out.

Protecting User Accounts in a Security Realm

Weblogic Server provides a set of attributes to protect user accounts from intruders. By default, these attributes are set for maximum protection. You can decrease the level of protection for user accounts. For example, you can increase the number of login attempts before a user account is locked, increase the time period in which invalid login attempts are made before locking the user account, or change the amount of time a user account is locked.

The AuthenticationProvider MBean does not extend methods that you use to protect user accounts. Instead, retrieve the UserLockoutManagerMBean and invoke its methods. See the Javadoc for the UserLockoutManagerMBean interface.

The following tasks provide examples for invoking UserLockoutManagerMBean methods:

Set Consecutive Invalid Login Attempts

The following commands set the number of consecutive invalid login attempts before a user account is locked out:

To determine the object name for your domain's UserLockoutManagerMBean, enter the following command:

java weblogic.Admin -adminurl localhost:8001 -username weblogic -password weblogic QUERY -pretty -pattern Security:*
If the command succeeds, it prints output similar to the following abbreviated example:
. . . --------------------------- MBeanName: "Security:Name=myrealmUserLockoutManager" InvalidLoginAttemptsTotalCount: 0 InvalidLoginUsersHighCount: 0 LockedUsersCurrentCount: 0 LockoutCacheSize: 5 LockoutDuration: 30 LockoutEnabled: true LockoutGCThreshold: 400 LockoutResetDuration: 5 LockoutThreshold: 5 . . .

To set the value of the LockoutThreshold attribute, enter the following command:

java weblogic.Admin -adminurl localhost:8001 -username weblogic -password weblogic set -mbean Security:Name=myrealmUserLockoutManager -property LockoutThreshold 3
If the command succeeds, it prints OK to standard out.

For more information about setting the value of MBean attributes, see Commands for Managing WebLogic Server MBeans.

Unlock a User Account

The following command unlocks a user account:

java weblogic.Admin -adminurl localhost:8001 -username weblogic -password weblogic invoke -mbean Security:Name=myrealmUserLockoutManager -method clearLockout my-user1

If the command succeeds, it prints OK to standard out.

Using weblogic.Admin Commands to Target Resources

In a WebLogic Server domain, many resources are defined at the domain level and then targeted to the server instances or clusters that will use the resource. For example, a JDBC connection pool is a domain-wide resource that can be targeted to many servers or clusters. Other resources, such as Web Servers and Network Channels, are defined at the level of a server instance. These resources are not targeted because they are already child resources of a server and they cannot be shared by other server instances.

Note: Instead of targeting J2EE modules (such as enterprise applications, Web applications, and EJBs) BEA recommends that you deploy them using the weblogic.Deployer utility. See "weblogic.Deployer Utility" in Deploying WebLogic Server Applications.

To target a resource to a server or cluster:

Determine the object name of the servers or clusters to which you want to target a resource:

To see the object names of all server instances in a domain, enter the following command:

java weblogic.Admin -adminurl adminListenAddress:ListenPort-usernameusername -password passwordGET -type Server
where adminListenAddress:ListenPort is the listen address and listen port of the domain's Administration Server. The output includes the object name for all ServerMBean instances, as illustrated in the bold text in the following truncated output:
MBeanName: "medrec:Name=MedRecServer,Type=Server"AcceptBacklog: 50 AdministrationPort: 0 . . . MBeanName: "medrec:Name=myMS1,Type=Server"AcceptBacklog: 50 AdministrationPort: 0 . . .

To see the object names of all clusters in a domain, enter the following command:

java weblogic.Admin -adminurl adminListenAddress:ListenPort-usernameusername -password passwordGET -type Cluster -property Name
where adminListenAddress:ListenPort is the listen address and listen port of the domain's Administration Server.

Determine the object name of the resource that you want to target by entering the following command:

java weblogic.Admin -adminurl adminListenAddress:ListenPort-usernameusername -password passwordGET -typeresource-MBean-type -property Targets
where adminListenAddress:ListenPort is the listen address and listen port of the domain's Administration Server and resource-MBean-type is the name of an MBean type described in Table 2-1.
For example, the following command returns a JDBCConnectionPool Administration MBean for all JDBC Connection Pools in the domain. The output includes the object name of the MyPool connection pool and indicates which servers or clusters have already been targeted to the resource:
java weblogic.Admin -adminurl localhost:8001 -username weblogic -password weblogic GET -type JDBCConnectionPool -property Targets
In the medrec sample domain, the command returns the following, which indicates that the MedRecPool-Oracle is not targeted to a server or cluster:
MBeanName: "medrec:Name=MedRecPool-Oracle,Type=JDBCConnectionPool" Targets: --------------------------- MBeanName: "medrec:Name=MedRecPool-PointBase,Type=JDBCConnectionPool" Targets: MedRecServer

The command that you use to target a resource to a server or cluster depends on the type of resource:

java weblogic.Admin -adminurl adminListenAddress:ListenPort-usernameusername -password passwordINVOKE -mbeanresource-object-name-method addTargetserver-or-cluster-object-name

This command appends an object name to the Targets attribute of a resource. It is valid only for resources whose Targets attribute can contain multiple values.

java weblogic.Admin -adminurl adminListenAddress:ListenPort-usernameusername -password passwordSET -mbeanresource-object-name-property Targetsserver-or-cluster-object-name

This command overwrites any existing values in the Targets attribute with the values that you specify. It is valid for any resource that includes a Targets attribute. For example: INVOKE -mbean "examples:Name=MyPool,Type=JDBCConnectionPool" -method addTarget "examples:Name=MS1,Type=Server" appends a server named MS2 to the list of targets for the MyPool JDBC connection pool. The following command replaces the current set of targets with a server named MS2: SET -mbean "examples:Name=MyPool,Type=JDBCConnectionPool" -property Targets "examples:Name=MS2,Type=Server"

java weblogic.Admin -adminurl adminListenAddress:ListenPort-usernameusername -password passwordSET -mbeanserver-object-name-propertyresource resource-object-name

This command is valid only for resources that are represented by an attribute within the ServerMBean.

Table 2-1 lists all resource types that can be targeted and provides a sample weblogic.Admin command to target the resource to the MS1 and a cluster named MedRecCluster.

Table 2-1 Resource MBeans

Resource Type	To Target a Server	To Target a Cluster
ClusterMBean	`SET -mbean "medrec:Name=MS1, Type=Server -property Cluster "medrec:Name=MedRecCluste r,Type=Cluster"`	not applicable
DomainLogFilterMBean	`SET -mbean "medrec:Name=MS1, Type=Server" -property DomainLogFilter "medrec:Name=MyDomainLogF ilter, Type=DomainLogFilter"`	not applicable
ForeignJMSServerMBean	`INVOKE -mbean "medrec:Name=MyForeign JMSServer,Type=ForeignJMS Server" -method addTarget "medrec:Name=MS1,Type=Ser ver"`	`INVOKE -mbean "medrec:Name=MyForeign JMSServer,Type=ForeignJMS Server" -method addTarget "medrec:Name=MedRecCluste r,Type=Cluster"`
JDBCConnectionPoolMBean	`INVOKE -mbean "medrec:Name=MedRecPool, Type=JDBCConnectionPool" -method addTarget "medrec:Name=MS1, Type=Server"`	`INVOKE -mbean "medrec:Name=MedRecPool, Type=JDBCConnectionPool" -method addTarget "medrec:Name=MedRecCluste r,Type=Cluster"`
JDBCDataSourceMBean	`INVOKE -mbean "medrec:Name=MyDataSource ,Type=JDBCDataSource -method addTarget "medrec:Name=MS1 ,Type=Server"`	`INVOKE -mbean "medrec:Name=MyDataSource ,Type=JDBCDataSource -method addTarget "medrec:Name=MedRecCluste r,Type=Cluster"`
JDBCMultiPoolMBean	`INVOKE -mbean "medrec:Name=MyMultiPool, Type=JDBCMultiPool" -method addTarget "medrec:Name=MS1, Type=Server"`	`INVOKE -mbean "medrec:Name=MyMultiPool, Type=JDBCMultiPool" -method addTarget "medrec:Name=MedRecCluste r,Type=Cluster"`
JDBCTxDataSourceMBean	`INVOKE -mbean "medrec:Name=MedRecTxData Source,Type=JDBCTxDataSou rce -method addTarget "medrec:Name=MS1 ,Type=Server"`	`INVOKE -mbean "medrec:Name=MedRecTxData Source,Type=JDBCTxDataSou rce -method addTarget "medrec:Name=MedRecCluste r,Type=Cluster"`
JMSConnectionFactoryMBean	`INVOKE -mbean "medrec:Name=jms/MedRecQu eueConnectionFactory,Type =JMSConnectionFactory" -method addTarget "medrec:Name=MS1,Type=Ser ver"`	`INVOKE -mbean "medrec:Name=jms/MedRecQu eueConnectionFactory,Type =JMSConnectionFactory" -method addTarget "medrec:Name=MedRecCluste r,Type=Cluster"`
JMSDistributedQueueMBean	not applicable Individual server instances can be specified in the MBean's `Members` attribute, but only clusters can be specified in the `Targets` attribute.	`INVOKE -mbean "medrec: Name=myDistributedQueue, Type=JMSDistributedQueue" -method addTarget "medrec:Name=MedRecCluste r,Type=Cluster"`
JMSDistributedTopicMBean	not applicable Individual server instances can be specified in the MBean's `Members` attribute, but only clusters can be specified in the `Targets` attribute.	`INVOKE -mbean "medrec: Name=myDistributedTopic, Type=JMSDistributedTopic" -method addTarget "medrec:Name=MedRecCluste r,Type=Cluster"`
JMSServerMBean	`SET -mbean "medrec:Name=MedRecJMSSer ver,Type=JMSServer" -property Targets "medrec:Name=MS1,Type=Ser ver"`	not applicable
MailSessionMBean	`INVOKE -mbean "medrec:Name=mail/MedRecM ailSession, Type=MailSession" -method addTarget "medrec:Name=MS1, Type=Server"`	`INVOKE -mbean "medrec:Name=mail/MedRecM ailSession, Type=MailSession" -method addTarget "medrec:Name=MedRecCluste r,Type=Cluster"`
MachineMBean and its associated NodeManagerMBean	`SET -mbean "mymedrec:Name=MS1, Type=Server" -property Machine "mymedrec:Name=WLSHost, Type=Machine"`	not applicable
MessagingBridgeMBean	`INVOKE -mbean "medrec:Name=MyMessaging Bridge,Type=MessagingBrid ge" -method addTarget "medrec:Name=MS1, Type=Server"`	`INVOKE -mbean "medrec:Name=MyMessaging Bridge,Type=MessagingBrid ge" -method addTarget "medrec:Name=MedRecCluste r,Type=Cluster"`
ShutdownClassMBean	`INVOKE -mbean "mymedrec:Name=MyShutdown Class,Type=ShutdownClass" -method addTarget "mymedrec:Name=MS1, Type=Server"`	`INVOKE -mbean "mymedrec:Name=MyShutdown Class,Type=ShutdownClass" -method addTarget "mymedrec:Name=MedRecClus ter,Type=Cluster"`
StartupClassMBean	`INVOKE -mbean "mymedrec:Name=MyStartup Class,Type=StartupClass" -method addTarget "mymedrec:Name=MS1, Type=Server"`	`INVOKE -mbean "mymedrec:Name=MyStartupClass,Type=StartupClass" -method addTarget "mymedrec:Name=MedRecClus ter,Type=Cluster"`
VirtualHostMBean	`INVOKE -mbean "medrec: Name=myVirtualHost, Type=VirtualHost" -method addTarget "medrec:Name=MS1, Type=Server"`	`INVOKE -mbean "medrec: Name=myVirtualHost, Type=VirtualHost" -method addTarget "medrec:Name=MedRecCluste r,Type=Cluster"`
WTCServerMBean	`INVOKE -mbean "medrec: Name=myWTC Server, Type=WTCServer" -method addTarget "medrec:Name=MS1, Type=Server"`	not applicable
XMLRegistry	`SET -mbean "medrec:Name=MS1, Type=Server" -property XMLRegistry "medrec:Name=MyXMLRegistr y,Type=XMLRegistry"`	not applicable

Using weblogic.Admin Commands to Configure the WebLogic SNMP Agent

WebLogic Server can use Simple Network Management Protocol (SNMP) to communicate with enterprise-wide management systems. The WebLogic Server subsystem that gathers WebLogic management data, converts it to SNMP communication modules (trap notifications), and forwards the trap notifications to third-party SNMP management systems is called the WebLogic SNMP agent. For more information about using SNMP with WebLogic Server, refer to the WebLogic SNMP Management Guide.

The commands in Listing 2-10 enable the WebLogic SNMP agent and configure it to send notifications (traps) to SNMP manager software.

Listing 2-10 Commands to Configure the WebLogic SNMP Agent

## Enable SNMPAgent and select a port
set -type SNMPAgent -property Enabled true -property SNMPPort 161

## create an SNMPTrapDestination where you want to send the traps that the agent
 generates
create -mbean medrec:Name=myManager,SNMPAgent=medrec,Type=SNMPTrapDestination

## Select a port for the trap destination
set -mbean medrec:Name=myManager,SNMPAgent=medrec,Type=SNMPTrapDestination
 -property Port 165

## Create an SNMPAttribute change trap and set the required properties
create -mbean
medrec:Name=myAttrChange,SNMPAgent=medrec,Type=SNMPAttributeChange

set -type SNMPAttributeChange -property AttributeMBeanType ServerRuntime
-property AttributeName State -property EnabledServers
medrec:Name=MedRecServer,Type=Server

## create a SNMPGaugeMonitor and set the required properties
create -mbean medrec:Name=myGauge,SNMPAgent=medrec,Type=SNMPGaugeMonitor

set -type SNMPGaugeMonitor -property MonitoredMBeanType ExecuteQueueRuntime
-property MonitoredAttributeName ExecuteThreadCurrentIdleCount 
-property EnabledServers medrec:Name=MedRecServer,Type=Server 
-property PollingInterval 20 -property ThresholdHigh 3 -property ThresholdLow 1

## create a SNMPStringMonitor and set the required properties
create -mbean medrec:Name=myString,SNMPAgent=medrec,Type=SNMPStringMonitor

set -type SNMPStringMonitor -property MonitoredMBeanType Server 
-property MonitoredAttributeName StartupMode -property EnabledServers
medrec:Name=MedRecServer,Type=Server -property NotifyMatch true 
-property StringToCompare RUNNING -property PollingInterval 20

## create a SNMPCounterMonitor and set the required properties
create -mbean medrec:Name=myCounter,SNMPAgent=medrec,Type=SNMPCounterMonitor

set -type SNMPCounterMonitor -property MonitoredAttributeName
ServicedRequestTotalCount -property MonitoredMBeanType ExecuteQueueRuntime
-property EnabledServers medrec:Name=MedRecServer,Type=Server -property Modulus
10 -property Offset 3 -property Threshold 3 -property PollingInterval 20

When invoked by the weblogic.Admin BATCHUPDATE command, the commands do the following (see BATCHUPDATE):

Enable the agent and configure it to listen for requests from other SNMP software on port 161. Because the commands do not specify a community name (password), the SNMP agent uses the default community name of public.
Create and enable a trap destination, which provides information for connecting to SNMP manager software. When the SNMP agent sends a message to this trap destination, it uses port 165 and the default community name of public.
Create and configure an Attribute Change trap, a String Monitor trap, a Gauge Monitor trap, and a Counter Monitor trap. See "WebLogic Trap Notifications" in the WebLogic SNMP Management Guide.

Using the Sample Commands

To configure the WebLogic SNMP Agent, do the following:

Start the MedRec domain and Administration Server by running the following script:
WL_HOME\samples\domains\medrec\startMedRecServer (Windows)
WL_HOME/samples/domains/medrec/startMedRecServer.sh (UNIX)

Where WL_HOME is the directory in which you installed WebLogic Server.

In a command shell, enter the following command:
WL_HOME\server\bin\setWLSEnv.cmd (Windows)
WL_HOME/server/bin/setWLSEnv.sh (UNIX)

Copy the commands in Listing 2-10 and paste them into an empty text file. Make sure that each command is on a separate, single line. For example, "create -mbean medrec:Name=myManager,SNMPAgent=medrec,Type=SNMPTrapDestination" must be on a single line.

Save the text file.

In the command shell, enter the following command:
java weblogic.Admin -url localhost:8001 -username weblogic -password weblogic BATCHUPDATE -batchFile filename -continueonerror -batchCmdVerbose

where filename is the name of the file that you created in step 4.

Note: The above command assumes that you are running MedRecServer and the BATCHUPDATE command on the same Windows computer, and that the server is listening on port 8001. If you specified some other listen address or listen port, use the -url argument to specify your address and listen port.
The BATCHUPDATE command returns OK for each command that it successfully runs.

To verify that you successfully configured the WebLogic SNMP agent:

Restart the Administration Server.

In a command shell, enter the following command:
WL_HOME\server\bin\setWLSEnv.cmd (Windows)
WL_HOME/server/bin/setWLSEnv.sh (UNIX)

In the same command shell, enter the following command:
java snmptrapd -p 165

This command starts a daemon that listens for SNMP traps on port 165. As the WebLogic SNMP agent on the MedRecServer sends traps to the trap destination that you defined, the trap daemon prints each trap to standard out.
For more information about the snmptrapd command, refer to snmptrapd.

Using weblogic.Admin Commands to Create a Simple Cluster

The weblogic.Admin BATCHUPDATE command runs a sequence of weblogic.Admin commands that you specify in a text file. This section describes how to use BATCHUPDATE to create a simple example cluster. In this example cluster, all server instances run on the same WebLogic Server host as the Administration Server.

Before you can instantiate a cluster, your WebLogic Server license must include a cluster license. If you do not have a cluster license, contact your BEA sales representative. For more information about creating clusters, refer to "Setting Up Clusters" in the Using WebLogic Server Clusters guide.

To use BATCHUPDATE to create a simple cluster in the MedRec domain, do the following:

Start the MedRec domain and Administration Server. For example, you can open a command shell and run the following script:
WL_HOME\samples\domains\medrec\startMedRecServer (Windows)
WL_HOME/samples/domains/medrec/startMedRecServer.sh (UNIX)

Where WL_HOME is the directory in which you installed WebLogic Server.

In a command shell, enter the following command:
WL_HOME\server\bin\setWLSEnv.cmd (Windows)
WL_HOME/server/bin/setWLSEnv.sh (UNIX)

Copy the commands in Listing 2-11 and paste them into an empty text file. Make sure that each command is on a separate, single line. For example, "SET -mbean MedRec:Type=WebServer,Name=MedRecMS1,Server=MedRecMS1 -property LoggingEnabled true" must be on a single line.

Save the text file.

Edit the commands that you pasted into the text file as follows:

In the command CREATE -mbean MedRec:Type=Machine,Name=calamine, change calamine to refer either to the name or IP address of the computer that is running the Administration Server.
If the listen ports 7777 and 7778 are already in use, change the port numbers in the commands.
If the IP address 239.0.0.32 is already in use, change the address to a valid multicast address. For information about multicast addresses, refer to "Communications in a Cluster" in the Using WebLogic Server Clusters guide.

where filename is the name of the file that you created in step 4.

Note: The above command assumes that you are running the MedRec server and the BATCHUPDATE command on the same Windows computer, and that the server is listening on port 8001. If you specified some other listen address or listen port, use the -url argument to specify your address and listen port.
The BATCHUPDATE command returns OK for each command that it successfully runs.

To verify that you successfully created a cluster, view the Administration Console. In the left pane of the Administration Console, open the Cluster folder and make sure that it contains a cluster named MedRecCluster. Make sure that the cluster contains two server instances named MedRecMS1 and MedRecMS2. Also verify that the servers are targeted for the machine that the command CREATE -mbean MedRec:Type=Machine,Name=calamine (from Listing 2-11) creates.

Listing 2-11 BATCHUPDATE Commands for Creating a Cluster

#Create Server Instances
CREATE -mbean medrec:Type=Server,Name=MedRecMS1
CREATE -mbean medrec:Type=Server,Name=MedRecMS2

#Configure Servers
SET -mbean medrec:Type=Server,Name=MedRecMS1 -property ListenPort 7777
SET -mbean medrec:Type=WebServer,Name=MedRecMS1,Server=MedRecMS1 -property LoggingEnabled true
SET -mbean medrec:Type=Server,Name=MedRecMS2 -property ListenPort 7778
SET -mbean medrec:Type=WebServer,Name=MedRecMS2,Server=MedRecMS2 -property LoggingEnabled true

#Create and Configure Cluster
CREATE -mbean medrec:Type=Cluster,Name=MedRecCluster
SET -mbean medrec:Type=Cluster,Name=MedRecCluster -property MulticastAddress 239.0.0.32
SET -mbean medrec:Type=Server,Name=MedRecMS1 -property Cluster medrec:Name=MedRecCluster,Type=Cluster
SET -mbean medrec:Type=Server,Name=MedRecMS2 -property Cluster medrec:Name=MedRecCluster,Type=Cluster

#Target Resources to Cluster
#The MedRec domain provides a set of JDBC Connection Pools and Data Sources
#that must be deployed to all servers in the new cluster. 
SET -mbean medrec:Name=MedRecPool-PointBase,Type=JDBCConnectionPool -property Targets medrec:Name=MedRecCluster,Type=Cluster
SET -mbean medrec:Name=MedRecTxDataSource,Type=JDBCTxDataSource -property Targets medrec:Name=MedRecCluster,Type=Cluster

SET -mbean medrec:Name=jms/MedRecQueueConnectionFactory,Type=JMSConnectionFactory
 -property Targets medrec:Name=MedRecCluster,Type=Cluster

#Configure Machines and Node Manager
CREATE -mbean medrec:Type=Machine,Name=calamine
CREATE -mbean medrec:Type=NodeManager,Name=calamine
SET -mbean medrec:Type=Server,Name=MedRecMS1 -property Machine medrec:Name=calamine,Type=Machine
SET -mbean medrec:Type=Server,Name=MedRecMS2 -property Machine medrec:Name=calamine,Type=Machine

#Creating the Server MBeans also creates ServerStart MBeans, which configure
#the server to be started by a Node Manager. The next commands set values for
#the ServerStart MBeans.
SET -mbean medrec:Name=MedRecMS1,Server=MedRecMS1,Type=ServerStart -property Username weblogic
SET -mbean medrec:Name=MedRecMS1,Server=MedRecMS1,Type=ServerStart -property Password weblogic

SET -mbean medrec:Name=MedRecMS2,Server=MedRecMS2,Type=ServerStart -property Username weblogic
SET -mbean medrec:Type=ServerStart,Name=MedRecMS2,Server=MedRecMS2 -property Password weblogic

Deploying Applications and Starting Servers in the Simple Cluster

After you create the cluster, you can use either the Administration Server or the weblogic.Deployer utility to deploy applications to the cluster. For more information, refer to "Deployment Tools Reference" in the Deploying WebLogic Server Applications guide and "Deploying Applications and Modules" in the Administration Console Online Help.

The commands in Listing 2-11 enable the MedRecMS1 and MedRecMS2 server instances to be started by the Node Manager. For information on setting up Managed Servers to be started by a Node Manager, refer to the following sections in the Configuring and Managing WebLogic Server guide: