Starting and Stopping Servers

Starting Servers: Before You Begin

Before starting a server instance, you must perform the prerequisite steps to set up the server environment.

Depending on the method you choose to manage server startup and what setup tasks you have already performed, you might need to complete the following procedures before you can start server instances:

Meet version requirements — Version Requirements for a Domain.
Create a domain — Choosing the Appropriate Technology for Your Administrative Tasks in Understanding Oracle WebLogic Server.
Provide user credentials — Provide User Credentials to Start and Stop Servers.
Set up Node Manager — Node Manager Overview in the Administering Node Manager for Oracle WebLogic Server.
Configure Managed Server connections to the Administration Server — Configuring Managed Server Connections to the Administration Server.
Specify Java startup options — Specifying Java Options for a WebLogic Server Instance.

Version Requirements for a Domain

All WebLogic Server instances within the same administrative domain must be at the same major and minor version. You cannot mix server versions within a domain.

Server instances within a domain can be at different patch set levels as long as the Administration Server is at the same patch set level or higher than its Managed Servers. For example, if the Managed Servers are at version 10.3.0, then the Administration Server can be either version 10.3.0, 10.3.1, or higher. However, if the Managed Servers are at 10.3.1, then the Administration Server must be at 10.3.1 or higher. Also, all server instances within a cluster must be at the same patch set level.

Starting an Administration Server with a Startup Script

Use the startWebLogic script to start an Administration Server. It sets the environment variables and starts a Java Virtual Machine (JVM) to run a WebLogic Server instance.

An Administration Server is a WebLogic Server instance that maintains configuration data for a domain. In a development environment, it is usually sufficient to start an Administration Server and deploy your applications directly onto the Administration Server. In a production environment, you create Managed Servers to run applications. See Understanding WebLogic Server Domains in Understanding Domain Configuration for Oracle WebLogic Server.

You can start an Administration Server with a default startup script or create your own. To start an Administration Server with the WebLogic Server-included startup script:

If you have not already done so, use the Configuration Wizard or WebLogic Scripting Tool (WLST) to create a domain.

See Creating a WebLogic Domain in Creating WebLogic Domains Using the Configuration Wizard or Creating Domains Using WLST Offline in Understanding the WebLogic Scripting Tool.
Open a shell (command prompt) on the computer on which you created the domain.
Change to the directory in which you located the domain.

By default, this directory is ORACLE_HOME\user_projects\domains\DOMAIN_NAME, where DOMAIN_NAME is the root directory of the domain. (The name of this directory is the name of the domain.)
Run one of the following scripts:
- bin/startWebLogic.cmd (Windows)
- bin\startWebLogic.sh (UNIX and Windows. On Windows, this script supports the MKS and Cygnus BASH UNIX shell emulators.)

Note:

If you use a Configuration Wizard template that is provided by WebLogic Server, your domain directory includes a start script named startWebLogic. If you use a domain template from another source, the wizard might not create a start script, or it might create a script with a different name. The template designer determines whether the wizard creates a start script and the name of the script.

The following error occurs when using startWebLogic.cmd to boot WebLogic Server:

Enter username to boot WebLogic server:weblogic
<Error> <Security> <BEA-090782> <Server is Running in Production Mode and Native Library(terminalio)
 to read the password securely from commandline is not found>
<Notice> <WebLogicServer> <BEA-000388> <JVM called WLS shutdown hook. The server will force shutdown now>
<Alert> <WebLogicServer> <BEA-000396> <Server shutdown has been requested by <WLS Kernel>>
<Notice> <WebLogicServer> <BEA-000365> <Server state changed to FORCE_SHUTTING_DOWN>
This error is caused by installing a 32-bit JDK on a 64-bit OS. To avoid this error, install a 64-bit JDK on a 64-bit OS.

The startWebLogic script does the following:

Sets environment variables by invoking DOMAIN_NAME\bin\setDomainEnv.cmd (setDomainEnv.sh on UNIX), where DOMAIN_NAME is the directory in which you located the domain; for example, ORACLE_HOME\user_projects\domains\DOMAIN_NAME, and where ORACLE_HOME is the directory you specified as Oracle Home when you installed Oracle WebLogic Server.

Note:

setDomainEnv is designed to be sourced from other scripts, such as the startWebLogic script. setDomainEnv should not be called directly from within an interactive shell. Doing so can cause unpredictable issues in the domain.
Invokes the java weblogic.Server command, which starts a JVM that is configured to run a WebLogic Server instance.

When the server successfully completes its startup process, it writes the following message to standard out (which, by default, is the command window):
<Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>

Starting an Administration Server with the java weblogic.Server Command

To start an Administration Server from the command line, use the java weblogic.Server command.

The weblogic.Server class is the main class for a WebLogic Server instance. You start a server instance by directly invoking weblogic.Server in a Java command.

Note:

Oracle recommends using java weblogic.Server primarily for initial development but not as a standard mechanism for starting production systems for the following reasons:

