BEA Logo BEA WebLogic Server Release 6.1

  BEA Home  |  Events  |  Solutions  |  Partners  |  Products  |  Services  |  Download  |  Developer Center  |  WebSUPPORT



  WebLogic Server Doc Home   |     Administration Guide   |   Previous Topic   |   Next Topic   |   Contents   |   Index   |   View as PDF

Overview of WebLogic Server Management


The following sections describe the tools available to manage WebLogic Server:

Your implementation of BEA WebLogic Server(TM) software provides a set of interrelated resources for users. Managing these resources includes such tasks as starting and stopping servers, balancing the load on servers or connection pools, selecting and monitoring the configuration of resources, detecting and correcting problems, monitoring and evaluating system performance, and deploying Web applications, Enterprise Javabeans (EJBs) or other resources.

The main tool that WebLogic provides to accomplish these tasks is a Web-based Administration Console. The Administration Console is your window into the WebLogic Administration Service. The Administration Service — an implementation of Sun's Java Management Extension (JMX) standard — provides the facilities for managing WebLogic resources.

Through the Administration Console you can configure attributes of resources, deploy applications or components, monitor resource usage (such as server load or Java Virtual Machine memory usage or database connection pool load), view log messages, start or shut down servers, or perform other management actions.


Domains, the Administration Server and Managed Servers

An inter-related set of WebLogic Server resources managed as a unit is called a domain. A domain includes one or more WebLogic Servers, and may include WebLogic Server clusters.

The configuration for a domain is defined in Extensible Markup Language (XML). Persistent storage for the domain's configuration is provided by a single XML configuration file install_dir/config/domain_name/config.xml (where install_dir is the directory under which the WebLogic Server software has been installed). For more information on the config.xml file, see BEA WebLogic Server Configuration Reference.

A domain is a self-contained administrative unit. If an application is deployed in a domain, components of that application cannot be deployed on servers that are not a part of that domain. When a cluster is configured in a domain, all of its servers must be a part of that domain as well. A domain may contain multiple clusters.

A J2EE application is a collection of components that are grouped together into a deployment unit (such as an EAR, WAR or JAR file). The various WebLogic resources required for an application — EJBs or Web applications, servers or clusters, JDBC connection pools, and so on — are defined within a single domain configuration. Grouping these resources into a single, self-contained domain provides a unified viewpoint, and point of access, for managing these interrelated resources.

A WebLogic Server running the Administration Service is called an Administration Server. The Administration Service provides the central point of control for configuring and monitoring the entire domain. The Administration Server must be running in order to perform any management operation on that domain.

Note: The Administration Server must be running the same version of WebLogic Server as the Managed Servers in its domain. The Administration Server must also have the same or later service pack installed as the Managed Servers in its domain. For example, the Administration Server could be running version 6.1, Service Pack 2 while the Managed Servers are running version 6.1, Service Pack 1.

In a domain with multiple WebLogic Servers, only one server is the Administration Server; the other servers are called Managed Servers. Each WebLogic Managed Server obtains its configuration at startup from the Administration Server.

The same class, weblogic.Server, may be started as either the Administration Server for a domain or as a WebLogic Managed Server. A WebLogic Server not started as a Managed Server is an Administration Server.

In a typical configuration for a production system, the applications and components with your business logic would be deployed across Managed Servers and the role of the Administration Server would be that of configuring and monitoring the Managed Servers. If the Administration Server should go down, the applications deployed on the Managed Servers are not affected and continue processing client requests; in such a situation, the Administration Server can regain administrative control of the active domain once it is restarted. (For information on how this is done, see Restarting the Administration Server when Managed Servers are Running.)

Distributing an application and its components across a set of Managed Servers has a number of possible advantages. EJBs or other components that do processing can be distributed to ensure ready availability for the main application entry point. Performance may be enhanced if components that do different functions, such as database access and account transactions, are segregated to different Managed Servers. A component such as an EJB that is a resource for a variety of functions or applications can be isolated, so that its availability is independent of the state of other components. Multiple applications can be deployed within a single domain.

A domain is active if the Administration Server was started using the configuration for that domain. While a domain is active, only the Administration Server can modify the configuration file. The Administration Console and the command-line administration utilities provide windows into the Administration Server which enable you to modify the domain configuration. Once the domain is activated, you can monitor and configure the resources of the entire domain via the Administration Console.

Additional non-active domain configurations may reside in the configuration repository, and you can edit them using the Administration Console. The configuration repository consists of a series of subdirectories (at least one) under the /config directory. Each domain is defined in a distinct config.xml file residing in a separate subdirectory; the name of that subdirectory is the domain name. To access non-active domain configurations, follow the Domain Configurations link on the Administration Console Welcome page when you start the Console.


Administration Console

The Administration Console is a JSP-based application hosted by the Administration Server. You can access the Administration Console using a Web browser from any machine on the local network that can communicate with the Administration Server (including a browser running on the same machine as the Administration Server). The Administration Console allows you to manage a WebLogic Server domain containing multiple WebLogic Server instances and applications. The management capabilities include:

Using the Administration Console, system administrators can easily perform all WebLogic Server management tasks without having to learn the JMX API or the underlying management architecture. The Administration Server persists changes to attributes in the config.xml file for the domain you are managing.

For more information, see:

After starting the Administration Server (see Starting and Stopping WebLogic Servers), you can start the Administration Console by directing your browser to the following URL:


The value of hostname is the DNS name or IP address of the Administration Server and port is the address of the port on which the Administration Server is listening for requests (7001 by default). If you started the Administration Server using Secure Socket Layer (SSL), you must add s after http as follows:


If you have your browser configured to send HTTP requests to a proxy server, then you may need to configure your browser to not send Administration Server HTTP requests to the proxy. If the Administration Server is on the same machine as the browser, then ensure that requests sent to localhost or are not sent to the proxy.

The left pane in the Administration Console contains a hierarchical tree — the domain tree — for navigating to tables of data, configuration pages and monitoring pages, or accessing logs. By selecting (that is, left-clicking) an item in the domain tree, you can display a table of data for resources of a particular type (such as WebLogic Servers) or configuration and monitoring pages for a selected resource. The top-level nodes in the domain tree are containers. If leaf nodes are present in those containers, you can click on the plus sign at the left to expand the tree to access the leaf nodes.

The entity tables — tables of data about resources of a particular type — can be customized by adding or subtracting columns that display values for attributes. You can customize a table by following the Customize this table link at the top of the table. Each column in the table corresponds to an attribute that has been selected for inclusion in the table.

When started, the Administration Console prompts for a password. The first time the Administration Console is started, you can use the user name and password under which the Administration Server was started. You can use the Administration Console to add users to the Administrators group. Once users (or groups of users) have been added to the Administrators group, these users can also perform administrative tasks via the Administration Console. The default member of the Administrators group is system.

Because an Administration Server can manage only one active domain, you can access only one active domain at a time using the Administration Console. If you have separate Administration Servers running, each with its own active domain, you can switch from managing one domain to the other only by invoking the Administration Console on the Administration Server that you want to access.


Run-time and Configuration Objects

The Administration Server is populated with JavaBean-like objects called Management Beans (MBeans), which are based on Sun's Java Management Extension (JMX) standard. These objects provide management access to domain resources.

The Administration Server contains both configuration MBeans and run-time MBeans. Configuration MBeans provide both SET (write) and GET (read) access to configuration attributes.

Run-time MBeans provide a snapshot of information about domain resources, such as current HTTP sessions or the load on a JDBC connection pool. When a particular resource in the domain (such as a Web application) is instantiated, an MBean instance is created which collects information about that resource.

When you access the monitoring page for particular resources in the Administration Console, the Administration Server performs a GET operation to retrieve the current attribute values.

