Administration Console Online Help
[Attributes and Console Screen Reference for Servers]
If a domain's Administration Server is running, you can use the Administration Console to add and remove servers in the domain and to configure all of the domain's properties. In addition, you can use the Administration Console to monitor the performance and overall health of a domain.
If you want to create a new domain, use the Configuration Wizard. You can also use the Configuration Wizard to modify many features of a domain's configuration without starting server instances in the domain. The Configuration Wizard can configure only a subset of a domain's features. For more information, refer to "Creating and Configuring Domains Using the Configuration Wizard."
The following sections describe how to create, configure, and monitor servers from the Administration Console:
A domain can include multiple WebLogic Server instances. A minimal domain contains only one WebLogic Server instance, which functions both as an Administration Server and as a Managed server—such a domain can be useful while developing applications, but is not recommended for use in a production environment.
A Managed Server is a WebLogic Server instance that retrieves its configuration data from the domain's Administration Server. There can be many Managed Servers in a domain, but only one Administration Server. Usually, you create and start server instances as Managed Servers to run your business applications in a production environment. In this standard scenario, the server instance that you start as the Administration Server does not run business applications. Instead, it only manages resources in the domain. To improve reliability and performance, you can install the WebLogic Server software on several computers and run the servers that you create on the various WebLogic Server hosts. For more information about Managed Servers and Administration Servers, refer to "WebLogic Server Domains."
Any server instance that you define for a domain can run as an Administration Server or a Managed Server. There is no attribute within a server's configuration that designates it as an Administration Server or Managed Server. Instead, the first server instance that you start in a domain always functions as the Administration Server. If you start additional servers in a domain, you must start them as Managed Servers. For more information, refer to Starting and Stopping Servers.
The following sections describe how to add and remove servers:
To create a Managed Server in an existing domain:
Figure 330-1 Click on the Name of the Servers Folder
Each server instance in your WebLogic environment must have a unique name, regardless of the domain or cluster in which it resides, or whether it is an Administration Server or a Managed Server. Within a domain, each server, machine, cluster, JDBC connection pool, virtual host, and any other resource type must be named uniquely and must not use the same name as the domain.
The server name is not used as part of the URL for applications that are deployed on the server. It is for your identification purposes only. The server name displays in the Administration Console, and if you use WebLogic Server command-line utilities or APIs, you use this name to identify the server.
The new server appears under the Servers node in the left pane. The Administration Console updates the domain's config.xml
file with the new server configuration data.
Cloning a server creates a new server instance with the same attributes as the original server.
The new server appears under the Servers node in the left pane. The Administration Console updates the domain's config.xml
file with the new server configuration data.
When you delete a server, WebLogic Server removes its associated configuration data from the domain's configuration file (config.xml
). To see which data will be deleted, select the server in the left pane of the Administration Console. All of the data in the right pane will be deleted. For example, any network channels that you created for the server are deleted, but applications and EJBs that are deployed on the server will not be deleted.
You cannot delete a server that is currently active; therefore, you cannot use the Administration Console to delete the Administration Server. (The Administration Console runs on the Administration Server.) For more information, see Deleting an Administration Server.
You cannot delete a server if it is running a pinned service. Before you can delete such a server, you must migrate the service to a migratable target. See "Migration for Pinned Services."
To delete the server instance that you are using as an Administration Server:
Each WebLogic Server instance provides default settings for the protocols, listen addresses, and listen ports through which it can be reached. These settings are referred to collectively as the default network channel. This default network channel provides two listen ports through which it receives requests: one for non-SSL requests and the other for SSL requests. You can disable one of these ports, but at least one must be enabled.
The following sections describe how to configure the default network channel for a server instance:
You can configure additional network channels to meet various connection requirements and improve the utilization of your system and network resources. For information on configuring additional network channels, refer to "Configuring Network Resources."
Servers can be reached through the following URL: protocol
://
listen-address
:
listen-port
The default network channel supports multiple protocols for communicating with a server instance. By default, clients can contact a server instance through the HTTP and HTTPS protocols. BEA utilities (such as the weblogic.Admin
command-line utility) can also connect to servers using the proprietary T3 and T3S protocols.
The following sections describe how to enable and configure communications protocols for a WebLogic Server instance:
The server instance for which you configure the HTTP protocol does not need to be running. If it is running, and if you change settings on the HTTP tab, you must restart it. Changes on the Protocols
To configure the HTTP protocol:
Note: These settings apply to all protocols in the server's default network configuration that support tunneling.
Also see "Setting Up WebLogic Server for HTTP Tunneling."
The server instance for which you configure the T3 protocol does not need to be running. If it is running, all modifications to the T3 protocol settings take effect immediately.
Note: These settings apply to all protocols in the server's default network configuration. See "The Default Network Channel."
Note: These settings apply to all protocols in the server's default network configuration that support tunneling.
Note: Messages sent via the default channel can contain DNS information about the hosts they originate on or are destined to. If a T3 connection is established across a firewall that has network address translation (NAT) enabled, it is possible that some information about the network configuration behind the firewall will be revealed. Using the firewall to prevent T3 connections through the firewall will prevent this problem.
The IIOP (Internet Inter-ORB Protocol) protocol makes it possible for distributed programs written in different programming languages to communicate over the Internet. For information about using RMI-IIOP in your applications, refer to the "Programming WebLogic RMI over IIOP" guide.
The server instance for which you enable and configure the IIOP protocol does not need to be running. If it is running, you must restart it after you complete these steps.
To enable and configure the IIOP protocol:
Note: These settings apply to all protocols in the server's default network configuration. See "The Default Network Channel."
WebLogic jCOM is a software bridge that allows bidirectional access between Java/J2EE objects deployed in WebLogic Server, and Microsoft ActiveX components available within Microsoft Office family of products, Visual Basic and C++ objects, and other Component Object Model /Distributed Component Object Model (COM/DCOM) environments. For more information about WebLogic jCOM, refer to the "Programming WebLogic jCOM" guide.
The server instance for which you enable and configure the jCOM protocol does not need to be running. If it is running, you must restart it after you complete these steps.
To enable and configure the jCOM protocol:
Servers can be reached through the following URL: protocol
://
listen-address
:
listen-port
By default, a server's listen address attribute is undefined, which enables you to reach the server through any of the following listen addresses:
localhost
string (valid only for requests that are issued from the computer on which the server is running) If the server instance must be accessible as localhost
(for example, if you create administrative scripts that connect to localhost
), and must also be accessible by remote processes, leave the listen address blank. Otherwise, if you want to limit the valid listen address for a server, refer to Table 330-2 for guidelines on specifying listen addresses.
Note: On multi-homed Windows NT machines, if you leave the listen address undefined or if you specify a DNS name, a server instance binds to all available IP addresses.
Table 330-2 Setting the Listen Address
The server instance for which you configure the listen address does not need to be running. If it is running, you must restart it after you complete these steps.
To configure the listen address from the Administration Console:
Figure 330-3 Click on a Server
Servers can be reached through the following URL: protocol
://
listen-address
:
listen-port
Each WebLogic Server instance defines two listen ports in its default network channel: one for regular, non-secure requests (via such protocols as HTTP and T3) and the other for secure requests (via such protocols as HTTPS and T3S).
Note: By default, a server instance uses demonstration certificates to authenticate requests from the secure port. In a production environment, you must configure SSL to use certificates from a certificate authority. See "Configuring the SSL Protocol" in the Managing WebLogic Security guide.
You can disable either the default non-SSL or the default SSL listen port, but at least one must be enabled, even if you create one or more network channels for the server.
Although you can specify any valid port number, if you specify port 80
, you can omit the port number from the HTTP request used to access resources over HTTP. For example, if you define port 80
as the listen port, you can use the URL http://hostname/myfile.html
instead of http://hostname:portnumber/myfile.html
.
On some operating systems, port 80 can be accessed only by processes that run under a privileged user or group ID. In this case, you can assign the server instance to a UNIX Machine that has defined a Post-Bind UID or GID. For more information, refer to Machines.
If you run multiple instances of WebLogic Server on a single computer, each instance must use a unique listen port/listen address combination. On a multihomed computer (a computer that can be accessed through multiple IP addresses), you can use the same listen port but configure each server to use a unique IP address as its listen address. If your computer does not support multiple IP addresses, you must use a different listen port for each active instance.
The server instance for which you configure the listen ports does not need to be running. If it is running, you must restart it after you complete these steps.
To configure the listen ports from the Administration Console:
If you want to disable the SSL listen port so that the server listens only on the non-SSL listen port, remove the checkmark from the Enable SSL Listen Port box.
Note: You cannot disable both the non-SSL listen port and the SSL listen port. At least one port must be active.
You can configure custom network channels to meet varying connection requirements and improve utilization of your systems and network resources. See "Configuring Network Resources."
Note: If this server belongs to a cluster, refer to "Configuring Network Channels with a Cluster."
The server instance for which you configure a custom network channel does not need to be running. If it is running, you must restart it after you complete these steps.
To configure a custom network channel from the Administration Console:
In a production environment, the security requirements are typically much stricter than in a development environment. The network environment is typically more complex, and the need for monitoring and availability is greater.
The following steps outline a logical order for transitioning a server that you originally configured for a development environment to a production environment:
On a Windows or Linux platform, BEA recommends using the JVM that the WebLogic JRockit SDK provides. This JVM provides optimal running performance but initial startup cycles can require more time than other JVMs.
Note that when you change JVMs, you most likely need to adjust the memory available to the JVM.
The runtime mode is a domain-wide setting. As each Managed Server starts, it refers to the mode of the Administration Server to determine its runtime mode. By default, all servers run in development mode. If you configure the domain to run in production mode, the Administration Server saves this setting to the domain's config.xml
file.
BEA recommends that you set the mode when you first create a domain instead of changing the mode for an existing domain. See Production and Development Modes.
To change the mode in which all servers in a domain run:
The following sections describe miscellaneous configuration tasks:
The server instance for which you configure Managed Server Independence (MSI) replication does not need to be running. If it is running, you must restart it after you complete these steps.
To configure a Managed Server to replicate a domain's configuration files:
When a Managed Server starts, it tries to contact the Administration Server to retrieve its configuration information. If a Managed Server cannot connect to the Administration Server during startup, it can retrieve its configuration by reading configuration and security files directly. A Managed Server that starts in this way is running in Managed Server Independence (MSI) mode. For more information about MSI mode, refer to "Managed Server Independence Mode."
By default, MSI mode is enabled.
The server instance for which you want to disable MSI does not need to be running. If it is running, you must restart it after you complete these steps.
The following tasks monitor the performance and health state of servers:
For more information about monitoring WebLogic Server, refer to "Monitoring a WebLogic Server Domain."
The WebLogic Server Administration Console provides visibility into a broad array of configuration and status information of a server instance.
The server instance that you want to monitor must be running. WebLogic Server does not archive performance statistics.
To monitor a server instance from the Administration Console:
To determine the platform on which a server instance is running:
If you run a server with the JRockit Virtual Machine (VM), you can view runtime data about the underlying JRockit VM and the memory and processors on the computer that is hosting the VM.
To view additional data about the VM, such as how long it spends in a specific method, use the JRockit Management Console. Note that if you want to use the JRockit Management Console, you must include the -XManagement
startup option when you start the server. (You do not need this option to use the WebLogic Server Administration Console to monitor the VM.) For more information, refer to "JRockit Documentation Home Page."
A server can also monitor key aspects of its subsystems and report when a subsystem is not functioning properly. If the server is running under a Node Manager, the Node Manager can automatically restart a server with an unhealthy subsystem.
The server instance for which you want to self-health monitoring does not need to be running. If it is running, you must use the Node Manager to restart it after you complete these steps.
Follow these steps to configure Node Manager features for monitoring, shutting down, and restarting a Managed Server: