Skip navigation.
Downloads | Product Documentation | Support

Configuring and Managing WebLogic Server

# Overview of WebLogic Server System Administration

The following sections provide an overview of system administration for WebLogic Server:

- Introduction to System Administration
- WebLogic Server Domains
- System Administration Infrastructure
- The Administration Server and Managed Servers
- System Administration Tools
- Resources You Can Manage in a WebLogic Server Domain
- Starting the Administration Console
- Using WebLogic Server with Web Servers
- Monitoring
- Licenses

# Introduction to System Administration

You manage a WebLogic Server installation by using any of several system administration tools provided with WebLogic Server. A WebLogic Server installation can consist of a single WebLogic Server instance or multiple instances, each hosted on one or more physical machines. The system administration tools include the Administration Console, command line utilities, and an API, with which you manage security, database connections, messaging, transaction processing, and the runtime configuration of your applications. The tools also allow you to monitor the health of the WebLogic Server environment to ensure maximum availability and performance for your applications.

# WebLogic Server Domains

The basic administrative unit for a WebLogic Server installation is called a domain. A domain is a logically related group of WebLogic Server resources that you manage as a unit. A domain always includes only one instance of WebLogic Server called the Administration Server. The Administration Server serves as a central point of contact for server instances and system administration tools. A domain may also include additional WebLogic Server instances called Managed Servers.

You can configure some or all of these Managed Servers to be part of a WebLogic Server cluster. A cluster is a group of WebLogic Server instances that work together to provide scalability and high-availability for applications. A Managed Server in a cluster can act as a backup for services such as JMS and JTA that are hosted on another server instance in the cluster. Your applications are also deployed and managed as part of a domain.

A Managed Server can also function as a virtual host.

You can organize your domains based on criteria such as:

- Logical divisions of applications. For example, a domain devoted to end-user functions such as shopping carts and another domain devoted to back-end accounting applications.
- Physical location. Domains for different locations or branches of your business.
- Size. Domains organized in small units that can be managed more efficiently, perhaps by different personnel.

For more information about WebLogic Server domains, see:

- Overview of WebLogic Server Domains
- Creating and Configuring Domains Using the Configuration Wizard
- Configuring Domains in the Administration Console Online Help

Figure 1-1 WebLogic Server Domain

Figure 1-1 depicts a possible configuration of a WebLogic Server Domain—one of many possible configurations.

In the depicted domain, there are three physical machines:

Machine A hosts one instance of WebLogic Server, the Administration Server. The System Administration Tools communicate with the Administration Server to perform configuration and monitoring of the servers and applications in the domain. The Administration Server communicates with each Managed Server on behalf of the System Administration Tools. The configuration for all the servers in the domain is stored in the configuration repository, the `config.xml` file, which resides on the machine hosting the Administration Server.

Machines B and C each host two instances of WebLogic Server, WebLogic Servers 1 through 4. These instances are called Managed Servers. The Administration Server communicates with an instance of Node Manager running on each machine to control startup and shutdown of the Managed Servers.

WebLogic Servers 2 and 4 are part of a WebLogic Cluster (outlined in red). This cluster is running an application that responds to HTTP requests routed to the cluster from a hardware load balancer. (An instance of WebLogic Server or a third-party Web server with one of the WebLogic Server plug-ins can also provide load balancing.) The load balancer processes HTTP requests from the Internet after they have passed through a firewall. The load balancer and firewall are not part of the domain. A replicated copy of objects such as HTTP sessions is passed between the two cluster members to provide failover capability.

WebLogic Server 1 runs an application that uses Java Database Connectivity (JDBC) to access a database server running on another physical machine that is not part of the WebLogic Domain.

Note: The pictured domain is only intended to illustrate the concepts of a WebLogic Server domain and how you manage the domain. Many possible configurations of servers, clusters, and applications are possible in a WebLogic Server domain.

# System Administration Infrastructure

System administration infrastructure in WebLogic Server is implemented using the Java Management Extension (JMX) specification from Sun Microsystems. The JMX API models system administration functions with Java objects called MBeans. Knowledge of this implementation as described in this discussion of system administration infrastructure is not necessary to manage a WebLogic Server domain.