The Administration Service allows you to change the configuration attributes of domain resources dynamically — while the WebLogic Servers are running. For many attributes, you do not need to restart the servers for your change to take effect. In that case, a change in configuration is reflected in both the current run-time value of the attribute as well as the persistently stored value in the configuration file. (For more information about configuring WebLogic Servers, see Configuring WebLogic Servers and Clusters.)

In addition to the Web-based Administration Console, WebLogic Server provides a command-line utility for accessing configuration and monitoring attributes of domain resources. This tool is provided for those who want to create scripts to automate system management. For more information, see:


Central Point of Access to Log Messages

The Administration Server also provides central access to critical system messages from all the servers via the domain log. JMX provides a facility for forwarding messages to entities that subscribe for specified messages. Subscriber entities specify which messages to forward by providing a filter that selects messages of interest. A message forwarded to other network entities on the initiative of a local WebLogic Server is called a notification. JMX notifications are used to forward selected log messages from all WebLogic Servers in the domain to the Administration Server.

When a WebLogic Managed Server starts, the Administration Server registers to receive critical log messages. Such messages are stored in the domain log. A single domain log filter is registered with each WebLogic Server by the Administration Server to select the messages to be forwarded. You can change the domain log filter, view the domain log, and view the local server logs using the Administration Console. (For details, see Using Log Messages to Manage WebLogic Servers.)


Creating a New Domain

This section describes how to create a new domain. The configuration information for all of the WebLogic administrative domains reside in the configuration repository, which is located under the /config directory. Each domain has a separate subdirectory under the /config directory. The name of the subdirectory for a domain must be the name of that domain.

When you first install WebLogic Server software, it is recommended that you create a zip file that has a copy of the default install_dir/config/mydomain configuration directory (where install_dir is the root directory where you installed the WebLogic Server software and mydomain is the default domain configuration you specified at installation). You should keep a copy of this zip file as a backup that you can use for creating new domains. This subdirectory contains components that are required for a working configuration, such as a file and a configuration file.

In the procedure below mydomain is assumed as the default configuration directory name selected during installation. If you used a name other than mydomain for the default configuration directory, substitute that name for mydomain throughout.

To create a new domain, do the following:

  1. Start the Administration Server under an existing domain such as mydomain.

  2. Invoke the Administration Console by pointing your browser to:

    where hostname is the name of the machine where you started the Administration Server and port is the Administration Server's listen port (default is 7001).

  3. Select mydomain—>Create or edit other domains.

    This displays the domains table.

  4. Select Default—>Create a new Domain.

    Enter the name of the new domain and click Create.

  5. Select the new domain from the list of domains at left to make that the current domain.

  6. Now you will need to create an Administration Server entry for the new domain:

    1. Select Servers—>Create a new Server.

    2. Enter the name of the new Administration Server and click Create. Each server must have a unique name — even if the servers are in different domains

  7. The Administration Console will have created a new subdirectory with the name of your domain and a configuration file, config.xml, under that subdirectory. Now you need to create an \applications subdirectory in that domain directory. You can create an \applications subdirectory in a command shell or, on Windows, by using Explorer.

  8. The default mydomain directory contains start scripts for starting the WeLogic Server. For Windows installations, these are startWebLogic.cmd and startManagedWebLogic.cmd. For UNIX installations, these are and Copy these start scripts to the new domain directory.

  9. You will need to edit the start scripts in a text editor. By default, the name of the domain is set as:

    Replace mydomain with the name of the new domain.

    By default the name of the Administration Server is set as:


    Replace MyServer with the name of the new Administration Server.

  10. At the end of the start script there is a cd command:
    cd config\mydomain

    Replace mydomain with the subdirectory name of the new domain. There is also a line in the start script that reads:

    echo startWebLogic.cmd must be run from the config\mydomain 

    Replace mydomain here with the name of the new domain.

  11. Copy the file SerializedSystemIni.dat and the file from the default mydomain directory to your new domain directory. Do not try to boot the new Administration Server before copying these files.

Once you have completed this procedure, you can start the Administration Server for your new domain.


back to top previous page next page