java weblogic.Server will not function if you select a product directory outside of the Oracle Middleware Home directory.
When executing java weblogic.Server, patches will not be recognized by the WebLogic Server run time.

See weblogic.Server Command-Line Reference and Using the weblogic.Server Command Line to Start a Server Instance in Command Reference for Oracle WebLogic Server.

Starting an Administration Server Using WLST and Node Manager

Node Manager is a utility for the remote control of WebLogic Server instances. Use the WLST nmStart command to start an Administration Server.

If you use the nmStart command with WLST connected to a Node Manager, Node Manager supports monitoring, stopping, and restarting the Administration Server.

Using WLST and Node Manager to Manage Servers in Understanding the WebLogic Scripting Tool describes how to start the Administration Server with WLST and Node Manager. How Node Manager Starts an Administration Server in Administering Node Manager for Oracle WebLogic Server describes how Node Manager accomplishes this process.

Oracle recommends running Node Manager as an operating system service so that it automatically restarts in the event of system failure or reboot, and using Node Manager to start and restart both Administration and Managed Servers.

See Running Node Manager as a Startup Service in the Administering Node Manager for Oracle WebLogic Server.

Starting an Administration Server Using WLST Without Node Manager

Use the WLST startServer command, to start the Administration Server without using Node Manager.

The WLST startServer command starts the Administration Server without using Node Manager. The server runs in a separate process from WLST; exiting WLST does not shut down the server. See Starting an Administration Server Without Node Manager in Understanding the WebLogic Scripting Tool.

Starting Managed Servers with a Startup Script

Use the startManagedWebLogic script to start Managed Servers. The script uses a Java command to set the environment variables and start a Java Virtual Machine (JVM) that runs a WebLogic Server instance.

Managed Servers host business applications, components, Web services, and their associated resources. A Managed Server is a WebLogic Server instance that runs deployed applications. It refers to the Administration Server for all of its configuration and deployment information. Usually, you use Managed Servers to run applications in a production environment.

See Understanding WebLogic Server Domains in Understanding Domain Configuration for Oracle WebLogic Server.

If you use one of the Configuration Wizard templates that WebLogic Server provides, your domain directory includes a start script named startManagedWebLogic that you can use to start Managed Servers. You can use this script to start all the Managed Servers in a cluster.

See Domain Configuration Files in Understanding Domain Configuration for Oracle WebLogic Server.

This script does not use the Node Manager to start and manage the server. Instead, it uses a Java command to invoke the weblogic.Server class, which is the main class for a WebLogic Server instance. For information about invoking weblogic.Server in a Java command, see weblogic.Server Command-Line Reference in Command Reference for Oracle WebLogic Server.

To use the WebLogic Server scripts to start Managed Servers:

Refer to Starting Servers: Before You Begin for prerequisite tasks.
If you have not already done so, create one or more Managed Servers.

See Creating WebLogic Domains Using the Configuration Wizard or Create Managed Servers in the Oracle WebLogic Server Administration Console Online Help.
If you have not already done so, start the domain's Administration Server.
In a shell (command prompt) on the computer that hosts the Managed Server, change to the directory that contains the startManagedWebLogic script:
- DOMAIN_NAME\bin\startManagedWebLogic.cmd (Windows)
- DOMAIN_NAME/bin/startManagedWebLogic.sh (UNIX)
where DOMAIN_NAME is the directory in which you located the domain. By default, this directory is ORACLE_HOME\user_projects\domains\DOMAIN_NAME.
Enter one of the following commands:
- startManagedWebLogic.cmd managed_server_name admin_url (Windows)
- startManagedWebLogic.sh managed_server_name admin_url (UNIX)
where managed_server_name specifies the name of the Managed Server and admin_url specifies the listen address (host name, IP address, or DNS name) and port number of the domain's Administration Server.

For example, the following command uses startManagedWebLogic.cmd to start a Managed Server named myManagedServer. The listen address for the domain's Administration Server is AdminHost:7001:
```
c:\Oracle\Middleware\user_projects\domains\mydomain\bin\startManagedWebLogic.cmd myManagedServer http://AdminHost:7001
```
For each Managed Server that you want to start, open a separate command shell and follow steps 4 and 5. If you are starting Managed Servers on another machine, log in to that machine (remotely or locally) and then follow steps 4 and 5.

For information on running Managed Servers on a remote WebLogic Server host, see Creating and Starting a Managed Server on a Remote Machine in Creating Templates and Domains Using the Pack and Unpack Commands.

See Configuring Managed Server Connections to the Administration Server.

The startManagedWebLogic script does the following:

Calls the startWebLogic script, which sets the environment variables by invoking ORACLE_HOME\user_projects\domains\DOMAIN_NAME\bin\setDomainEnv.cmd (setDomainEnv.sh on UNIX), where ORACLE_HOME is the directory you specified as Oracle Home when you installed Oracle WebLogic Server.

Note:

setDomainEnv is designed to be sourced from other scripts, such as the startWebLogic script. setDomainEnv should not be called directly from within an interactive shell. Doing so can cause unpredictable issues in the domain.
Invokes the java weblogic.Server command, which starts a JVM that is configured to run a WebLogic Server instance.

When the server successfully completes its startup process, it writes the following message to standard out (which, by default, is the command window):
<Notice> <WebLogicServer> <000360> <Server started in RUNNING mode>

Starting Managed Servers from the Administration Console

Use the WebLogic Server Administration Console to start an Administration Server and its Managed Servers.

See Start Managed Servers from the Administration Console in the Oracle WebLogic Server Administration Console Online Help.

Starting Managed Servers and Clusters with WLST and Node Manager

Use WLST to start Managed Servers in a WebLogic cluster.

To start Managed Servers and clusters using WLST and Node Manager, see Using Node Manager to Start Managed Servers in a Domain or Cluster in Understanding the WebLogic Scripting Tool. See Setting up WebLogic Clusters in Administering Clusters for Oracle WebLogic Server.

Starting Managed Servers with the java weblogic.Server Command

Use the java weblogic.Server command to start Managed Servers.

The weblogic.Server class is the main class for a WebLogic Server instance. You start a server instance by directly invoking weblogic.Server in a Java command. See weblogic.Server Command-Line Reference and Using the weblogic.Server Command Line to Start a Server Instance in Command Reference for Oracle WebLogic Server.

Starting a Managed Server When the Administration Server Is Unavailable

You can start a Managed Server in Managed Server Independence (MSI) mode if it is unable to connect to the Administration Server during startup.

A Managed Server contacts the Administration Server during its startup sequence to retrieve its configuration information. If a Managed Server cannot connect to the Administration Server during startup, it can retrieve its configuration by reading its locally cached configuration data from the config directory.

Note:

The first time you start a Managed Server instance, it must be able to contact the Administration Server. Thereafter, the Managed Server instance can start even if the Administration Server is unavailable.

See Starting a Managed Server When the Administration Server Is Not Accessible.

Provide User Credentials to Start and Stop Servers

To start and stop WebLogic Server instances, you must provide the credentials of a user who is permitted to start and stop servers for the domain.

See Users, Groups, and Security Roles in Securing Resources Using Roles and Policies for Oracle WebLogic Server.

Table 2-1 describes providing user credentials when starting a WebLogic Server instance.

Table 2-1 Providing User Credentials

If you specify this...	The server instance does this...
User Name and password on the command line.	Uses them and does not prompt you for either credential.
User Name and password in `boot.properties`.	Uses them and does not prompt you for either credential.
Neither user name nor password on the command line.	Prompts you for the user name. Prompts you for the password twice.
User Name but no password on the command line.	Uses the user name from the command line. Prompts you for the password twice.
Password but no user name on the command line.	Prompts you for the user name. Ignores the password from the command line and prompts you for the password twice.

Note:

Do not use username/password as command line arguments in the startWeblogic script. Instead, you can provide username/password as JVM options:

-Dweblogic.management.username
-Dweblogic.management.password

These sections describe the following tasks:

Specifying an Initial Administrative User for a Domain

When you create a domain, the Configuration Wizard prompts you to provide the user name and password for an initial administrative user. The Configuration Wizard does the following with this information:

Assigns the user to the Administrators security group.

The Administrators group grants the highest level of privileges for starting and managing WebLogic Server. See Users, Groups, And Security Roles in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
Adds the user to the myrealm security realm.

A security realm is a collection of components (providers) that authenticate user names, determine the type of resources that the user can access, and provide other security-related services for WebLogic resources. WebLogic Server installs the myrealm security realm and uses it by default.

You can use the Administration Console to add users to security realms. If you use an Authentication provider other than the one that WebLogic Server installs, you must use the provider's administration tools to create at least one user with administrative privileges.
If you are creating a domain in development mode, the wizard creates a boot identity file in the security directory of the Administration Server's root directory. The boot identity file contains an encrypted version of the user name and password which lets you bypass the login prompt during subsequent instantiations of the server. See Boot Identity Files.

In production domains, you are prompted to enter user credentials on the command line when booting the server.

Boot Identity Files

A boot identity file is a text file that contains user credentials for starting and stopping an instance of WebLogic Server. An Administration Server can refer to this file for user credentials instead of prompting you to provide them. Because the credentials are encrypted, using a boot identity file is much more secure than storing unencrypted credentials in a startup or shutdown script. If there is no boot identity file when starting a server, the server instance prompts you to enter a user name and password.

If you start a Managed Server from a script that invokes the java weblogic.Server command (or if you invoke the java weblogic.Server command directly), a Managed Server can also refer to a boot identity file. If the Managed Server and Administration Server use the same root directory, the Managed Server can refer to the Administration Server's boot.properties file. If a Managed Server's security directory contains a valid boot.properties file, it uses this file during its startup process by default. The boot.properties file can be different for each server instance in the domain.