There are three types of MBeans used to manage a WebLogic Server domain: administration, configuration, and runtime Mbeans.

Administration Mbeans contain a set of attributes that define configuration parameters for various management functions. All attributes for administration MBeans have pre-set default values. When the Administration Server starts, it reads the domain configuration file (called `config.xml)` and overrides the default attribute values of the administration MBeans with any attribute values found in the `config.xml` file.

The `config.xml` file, located on the machine that hosts the Administration Server, provides persistent storage of Mbean attribute values. Every time you change an attribute using the system administration tools, its value is stored in the appropriate administration MBean and written to the `config.xml` file. Each WebLogic Server domain has its own `config.xml` file.

Each time the Administration Server starts successfully, and each time you modify the configuration, a backup configuration file is created. You can configure the number of back up copies of `config.xml` retained by the Administration Server. For more information, see Backing up config.xml.

If you set any configuration attributes on the command line when you start the Administration Server with `-D` arguments, these values override the values set by the defaults or those read from the `config.xml` file. These overridden values are also persisted to `config.xml` file by the Administration Server. For more information about these command-line arguments, see Configuring Servers in the Administration Console Online Help.

Configuration Mbeans are copies of Administration Mbeans that each Managed Server uses to initialize its configuration. When you start a Managed Server, the server receives a copy of all the administration MBeans configured on the Administration Server and stores them in memory as configuration MBeans. If you override any configuration attributes when starting a Managed Server, those values override the values received from the Administration Server but are not written to the `config.xml` file. For more information about starting a Managed Server, see Starting Managed Servers in the Administration Console Online Help.

Runtime Mbeans contain sets of attributes consisting of runtime information for active WebLogic Servers instances and applications. By retrieving the values of attributes in these runtime MBeans, you can monitor the running status of a WebLogic Server domain.

Mbeans may also contain operations used to execute management functions.

Although users with a knowledge of these Mbeans and the JMX API can create their own customized management system, most users prefer to use the system administration tools provided with WebLogic Server to perform these tasks. These tools do not require knowledge of the JMX API. For more information, see System Administration Tools.

# The Administration Server and Managed Servers

One instance of WebLogic Server in each domain acts as an Administration Server. The Administration Server provides a central point for managing a WebLogic Server domain. All other WebLogic Server instances in a domain are called Managed Servers. In a domain with only a single WebLogic Server instance, that server functions both as Administration Server and Managed Server.

For a typical production system, BEA recommends that you deploy your applications only on Managed Servers. This practice allows you to dedicate the Administration Server to configuration and monitoring of the domain, while one or more Managed Servers service your applications.

For more information, see Starting and Stopping Servers in the Administration Console Online Help.

## Recovery of a Failed Administration Server

A running Administration Server is always required to configure and monitor a domain. By maintaining backups of the `config.xml` file and certain other resources for a domain, you can replace a failed Administration Server with a backup WebLogic Server instance that can assume the role of Administration Server. For more information, see Starting Administration Servers and Recovering Failed Servers.

## Managed Server Independence

To prevent the Administration Server from becoming a single point of failure, Managed Servers can always function without the presence a running Administration Server. When a Managed Server starts, it contacts the Administration Server to retrieve its configuration information. If a Managed Server is unable to connect to the specified Administration Server during startup, it can retrieve its configuration directly by reading a copy of the `config.xml` file and other files located on the Managed Server's own file system.

A Managed Server that starts in this way is running in Managed Server Independence mode. In this mode, a server uses cached application files to deploy the applications that are targeted to the server. You cannot change a Managed Server's configuration until it is able to restore communication with the Administration Server. For more information, see Recovering Failed Servers. Failover for Managed Servers is applicable to both clustered and non-clustered servers.

## Domain-Wide Administration Port

You can enable an administration port for use with servers in a domain. The administration port is optional, but it provides two important capabilities:

- You can start a server in standby state. While in the standby state, the administration port remains available to activate or administer the server. However, the server's other network connections are unavailable to accept client connections. See Starting and Stopping WebLogic Server in the Administration Console Online Help for more information on the standby state.
- You can separate administration traffic from application traffic in your domain. In production environments, separating the two forms of traffic ensures that critical administration operations (starting and stopping servers, changing a server's configuration, and deploying applications) do not compete with high-volume application traffic on the same network connection.

For more information, see Enabling the Domain-Wide Administration Port in Administration Console Online Help

## Service Packs and WebLogic Server Instances

All WebLogic Server instances in a domain must run the same version of the WebLogic Server software. 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 8.1, Service Pack 1 while the Managed Servers are running version 8.1 without Service Pack 1.

# System Administration Tools

Using JMS as the underlying architecture, System administration tools are provided for a variety of management functions. An Administration Server must be running when you use system administration tools to manage a domain. The following tools are discussed in the next sections:

- System Administration Console
- Command-Line Interface
- JMX
- Configuration Wizard
- Configuration Template Builder
- Java Utilities
- Ant Tasks
- Node Manager
- SNMP
- Logs
- Editing config.xml

## Security Protections for System Administration Tools

All system administration operations are protected based on the user name employed to access a system administration tool. A user (or the group a user belongs to) must be a member of one of four security roles. These roles grant or deny a user access to various sets of system administration operations. The roles are Admin, Operator, Deployer, and Monitor. You can also set a security policy on WebLogic Server instances in a domain. For more information, see Protecting User Accounts in Managing WebLogic Security.

## System Administration Console

The Administration Console is a Web Application hosted by the Administration Server. You access the Administration Console from any machine on the local network that can communicate with the Administration Server through a Web browser (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, clusters, and applications. The management capabilities include:

- Configuration
- Stopping and starting servers
- Monitoring server health and performance
- Monitoring application performance
- Viewing server logs
- Assistants, which step you through the following tasks:

- Creating JDBC connection pools and DataSources
- Deploying your applications
- Configuring SSL

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

See:

- Starting the Administration Console
- Administration Console Online Help. (The online help is also available from the Administration Console by clicking on the "?" icon located in the upper right portion of the console.)

## Command-Line Interface

You use the command-line interface to manage a WebLogic Server domain when using the Administration Console is not practical or desired—such as when you want to manage your domain with scripts, when you cannot use a Web browser to access the Administration Console, or if you prefer using the command-line interface over a graphical user interface. You can use only the command-line interface to manage your domain, or use the command-line interface in combination with other system administration tools such as the Administration Console.

The command line interface invokes a Java class called `weblogic.Admin`. Arguments for this class enable you to perform many common management functions without knowing the JMX API. See:

- weblogic.Admin Command-Line Reference in the WebLogic Server Command Reference.
- WebLogic Server API Reference (in Javadocs, the `weblogic.management` packages)

If you require more fine-grained control than the `weblogic.Admin` management functions provide you can also use the command line interface to perform `set` or `get` operations directly on Mbean attributes. This feature requires knowledge of the WebLogic Server Mbean architecture. For more information, see the following resources:

- Commands for Managing WebLogic Server MBeans
- Javadocs for WebLogic Server classes.

- Select the `weblogic.management.configuration` package for configuration MBeans (to configure a WebLogic Server Domain)
- Select the `weblogic.management.runtime` package for runtime MBeans (for monitoring).

- A reference of Mbeans and attributes is provided in the BEA WebLogic Server Configuration Reference.

## JMX

Advanced Java programmers with knowledge of the JMX API from Sun Microsystems Inc. and WebLogic Server Mbeans can write their own management components as a Java class.

See:

- Programming WebLogic JMX Services
- WebLogic Server API Reference (in Javadocs, the `weblogic.management` packages.)

## Configuration Wizard

The Configuration Wizard is a tool for creating a new WebLogic Server domain or modifying an existing, inactive domain. Use the Configuration Wizard to:

- Create a new WebLogic Server domain—for stand-alone servers, Administration Servers with Managed Servers, and clustered servers.
- Create a new WebLogic Server domain based on a template. Templates allow you to re-create an existing domain for use in another context, such as migrating a domain containing an application under development to a production environment. See Configuration Template Builder.
- Add JMS Configurations off-line to an existing domain.
- Add JDBC Connection pools, MultiPools, and DataSources, off-line, to an existing domain.

The Configuration Wizard creates the appropriate directory structure for your domain, a basic `config.xml` file, and scripts you can use to start the servers in your domain. Depending on the options you select in the wizard, other files may also be created.

You can run the Configuration Wizard either using a graphical user interface (GUI) or in a text-based command line environment (this is called console mode—do not confuse this mode with the Administration Console). You can also create user-defined domain configuration templates for use by the Configuration Wizard.

See:

- Creating and Configuring Domains Using the Configuration Wizard
- Configuring WebLogic Platform

## Configuration Template Builder

A configuration template defines the full set of resources within a domain, including infrastructure components, applications, services, security options, and general environment and operating system options. BEA provides a number of templates and template extensions as part of the WebLogic Platform product. The templates delivered with your installation are described in the Template Reference.

The Configuration Template Builder provides the capability to easily create your own templates, to enable, for example, the definition and propagation of a standard domain across a development project, or to enable the distribution of a domain along with an application that has been developed to run on that domain. The templates you create with the Configuration Template Builder are used as input to the Configuration Wizard as the basis for creating a domain that is customized for your target environment. See Overview of the WebLogic Configuration Wizard and Configuration Template Builder in Configuring WebLogic Platform.

## Java Utilities

Utility programs are provided for common tasks such as deploying applications and testing DBMS configurations. For more information, see Using the WebLogic Java Utilities in the WebLogic Server Command Reference.

## Ant Tasks

You can use two Ant tasks provided with WebLogic Server to help you perform common configuration tasks in a development environment. Ant is a Java-based build tool similar to Make.The configuration tasks enable you to start and stop WebLogic Server instances as well as create and configure WebLogic Server domains. When combined with other WebLogic Ant tasks, you can create powerful build scripts for demonstrating or testing your application with custom domains.

See:

Using Ant Tasks to Configure a WebLogic Server Domain in the WebLogic Server Command Reference.

## Node Manager

Node Manager is a Java program provided with WebLogic Server that enables you to start, shut down, restart, and monitor remote WebLogic Server instances. To enable these capabilities, you run an instance of Node Manager on each physical machine in your domain.

See:

- Overview of Node Manager
- Configuring, Starting, and Stopping Node Manager
- Creating and Configuring Domains Using the Configuration Wizard

## SNMP

WebLogic Server includes the ability to communicate with enterprise-wide management systems using Simple Network Management Protocol (SNMP). The WebLogic Server SNMP capability enables you to integrate management of WebLogic Servers into an SNMP-compliant management system that gives you a single view of the various software and hardware resources of a complex, distributed system.

See:

- WebLogic SNMP Management Guide
- WebLogic SNMP MIB Reference

## Logs

Many WebLogic Server operations generate logs of their activity. Each server has its own log as well as a standard HTTP access log. These log files can be configured and used in a variety of ways to monitor the health and activity of your servers and applications.

See:

- Server Log in the Administration Console Online Help
- Setting Up HTTP Access Logs
- Using WebLogic Logging Services

You can also configure a special domain log that contains a definable subset of log messages from all WebLogic Server instances in a domain. You can modify which logged messages from a local server appear in the domain log using the system administration tools. You can view this domain log using the Administration Console or a text editor/viewer.

For more information, see Domain Log Filters in the Administration Console Online Help.

## Editing config.xml

You can manage a WebLogic Server domain by manually editing the persistent store for configuration, the `config.xml` file. (Other system administration tools automatically save the configuration to the `config.xml` file.) Because of the difficulty of correctly editing the XML syntax required in this file, this method of configuration is not recommended but may provide advantages in limited situations.

Note: Do not edit the `config.xml` file while the Administration Server is running.

For more information, see BEA WebLogic Server Configuration Reference.

# Resources You Can Manage in a WebLogic Server Domain

This section discusses the domain resources you manage with the system administration tools.

## Servers

The administrative concept of a server represents an instance of WebLogic Server in your domain. Using the system administration tools you can:

- Start and stop servers. (To start and stop servers on a remote machine, you must have Node Manager installed on the remote machine.) For more information see Node Manager.
- Configure a server's Listen address, listen port, HTTP settings, and time outs.
- Configure HTTP server functionality and Virtual Hosts
- Configure logging and view logs
- Configure Secure Sockets Layer (SSL)
- Deploy applications to specific servers
- Configure WebLogic Server resources active on the server, such as JDBC Connection Pools and startup classes.
- Tune the server for best performance

For more information, see:

- Creating, Configuring, and Monitoring Servers, in the Administration Console Online Help
- Starting and Stopping Servers, in the Administration Console Online Help
- weblogic.Server Command-Line Reference in the WebLogic Server Command Reference

## Clusters

WebLogic Server clusters allow you to distribute the work load of your application across multiple WebLogic Server instances. Clusters can improve performance and provide fail-over should a server instance become unavailable. For example, clusters provide several ways to replicate objects used in your applications so that data is not lost in the event of hardware failure.

You can architect combinations of clusters to distribute the work load in a way that provides the best performance for your applications.

Some services that are hosted on a single instance of WebLogic Server can be migrated from one server to another in the event of server failure. The system administration tools allow you to control these migrations.

See:

- Using WebLogic Server Clusters
- Clusters, in the Administration Console Online Help

## Machines

The administrative concept of a machine represents the computer that hosts an instance of WebLogic Server. WebLogic Server uses machine names to determine the optimum server in a cluster to which certain tasks, such as HTTP session replication, are delegated.

Using the system administration tools you can define one or more machines, configure Node Manger for those machines, and assign servers to the machines. For UNIX machines, you can configure UID and GID information.

See:

- Using WebLogic Server Clusters
- Machines, in the Administration Console Online Help

## Network Channels

A network channel is a configurable resource that defines the attributes of a network connection to WebLogic Server. You can use network channels to manage quality of service, meet varying connection requirements, and improve utilization of your systems and network resources. For more information, see Configuring Network Resources.

## JDBC

Java Database Connectivity (JDBC) allows Java programs to interact with common DBMSs such as Oracle, Microsoft SQL Server, Sybase, DB2, MySQL, and others.

Using the System Administration tools you can manage and monitor connectivity between WebLogic Server and your database management system. Connectivity is usually established through connection pools or DataSources.

See:

- JDBC, in the Administration Console Online Help
- Configuring JDBC Connection Pools, in the Administration Console Online Help
- Configuring JDBC DataSources, in the Administration Console Online Help
- Configuring JDBC MultiPools, in the Administration Console Online Help

## JMS

The Java Message Service (JMS) is a standard API for accessing enterprise messaging systems that allow communication between applications.

Using the system administration tools, you can define configuration attributes to:

- Enable JMS
- Create JMS servers
- Create and/or customize values for JMS servers, connection factories, destinations (physical queues and topics), distributed destinations (sets of physical queue and topic members within a cluster), destination templates, destination sort order (using destination keys), persistent stores, paging stores, session pools, and connection consumers.
- Set up custom JMS applications.
- Define thresholds and quotas.
- Enable any desired JMS features, such as server clustering, concurrent message processing, destination sort ordering, persistent messaging, message paging, flow control, and load balancing for distributed destinations.

For more information, see:

- Configuring JMS, in the Administration Console Online Help
- Monitoring JMS, in the Administration Console Online Help
- Tuning JMS, in the Administration Console Online Help

## WebLogic Messaging Bridge

A Messaging Bridge transfers messages between two messaging providers. The providers may be another implementation of WebLogic JMS or a third-party JMS provider.

For more information, see Messaging Bridge, in the Administration Console Online Help.

## Web Servers and Web Components

WebLogic Server can perform as a fully functional Web server. WebLogic Server can serve both static files such as HTML files and dynamic files such as Java servlets or Java ServerPages (JSP). Virtual hosting is also supported.

For more information on managing Web server functionality in WebLogic Server, see:

- Configuring Web Server Functionality for WebLogic Server.
- Virtual Hosts, in the Administration Console Online Help

You can also use Web Servers such as Apache, Microsoft IIS, and Netscape with WebLogic Server. For more information, see Using WebLogic Server with Web Servers.

## Applications

You deploy, configure, and manage the applications in your domain using the system administration tools to:

- Deploy applications to one or more WebLogic Servers or clusters in a domain. WebLogic Server uses a two-phase deployment model that gives you fault-tolerant control over the deployment process.
- Configure runtime parameters for the applications.
- Monitor application performance.
- Configure security parameters.
- View an application's deployment descriptor.
- Edit selected runtime elements of deployment descriptors. (Administration Console only). You can also use a text editor, an XML editor, or the WebLogic Builder tool to edit deployment descriptors. For more information, see Editing and Creating Deployment Descriptors with WebLogic Builder.
- Protect access to an application based on security roles or a security policy. For more information see Securing WebLogic Resources.

See:

- WebLogic Server Deployment
- Deploying Applications and Modules, in the Administration Console Online Help

### Application Formats

You deploy applications in one or more of the following J2EE application formats:

- Web applications
- Enterprise JavaBeans (EJB)
- Enterprise applications
- J2EE connectors
- Web services. Web services are deployed as a Web Application or Enterprise Application that includes a special deployment descriptor that configures the Web Service.

For more information, see:

- Developing Applications
- Assembling and Configuring Web Applications
- Deploying Applications and Modules
- Developing WebLogic Server Applications
- Programming WebLogic Enterprise Java Beans
- Programming WebLogic J2EE Connectors
- Programming WebLogic Web Services
- Defining a Security Policy
- Setting Protections for WebLogic Resources

### Editing and Creating Deployment Descriptors with WebLogic Builder

In addition to using the Administration Console to edit selected deployment descriptor elements you can also use the more robust WebLogic Builder tool that is included with your WebLogic Server distribution. WebLogic Builder is a stand-alone graphical tool for assembling a J2EE application, creating and editing deployment descriptors, and deploying an application on WebLogic Server. For more information, see WebLogic Builder Online Help.

## Startup and Shutdown Classes

A startup class is a Java program that is automatically loaded and executed when a WebLogic Server instance is started or restarted and after other server initialization tasks have completed. A shutdown class is automatically loaded and executed when a WebLogic Server instance is shut down either from the Administration Console or using the `weblogic.Admin` shutdown command.

You use the system administration tools to register and manage startup and shutdown classes.

For more information, see Startup and Shutdown Classes, in the Administration Console Online Help.

## JNDI

The Java Naming and Directory Interface (JNDI) API enables applications to look up objects—such as DataSources, EJBs, JMS, and MailSessions—by name. You can view the JNDI tree through the Administration Console.

See:

- JNDI, in the Administration Console Online Help
- Programming WebLogic JNDI

## Transactions

You use the system administration tools to configure and enable the WebLogic Server Java Transaction API (JTA). The transaction configuration process involves configuring:

- Transaction time outs and limits
- Transaction Manager behavior

See:

- JTA, in the Administration Console Online Help
- Programming WebLogic JTA

## XML

The XML Registry is a facility for configuring the XML resources of a WebLogic Server domain. XML resources in WebLogic Server include the parser used by an application to parse XML data, the transformer used by an application to transform XML data, external entity resolution, and caching of external entities.

See:

- Administering WebLogic Server XML
- XML, in the Administration Console Online Help

## Security

The WebLogic Server security subsystem allows you to plug in third-party security solutions and also provides out-of-the box implementations for many common security systems. You can also create your own security solution and implement it in WebLogic Server.

For backwards compatibility, the security functionality available in version 6.0 and 6.1 of WebLogic Server is also supported when the domain is running in Compatibility Security Mode.

Using the administration tools, you can define realms, users, groups, passwords, and other security features.

See:

- Managing WebLogic Security
- Using Compatibility Security in Managing WebLogic Security
- Security in the Administration Console Online Help
- Security Index Page

## WebLogic Tuxedo Connector

WebLogic Tuxedo Connector provides interoperability between WebLogic Server applications and Tuxedo services. The connector allows WebLogic Server clients to invoke Tuxedo services and Tuxedo clients to invoke WebLogic Server Enterprise Java Beans (EJBs) in response to a service request.

See:

- WebLogic Tuxedo Connector
- WebLogic Tuxedo Connector (WTC), in the Administration Console Online Help

## Jolt

Jolt is a Java-based client API that manages requests to BEA Tuxedo services via a Jolt Service Listener (JSL) running on a Tuxedo server.

See:

- BEA Jolt
- Jolt, in the Administration Console Online Help

## Mail

WebLogic Server includes the JavaMail API version 1.1.3 reference implementation from Sun Microsystems. Using the JavaMail API, you can add email capabilities to your WebLogic Server applications. JavaMail provides access from Java applications to IMAP- and SMTP-capable mail servers on your network or the Internet. It does not provide mail server functionality; so you must have access to a mail server to use JavaMail.

See:

- "Using JavaMail with WebLogic Server Applications" under Programming Topics.
- Mail, in the Administration Console Online Help

# Starting the Administration Console

This section contains instructions for starting the Administration Console.

To use the Administration Console, use one of the supported Web Browsers for your environment. See Browser Support for the WebLogic Server Console. If your Web browser is not on this list of supported browsers, you may experience functional or formatting problems when using the Administration Console.

To start the Administration Console:

1. Start an Administration Server. See Starting Administration Servers in the Administration Console Online Help.
2. Open one of the supported Web browsers and open the following URL:

>     http://hostname:port/console

Where `hostname` is the DNS name or IP address of the Administration Server and `port` is the listen port on which the Administration Server is listening for requests (port 7001 by default). If you have configured a domain-wide Administration port, use that port number. If you configured the Administration Server to use Secure Socket Layer (SSL) you must add `s` after `http` as follows:

`https://``hostname``:``port``/console`

Note: A domain-wide administration port always uses SSL. See Server --> Configuration --> Keystores and SSLin the Administration Console Online Help

3. When the login page appears, enter the user name and the password you used to start the Administration Server (you may have specified this user name and password during the installation process) or enter a user name that belongs to one of the following security groups: Administrators, Operators, Deployers, or Monitors. These groups provide various levels of access to system administration functions in the Administration Console. See Protecting User Accounts in Managing WebLogic Security.

Using the security system, you can add or delete users to one of these groups to provide controlled access to the console. See Protecting User Accounts in Managing WebLogic Security.

Note: 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 `127.0.0.1` are not sent to the proxy.

For information on using the Administration Console, see Using the Administration Console in the Administration Console Online Help.

# Using WebLogic Server with Web Servers

You can proxy requests from popular Web servers to an instance of WebLogic Server or a cluster of WebLogic Servers by using one of the Web server plug-ins. Plug-ins are available for the following Web servers:

- Netscape Enterprise Server or IPlanet
- Microsoft Internet Information Server
- Apache

Because these plug-ins operate in the native environment of the Web server, you manage the plug-ins through the administration facilities of that Web server.

For more information, see Using WebLogic Server with Plug-ins.

Special servlets are also included with the WebLogic Server distribution to proxy requests from an instance of WebLogic Server to another instance of WebLogic Server or to a cluster of WebLogic Servers. For more information, see:

- Configure Proxy Plug-ins in Using Web Server Plug-Ins With WebLogic Server
- Proxying Requests to a WebLogic Cluster in Using WebLogic Server Clusters

# Monitoring

The system administration tools contain extensive capabilities for monitoring WebLogic Servers, domains, and resources. Using the tools you can monitor:

- Server health and performance:

- Execute Queues
- Connections
- Sockets
- Threads
- Throughput
- Memory Usage

- Security:

- Locked-out users
- Invalid Logins
- Login attempts

- Transactions:

- Committed transactions
- Rolledback transactions

- JMS connections and servers
- WebLogic Messaging Bridge
- Applications:

- Servlet sessions
- Connector connection pools
- EJB performance

- JDBC connections and connection pools

For more information, see Monitoring a WebLogic Server Domain.

# Licenses

WebLogic Server requires a valid license to function. An evaluation copy of WebLogic Server is enabled for a limited time period so you can start using WebLogic Server immediately. To use WebLogic Server beyond the evaluation period, you will need to contact your salesperson about further evaluation or purchasing a license for each IP address on which you intend to use WebLogic Server. All WebLogic Server evaluation products are licensed for use on a single server with access allowed from up to 20 connections to the server.

If you downloaded WebLogic Server from the BEA Web site, your evaluation license is included with the distribution. The WebLogic Server installation program allows you to specify the location of the BEA home directory, and installs a BEA license file, `license.bea`, in that directory.

See "Installing and Updating WebLogic Platform License Files" in Installing WebLogic Platform.