Skip navigation.

eDocs Home > BEA WebLogic Server 8.1 Documentation > WebLogic Server Command Reference > Using Command-Line Utilities to Configure a WebLogic Server Domain

WebLogic Server Command Reference

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents Index View as PDF   Get Adobe Reader

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:

 

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:

  1. Set the required environment variables.

    2. See Setting Up the Environment.

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

    3. See Creating a Domain.

  3. 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:

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

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

    5. 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:

  1. Create an empty directory named mymedrec.
  2. Change to the empty directory and enter the following command:

    3. 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:

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):

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

    2. 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:

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

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

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

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

  4. 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:

  1. Copy the commands in Listing 2-1 and paste them into an empty text file.
  2. Open a command prompt (shell) and invoke WL_HOME\common\bin\startPointBase.sh.

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

  3. If you haven't already started the Administration Server for the mymedrec domain:
    1. Change to the mymedrec directory that you created in Creating a Domain.
    2. Invoke one of the following scripts:

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

    3. Enter the following command:

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

  4. Open another command prompt (shell) and do the following:
    1. Invoke WL_HOME\samples\domains\medrec\setMedRecEnv.cmd or setMedRecEnv.sh.
    2. Invoke the following command:

      3. 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):

  1. Create a JMS connection factory by instantiating a JMSConnectionFactoryMBean.

    2. 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:

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

    3. In the SET command:

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

    4. 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)

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

    5. 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.

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

    6. 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):

  1. Create a server instance named myMedRecServer1 by instantiating a ServerMBean.

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

  2. Configure myMedRecServer1 to listen on port 8011 by setting the ListenPort attribute of myMedRecServer1's ServerMBean.
  3. Make resources available to the myMedRecServer1 Managed Server by setting the Targets attribute of the resources' MBeans.

    4. 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):

  1. Create a machine by instantiating a MachineMBean.

    2. 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:

  2. 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.

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

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

  3. 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.

    4. 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:

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:

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

    2. 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.

  2. Save Listing 2-8 in a text file named ConfigDomain.txt and locate it in the same directory as CreateDomain.sh.
  3. Open a Korn shell and set up the environment as follows:
    1. Invoke WL_HOME\common\bin\startPointBase.sh.

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

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

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

  4. Invoke CreateDomain.sh.

    5. The CreateDomain.sh script:

  5. To deploy the MedRec sample applications:
    1. Change to the mymedrec directory that the CreateDomain.sh script created.
    2. Invoke the following command:
      java -Dweblogic.Name=myMedRecServer1
      -Dweblogic.management.server=http://localhost:8001 weblogic.Server       &
    3. 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 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:

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:

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

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

  2. Constructs a loop that does the following:
    1. Invokes the weblogic.management.utils.NameLister.haveCurrent method on the cursor variable to determine if the current cursor position refers to a name.

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

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

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

    3. Invokes the weblogic.management.utils.NameLister.advance method on the cursor, which causes the cursor to refer to the next name in the list.
  3. 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:

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

    2. 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
    .
    .
    .

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

    3. 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:

  1. Determine the object name of the servers or clusters to which you want to target a resource:
  2. Determine the object name of the resource that you want to target by entering the following command:

    3. java weblogic.Admin -adminurl adminListenAddress:ListenPort
    -username     username -password password
    GET -type     resource-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

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

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):

Using the Sample Commands

To configure the WebLogic SNMP Agent, do the following:

  1. 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)

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

  2. In a command shell, enter the following command:
    WL_HOME\server\bin\setWLSEnv.cmd (Windows)
    WL_HOME/server/bin/setWLSEnv.sh (UNIX)
  3. 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.
  4. Save the text file.
  5. In the command shell, enter the following command:
    java weblogic.Admin -url localhost:8001 -username weblogic -password weblogic BATCHUPDATE -batchFile filename -continueonerror -batchCmdVerbose

    6. 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:

  1. Restart the Administration Server.
  2. In a command shell, enter the following command:
    WL_HOME\server\bin\setWLSEnv.cmd (Windows)
    WL_HOME/server/bin/setWLSEnv.sh (UNIX)
  3. In the same command shell, enter the following command:
    java snmptrapd -p 165

    4. 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:

  1. 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)

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

  2. In a command shell, enter the following command:
    WL_HOME\server\bin\setWLSEnv.cmd (Windows)
    WL_HOME/server/bin/setWLSEnv.sh (UNIX)
  3. 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.
  4. Save the text file.
  5. Edit the commands that you pasted into the text file as follows:
  6. In the command shell, enter the following command:
    java weblogic.Admin -url localhost:8001 -username weblogic -password weblogic BATCHUPDATE -batchFile filename -continueonerror -batchCmdVerbose

    7. 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:

 

Skip navigation bar  Back to Top Previous Next