If you use the Node Manager to start a Managed Server, the Node Manager encrypts and saves the credentials with which it started the server in a server-specific boot.properties file for use in automatic restarts. This file is located in DOMAIN_NAME/servers/SERVER_NAME/data/nodemanager, where DOMAIN_NAME is the name of the directory in which you located the domain and SERVER_NAME is the name of the server. See Node Manager Configuration and Log Files in the Administering Node Manager for Oracle WebLogic Server.

The following sections describe working with boot identity files:

Creating a Boot Identity File for an Administration Server

If you use the Configuration Wizard to create a domain in development mode, the Configuration Wizard creates an encrypted boot identity file in the security directory of the Administration Server's root directory. See Domain Directory Contents in Understanding Domain Configuration for Oracle WebLogic Server.

If a boot identity file for an Administration Server does not already exist, and if you want to bypass the prompt for user name and password, create one as follows.

Start the Administration Server at least once and provide the user credentials on the command line.

During the Administration Server's initial startup process, it generates security files that must be in place before a server can use a boot identity file.
Place the following two lines in a text file:
```
username=username
password=password
```
The user name and password values must match an existing user account in the Authentication provider for the default security realm and must belong to a role that has permission to start and stop a server. See Users, Groups, And Security Roles in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
Save the file.

If you save the file as boot.properties and locate it in the security directory of the server's root directory, the server automatically uses this file during its subsequent startup cycles. See How a Server Uses a Boot Identity File at Startup.

The first time you use this file to start a server, the server reads the file and then overwrites it with an encrypted version of the user name and password.

Using java weblogic.Server to Create a Boot Identity File for an Administration Server

Note:

Use this technique only if you invoke the java weblogic.Server command from the command line. If you use a script to start an Administration Server, Oracle recommends that you do not use the technique described in this section for the following reasons:

It requires you to store an unencrypted password in the startup script.
Each time you run the script, the server boots with the supplied user credentials and then creates a new boot identity file.

Instead of following the steps in the previous section, Creating a Boot Identity File for an Administration Server, you can create a boot identity file by invoking the weblogic.Server class directly on the command line and including the following options in the Java command:

-Dweblogic.management.username=username
-Dweblogic.management.password=password
-Dweblogic.system.StoreBootIdentity=true

These options cause the server instance to boot with the supplied user credentials and then store them in a file named boot.properties.

For example, the following command starts an Administration Server named myAdminServer and creates a boot identity file:

java -Dweblogic.management.username=weblogic
-Dweblogic.management.password=password
-Dweblogic.system.StoreBootIdentity=true
-Dweblogic.Name=myAdminServer weblogic.Server

For more information about invoking the weblogic.Server class directly from a command line, see weblogic.Server Command-Line Reference in Command Reference for Oracle WebLogic Server.

Creating Boot Identity Files for Managed Servers

If a Managed Server uses the same root directory as the Administration Server, it can use the same boot properties file as the Administration Server. If you use a Node Manager to start a Managed Server, you do not need to create a boot identity file. See Node Manager Configuration and Log Files in Administering Node Manager for Oracle WebLogic Server.

To create a boot identity file for a Managed Server instance:

Start the domain's Administration Server to make sure that the required security files are in the security directory of the Administration Server's domain and root directories. If the files are not present, the Administration Server generates them.

See Domain Configuration Files in Understanding Domain Configuration for Oracle WebLogic Server.
Place the following two lines in a text file:
```
username=username 
password=password
```
The user name and password values must match an existing user account in the Authentication provider for the default security realm and must belong to a role that has permission to start a server. See Users, Groups, And Security Roles in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
Save the file.

If you save the file as boot.properties and locate it in the security directory of the server's root directory, the server automatically uses this file during its subsequent startup cycles. See How a Server Uses a Boot Identity File at Startup.
Repeat steps 2 and 3 for each Managed Server in the domain for which you want to create a boot identity file.

The first time you use this file to start a server, the server reads the file and then overwrites it with an encrypted version of the user name and password.

How a Server Uses a Boot Identity File at Startup

A server instance uses a boot identity file during its startup process as follows:

If a server's security directory contains a valid boot.properties file, it uses this file during its startup process by default. See A Server's Root Directory in Understanding Domain Configuration for Oracle WebLogic Server.
If you want to specify a different file (or if you do not want to store boot identity files in a server's security directory), you can include the following argument in the server's weblogic.Server startup command:
```
-Dweblogic.system.BootIdentityFile=filename 
```
where filename is the fully qualified pathname of a valid boot identity file.

To specify this argument in the startWebLogic script, add -Dweblogic.system.BootIdentityFile as a value of the JAVA_OPTIONS variable. For example:
```
set JAVA_OPTIONS=-Dweblogic.system.BootIdentityFile=C:\Oracle\user_domains\mydomain\myidentity.prop 
```
If you do not want a server instance to use a boot identity file during its startup cycle, include the following options in the server's weblogic.Server startup command:
```
-Dweblogic.management.username=username
-Dweblogic.management.password=password
```
These options cause a server instance to ignore any boot identity files and override other startup options that cause a server to use boot identity files during it startup cycle.

Note:

If you use a script to start a server instance, Oracle recommends that you do not use this technique because it requires you to store an unencrypted password in the startup script. Use this technique only if you invoke the weblogic.Server class directly from the command line. See weblogic.Server Command-Line Reference in Command Reference for Oracle WebLogic Server.
If a server is unable to access its boot identity file during its startup cycle, it displays the user name and password prompt in its command shell and writes a message to the log file.

For a given server instance, use only the boot identity file that the instance has created. WebLogic Server does not support copying a boot identity file from one server root directory to another.

For example, if you use ServerA to generate a boot identity file, use only that boot identity file with ServerA. Do not copy ServerA's boot identity file into the security directory of ServerB. Instead, create a boot identity file for ServerB as described in Creating a Boot Identity File for an Administration Server or Creating Boot Identity Files for Managed Servers.

Removing Boot Identity Files After Startup

If you want to remove the boot identity file after a server starts, you can include the following argument in the server's weblogic.Server startup command:

-Dweblogic.system.RemoveBootIdentity=true

This argument removes only the file that the server used to start. For example, if you specify -Dweblogic.system.BootIdentityFile=c:\secure\boot.MyServer, only boot.MyServer is removed, even if the server's root directory contains a file named boot.properties. Open a separate command shell and include the -Dweblogic.system.RemoveBootIdentity=true argument in each Managed Server's weblogic.Server startup command to remove its boot identity file.

To specify this argument in the startWebLogic script, add -Dweblogic.system.RemoveBootIdentity=true as a value of the JAVA_OPTIONS variable. For example:

set JAVA_OPTIONS=-Dweblogic.system.RemoveBootIdentity=true

Limitation Regarding User weblogic

If you install the WebLogic Server Examples component, the default user weblogic is created that has permission to start and stop WebLogic Server. When you set the password of the weblogic user, WebLogic Server does not automatically update this password in the boot.properties file, which is located in the DOMAIN_NAME/servers/AdminServer/security directory.

If you change the password for user weblogic, you can use either of the following workarounds so that you can continue to boot a WebLogic Server instance using that user name and its new password:

Remove the boot.properties file. Subsequently each time you start WebLogic Server, you are prompted for the user name and password. The changed password for the weblogic user will be accepted.
Modify the existing boot.properties file, changing the user name and password as follows:
```
username=weblogic
password=password
```
Subsequently during the server startup process, the boot.properties file is encrypted again.

Note:

Do not install the WebLogic Server Examples on a production machine. Keeping the samples software and other development tools off the production machine reduces the leverage intruders potentially have if they were to get partial access to a WebLogic Server production machine.

Specifying User Credentials for Starting a Server with Node Manager

If you use the Node Manager to start a Managed Server, you must provide user credentials on the server's Configuration > Server Start page of the WebLogic Server Administration Console. If you do not provide these credentials, the Node Manager throws an exception when it tries to start the server.

When you use the WebLogic Server Administration Console or the Configuration Wizard to create a Managed Server, WebLogic Server adds the user credentials to the server's Configuration > Server Start page. If you want the server instance to run under a different WebLogic Server user account, see Configure startup arguments for Managed Servers in the Oracle WebLogic Server Administration Console Online Help.

Changing the Credentials Used for Starting a Server

To change the user credentials that you provided to permit a user to start and stop WebLogic Server instances for the domain:

If using the WebLogic Authentication provider (also called DefaultAuthenticator), then change the user password using the Administration Console or WLST.

If you are not using the WebLogic Authentication provider, then use the appropriate tool for the external authentication store to change the user password.
If using the boot.properties files, then edit the file to set the new password, as described in Boot Identity Files.
If using Node Manager to start server instances, and the user name and password are set in the server start element (ServerStartMBean), then update the server start password using the Administration Console or WLST.

If using Node Manager to start server instances, and the user name and password are not set in the server start element, then restart the Administration Server before attempting to start Managed Servers.

Other Startup Tasks

Consider the miscellaneous WebLogic Server startup tasks.

Making Java Classfiles Globally Available

Use the $DOMAIN_DIR/lib environment variable or the -Dweblogic.ext.dirs start-up option to make Java class files globally available to all servers in the domain.

There are two methods for making java classes globally available to WebLogic Server:

Setting the $DOMAIN_DIR/lib environment variable.
Specifying the -Dweblogic.ext.dirs startup option.

You can specify either or both of these methods. When specifying both, classes defined using the startup option take precedence.

In both cases, you must ensure that your classes are packaged into .jar files.

Configuring Managed Server Connections to the Administration Server

To configure Managed Server connections, use the protocol://]Admin-host:port format to specify the listen address of the Administration Server.

If you will be starting a Managed Server from a script that invokes the java weblogic.Server command, or if you invoke the java weblogic.Server command directly, you must make sure that the Managed Server specifies the correct listen address of the Administration Server. A Managed Server uses this address to retrieve its configuration from the Administration Server.

Use the following format to specify the listen address:

protocol://]Admin-host:port

For protocol, specify any of the following:
- t3
- t3s
- http
- https
  
  If you will be using the domain-wide administration port, you must specify either T3S or HTTPS. If you do not specify a value, the servers use T3.
  
  Note:
  
  Regardless of which protocol you use, the initial download of a Managed Server's configuration is over HTTP or HTTPS. After the RMI subsystem initializes, the server instance can use the T3 or T3S protocol.
For Admin-host, specify any of the following:
- localhost
  
  Valid only if you are starting the Managed Server on the same computer as the Administration Server.
- The DNS name of the computer that is hosting the Administration Server.
  
  Configuring a DNS name for the Administration Server that maps to multiple IP addresses is particularly useful for Managed Servers to trying to reconnect after an Administration Server is restarted on a different IP address. See Managed Servers and the Re-started Administration Server.
  
  If you are using the demo certificates in a multi-server domain, Managed Server instances will fail to boot if you specify the fully-qualified DNS name. For information about this limitation and suggested workarounds, see Limitation on CertGen Usage in Administering Security for Oracle WebLogic Server.
- The IP address of the computer that is hosting the Administration Server.
  
  Because of the following security issue, Oracle recommends that you do not use IP addresses for Admin-host in a production environment:
  
  To connect to the Administration Server through an SSL port, the Managed Server verifies that the Administration Server's host name matches the host name that is specified in the URL. If you specify an IP address, and if host name verification is enabled, the connection fails because the IP address, which is a series of numbers, does not match the name of the host, which is a string of characters.
  
  In a development environment, where security is less of a concern, you can disable host name verification on the Managed Server so SSL connections that specify an IP address will succeed. See Using Host Name Verification in Administering Security for Oracle WebLogic Server.
  
  If the Administration Server has been configured to use some other listen address, you must specify the configured listen address.
For port, specify any of the following:
- The domain-wide administration port.
  
  When configured, the administration port is used by each Managed Server in the domain exclusively for communication with the domain's Administration Server. See Configure the domain-wide administration port in the Oracle WebLogic Server Administration Console Online Help.
  
  If you have enabled the domain-wide administration port, you must specify this port. You must specify either the T3S or HTTPS protocol to use this port.
- The non-SSL listen port for the Administration Server's default network configuration (7001 by default).
  
  If this listen port has been disabled for the Administration Server, you must use one of the other listen ports described in this list. You must specify either the T3 or HTTP protocol to use this port.
- The SSL listen port for the Administration Server's default network configuration (7002 by default).
  
  If this listen port has been disabled for the Administration Server, you must use one of the other listen ports described in this list. You must specify either the T3S or HTTPS protocol to use this port.
- The port number that is associated with an optional, custom network channel.
  
  If the port is secured with SSL, you must specify either the T3S or HTTPS protocol.

To verify the host IP address, name, and default listen port of the Administration Server, start the Administration Server in a shell (command prompt). When the server successfully finishes its startup cycle, it prints to standard out messages that are similar to the following (among other messages):

<Nov 5, 2004 12:16:04 PM EST> <Notice> <Server> <BEA-002613> <Channel "DefaultSecure[2]" is now
listening on 127.0.0.1:7012 for protocols iiops, t3s, ldaps, https.>
...
<Nov 5, 2004 12:16:04 PM EST> <Notice> <WebLogicServer> <BEA-000331> <Started WebLogic Admin Server
"MedRecServer" for domain "medrec" running in Development Mode>

For information on enabling SSL, see Set up SSL in the Oracle WebLogic Server Administration Console Online Help. See Understanding Network Channels in Administering Server Environments for Oracle WebLogic Server.

Specifying Java Options for a WebLogic Server Instance

Use Java options to configure operating parameters for the JVM that runs a WebLogic Server instance and to override a server configuration temporarily.

The Java options apply only to the current instance of the server. They are not saved in the domain's config.xml file and they are not visible from the WebLogic Server Administration Console. For example, if a server is configured to listen on port 7201, you can use a Java option to start the server so that it listens on port 7555. The WebLogic Server Administration Console will still indicate that the server is configured to listen on port 7201. If you do not use the Java option the next time you start the server, it will listen on port 7201.

If you use a WebLogic Server script to start servers, do the following. If you use the Node Manager to start servers, see Set Java options for servers started by Node Manager in the Oracle WebLogic Server Administration Console Online Help.

Create a backup copy of the WebLogic Server start scripts:
- For scripts that start an Administration Server, back up DOMAIN_NAME\bin\startWebLogic.cmd (startWebLogic.sh on UNIX)
- For scripts that start a Managed Server, back up DOMAIN_NAME\bin\startManagedWebLogic.cmd (startManagedWebLogic.sh on UNIX)
  
  where DOMAIN_NAME is the name of the directory in which you located the domain. By default, this directory is ORACLE_HOME\user_projects\domains\DOMAIN_NAME.
Open the start script in a text editor.
Edit the set JAVA_OPTIONS command to specify the Java options. If you specify multiple options, separate each option by a space, and place quotes around the entire set of options. For example:
```
set JAVA_OPTIONS="-Xgc:gencopy -Xns:30" 
```
See:
- weblogic.Server Command-Line Reference for information on the Java options that set run-time behavior of a WebLogic Server instance.
- Using Start Scripts in Administering Node Manager for Oracle WebLogic Server for detailed information on how JAVA_OPTIONS are combined and how duplicate values are handled.
- The documentation that the JVM vendor provides for information on the Java options that other JVMs support.
Save the start script.
Start the server.

Changing the JVM That Runs Servers

To use a different JDK in WebLogic Server, modify the values for the JAVA_HOME and JAVA_VENDOR variables in the Configuration Wizard.

When you create a domain, the Configuration Wizard lists the JDK used when you installed WebLogic Server. The default JDK is Oracle HotSpot, but you may have installed and used another JDK during installation.

After you create a domain, if you want to use a different JVM, you can modify the scripts as follows:

Change the value for the JAVA_HOME variable.

Specify an absolute pathname to the top directory of the JDK that you want to use.

On a Windows or Linux platform, Oracle recommends Oracle HotSpot.
Change the value for the JAVA_VENDOR variable.
Specify the vendor of the JDK. Valid values depend on the platform on which you are running. See Oracle Fusion Middleware Supported System Configurations on Oracle Technology Network.

For example:
- Oracle or Sun indicates that you are using the Oracle HotSpot JDK. It is valid only on platforms that support Oracle HotSpot.
- HP and IBM indicate that you are using JDKs that Hewlett Packard or IBM have provided. These values are valid only on platforms that support HP or IBM JDKs.
Restart any servers that are currently running.

Configuring Server Level Startup and Shutdown Classes

To provide custom, system-wide services for your applications, add the Startup and Shutdown (SU/SD) Java programs to the WebLogic Server classpath and configure them to load and run when a server starts or shuts down.

You must deploy each class on one or more specific servers. By default, startup classes are loaded and run after all other server subsystems have initialized and after the server deploys modules. See Ordering Startup Class Execution and Deployment in Deploying Applications to Oracle WebLogic Server. Shutdown classes are loaded and run when you gracefully shut down a server.

WebLogic Server 9.0 introduced a new and simpler POJO-based approach for SU/SD classes. This approach requires only that SU/SD classes have a static main(String args[]) method, which the server invokes after instantiating the class. Any arguments that you configure for SU/SD classes are passed via the String args [] parameter.

The POJO-based SU/SD classes follow the same deployment and configuration steps used in earlier versions-the classes needs to be made available on the server classpath, SU/SD classes are configured using the WebLogic Server Administration Console, and ultimately stored as an entry in config.xml.

See Example 2-1, Example 2-2, and Use custom classes to configure servers in the Oracle WebLogic Server Administration Console Online Help.

Example 2-1 Startup Classes

package sab.demo.utils;
public class StartupMain {
/**
* @param args
*/
public static void main(String[] args) {
 
log(StartupMain.class.getName() + "::main");
log("Arguments::");
for(int i=0;args!=null && i<args.length;i++) {
log("  arg[" + i + "]: " + args[i]);
}
}
 
private static void log(String msg) {
System.out.printf("  --> [SAB]: %s\n", msg);
}
}

Example 2-2 config.xml

<startup-class>
<name>StartupMain</name>
<target>AdminServer</target>
<deployment-order>1000</deployment-order>
<class-name>sab.demo.utils.StartupMain</class-name>
<arguments>arg1 arg2 arg3</arguments>
<failure-is-fatal>false</failure-is-fatal>
<load-before-app-deployments>false</load-before-app-deployments>
<load-before-app-activation>true</load-before-app-activation>
</startup-class>

Customizing Domain Wide Server Parameters

To customize domain wide server parameters in WebLogic Server, configure setUserOverrides.cmd (Windows) or setUserOverrides.sh (UNIX) libraries by specifying the required Java command line options and environment variables to it.

Every domain includes dynamically generated domain and server startup scripts, such as setDomainEnv. Oracle recommends that you do not modify these startup scripts, as any changes you make to them will be overwritten during subsequent domain upgrade operations.

To enable you to customize server startup parameters that apply to the servers in a domain, there are two scripts that you can provide: setUserOverrides.cmd and setUserOverridesLate.cmd (Windows) or setUserOverrides.sh and setUserOverridesLate.sh (UNIX). The setUserOverrides script will be executed early in the setDomainEnv script, before any domain extension template properties have been set. The setUserOverridesLate script will be executed later after the domain extension template properties have been set. These scripts can be configured to, for example, add custom libraries to the WebLogic Server classpath, specify additional java command line options for running the servers, or specify additional environment variables. Any customizations you add to these files are preserved during domain upgrade operations and are carried over to remote servers when using the pack and unpack commands.

To assure your customizations effectively override all product defaults, add your customizations to the setUserOverridesLate script, otherwise your customizations may be overridden by product extensions when using setUserOverrides.

Note:

If you move customizations from setUserOverrides to setUserOverridesLate, it is recommended to re-validate your application’s functionality, as some customizations may not have taken effect previously.

During server startup, if this file exists, it is included in the startup sequence and any overrides it defines take effect. The file must be stored in the domain_home/bin directory.

Note:

Node Manager does not detect setUserOverrides. If you start Administration Server using Node Manager, setUserOverrides does not create startup Java logs and takes the default path even when you mention the arguments -Dweblogic.Stdout and -Dweblogic.Stderr in Server start tab. You must follow Configuring Remote Startup Arguments in Administering Node Manager for Oracle WebLogic Server.

The following example shows how to add custom libraries and specify additional java command line options.

Example 2-3 Example Startup Customizations in a setUserOverridesLate or setEnvUserOverrides file

echo ""
echo "*****************************************************"
echo "** Executing setUserOverridesLate.sh"
echo "*****************************************************"

# add custom libraries to the WebLogic Server system classpath
  if [ "${POST_CLASSPATH}" != "" ] ; then
    POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  else
    POST_CLASSPATH="${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  fi
 
# specify additional java command line options for all servers

EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Dcustom.property.key=custom.value"
export EXTRA_JAVA_PROPERTIES


# Specify any server-specific java command line options by server name or partial match
case "${SERVER_NAME} in
   AdminServer)
      echo "** AdminServer Customizations:"
      USER_MEM_ARGS="${USER_MEM_ARGS} -Xms#g -Xmx#g ";
      export USER_MEM_ARGS;
      ;;

   WLS_appA*)
      echo "** Application A Managed Servers Customizations:"
      USER_MEM_ARGS="${USER_MEM_ARGS} -Xms#g -Xmx#g ";
      export USER_MEM_ARGS;
      EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Dcustom.property.key=custom.value"
      export EXTRA_JAVA_PROPERTIES
      ;;
   *)
      echo "** WARNING - No server match - VERIFY case condition coding."
      ;;

esac
echo "USER_MEM_ARGS=\"${USER_MEM_ARGS}\""
echo "EXTRA_JAVA_PROPERTIES=\"${EXTRA_JAVA_PROPERTIES}\""
echo ""
echo "*****************************************************"
echo "** End of setUserOverrideLate.sh"
echo "*****************************************************"
echo ""

Shutting Down Instances of WebLogic Server

Shut down a WebLogic Server instance using a stop script in the console or an operating system command to kill the Java Virtual Machine (JVM) of the specific server instance. These procedures help to stop the server instance smoothly without any session data loss.

It is recommended that you shut down WebLogic Server instances through the WebLogic Server Administration Console. See Shut Down a Server Instance, Control Graceful Shutdowns, and Shut down server instances in a cluster in Oracle WebLogic Server Administration Console Online Help.

Shutting Down Servers with a Stop Script

If you use a Configuration Wizard template that is provided by WebLogic Server, the bin directory under your domain directory includes a stop script named stopWebLogic that you can use to stop an Administration Server and one named stopManagedWebLogic for stopping Managed Servers. To use the scripts, you must set SERVER_NAME, ADMIN_URL, USERID, and PASSWORD as environment variables or specify them on the command line. When using the stopWebLogic script, if you do not specify SERVER_NAME, the Administration Server name is used by default.

For an Administration Server, invoke:

DOMAIN_NAME\bin\stopWeblogic.cmd username password admin_url (Windows)

DOMAIN_NAME/bin/stopWeblogic.sh username password admin_url (UNIX)
For Managed Servers, invoke:

DOMAIN_NAME\bin\stopManagedWeblogic.cmd managed_server_name admin_url username password (Windows)

DOMAIN_NAME/bin/stopManagedWeblogic.sh managed_server_name admin_url username password (UNIX)

Note:

On the command line, specify parameters in the order shown. User credentials come before the ADMIN_URL with stopWebLogic.cmd and after the ADMIN_URL with stopManagedWebLogic.cmd.

Killing the JVM

Each WebLogic Server instance runs in its own JVM. If you are unable to shut down a server instance using the methods described in the previous sections, you can use an operating system command to kill the JVM.

Note:

If you kill the JVM, the server immediately stops all processing. Any session data is lost. If you kill the JVM for an Administration Server while the server is writing to the config.xml file, you can corrupt the config.xml file.

Some common ways to kill the JVM are as follows:

If the shell (command prompt) in which you start the server is still open, you can type Ctrl-C.
On a Windows computer, you can use the Task Manager to kill a JVM.
On a UNIX computer, you can use the ps command to list all running processes. Then you can use the kill command to kill the JVM.