The role of the administration server is to run the administration service for the entire domain, providing a central control for configuring, managing, and monitoring all aspects of a WebLogic domain, including

The configuration information for the entire WebLogic domain is maintained by the administration server in a configuration repository, which currently exists as an XML file named config.xml. The config.xml file is, by default, located in the root of the directory from which the administration server is launched, and can be viewed using a Web browser or any XML editor. The config.xml file is discussed in detail in the next section.

The role of a managed server is to execute the applications that are deployed to its WebLogic domain and make available their status to the administration server. Upon startup, managed servers

The configuration settings that are received by a managed server from an administration server include the config.xml and the SerializedSystemIni.dat files. Upon receiving these files, a managed server always caches them to its root directory on the local file system. You also have the option to manually copy these files from the administration server’s root directory to the managed server’s root directory. By default, the directory from which an administration or managed server is launched is considered its respective root directory. Without the presence of these files, you cannot start a managed server.

By default, the encrypted boot.properties file, which enables WebLogic Server to start up while bypassing the startup prompt for username and password, is not automatically copied from the administration server to any managed server. If you want to use this file in the startup of your managed servers, you will need to manually copy the file from the root directory of the administration server to the root directory of your managed server.

After the initial startup and shutdown of a managed server, if the administration server becomes unavailable before a managed server is started, these cached configuration files are used to start the managed server. However, the managed server cannot persist any changes of its state or even be managed or monitored until its designated administration server is available again. Managed servers that are started in this manner are in Managed Server Independence (MSI) mode. When an administration server is started, it queries its running-managed-servers.xml file to identify the managed servers that were registered with it so that they can be notified to reregister with the administration service.

It is only at startup that managed servers have a slight dependency on the availability of an administration server. When they are operational, the only consequence for shutting down an administration server is that the administration service will not be running, which has no effect on the execution of an application on the managed servers.

The relationship between the administration and managed servers is summarized in Figure 24.2.

Figure 24.2. The relationship between the administration and managed servers in a WebLogic domain.

The management of a WebLogic domain is, in essence, a collective management effort of all the subsystems (resources and services) of WebLogic Servers that constitute a domain. The management capabilities (configuration and monitoring) of these subsystems as well as the applications they support are represented within WebLogic Server as MBeans (managed beans), which are implemented as Java classes in compliance with the Java Management Extension (JMX) specification as defined by Sun. The WebLogic administration service institutes management of subsystems such as the Web and EJB containers, JDBC, JMS, SNMP, and JTA, through their respective MBeans.

Each WebLogic Server subsystem has a set of attributes that can be configured and monitored, with some subsystems providing additional management capabilities through administration methods. The role of an MBean is to provide an administration interface to these attributes and methods of a WebLogic Server subsystem, decoupling the subsystem from its management interface.

As shown in Figure 24.3, one or more MBeans can be associated with each WebLogic subsystem, and can include the following elements:

Figure 24.3. The elements of a WebLogic Server MBean.

The following three types of MBeans are used to manage a WebLogic domain:

The system administration tools provided with WebLogic Server—the Administration Console and weblogic.Admin utility—provide an interface to the administration service, allowing you to manage a WebLogic domain without requiring any knowledge of the JMX API. However, knowledge of the WebLogic MBean interfaces is required to use the weblogic.Admin utility to interface with the administration service.

The Administration Console is the preferred Administration tool, allowing you to manage and view the attributes of Administration and Runtime MBeans through a graphical interface (such as a Web browser). The Administration Console can manage only one WebLogic domain at a time; therefore, multiple WebLogic domains require their own instance of the Administration Console. From the Administration Console, you can also determine the MBean attribute you are working with by clicking the question mark next to an attribute field. However, the Administration Console enables you to manage and view only the attributes of Configuration MBeans.

Alternatively, the weblogic.Admin tool enables you to manage and retrieve the attributes of Administration and Configuration MBeans, as well as invoke the methods of Runtime MBeans through the CREATE, DELETE, GET, SET, and INVOKE commands.

Both the Administration Console and the weblogic.Admin tools should provide you with the initial administration and monitoring capabilities you need for your environment. However, if you have administration requirements that are not satisfied by these tools, you can either write your own JMX extensions to the Administration Console, or you can purchase a suitable WebLogic Server administration tool provided by one of BEA’s solution partners, which are listed on the BEA Web site.

To create a WebLogic domain in a Windows environment, follow these steps:

If you select the Admin Server with Managed Server(s) option in step 3, the only difference from the preceding series of steps would be that you would see the Configure Managed Servers in Admin Server screen, as shown in Figure 24.4. From this screen, you can add multiple managed servers to your WebLogic domain by clicking the Add button and entering the new managed server information in the displayed Add Server dialog. However, these managed servers will be configured to run on the same machine as the administration server of the domain.

Figure 24.4. Adding managed servers to a WebLogic domain using the Admin Server with Managed Server(s) option in the Configuration Wizard.

You can start the administration server (AdminServer) you have just created by executing the following scripts from the command prompt, which can be located in the BEA_HOME/user_projects/domain directory:

After you successfully start the administration server, the last two lines of the startup process in the command console should look similar to the following:

<Oct 8, 2002 3:20:11 AM EDT> <Notice> <WebLogicServer> <000365> <Server state changed to RUNNING>

<Oct 8, 2002 3:20:11 AM EDT> <Notice> <WebLogicServer> <000360> <Server started in RUNNING mode>

To extend a WebLogic domain using the Configuration Wizard, you must install the WebLogic Server software, which includes the Configuration Wizard, on the machine that will host the managed server. After you satisfy this prerequisite, you can follow these steps to add a remote managed server named mServer to your newly created WebLogic domain (ObjectMind):

A common misconception of extending a WebLogic domain using the Configuration Wizard is that you can start a remote managed server after it is created. This is not true, and most people make this mistake. If you want to start a remote managed server:

Because the Configuration Wizard does not make a connection with the administration server, the domainwide config.xml file is not updated with the new managed server information, and a config.xml file is not copied from the administration server to the remote managed server’s file system. Instead, the Configuration Wizard just creates a skeleton version of the config.xml file and places it in the root of the managed server’s domain directory.

To successfully start a remote managed server, you need to use the Administration Console to register the managed server with its associated domain’s administration server. This two-step process involves

These tasks are described in the following two sections.

Configuring a New Server Definition within a WebLogic Domain

The following steps will guide you through the configuration of a new WebLogic Server definition for your remote managed server using the Administration Console:

1. Select the Servers node in the left panel of the Administration Console.

2. In the right panel of the Administration Console, click the Configure a New Server link.

3. Enter the following information in the General tab to configure your managed server, as shown in Figure 24.8:

   

   Figure 24.8. Configuring a new server in a WebLogic domain using the Administration Console.

   • Name—. Enter the name of the managed server, for example, mServer.

   • Machine—. Select the machine name that hosts the managed server from the drop-down list box.

   • Cluster—. Select None from the drop-down list box.

   • Listen Address—. Enter the TCP/IP address or DNS name of the machine that will host the managed server.

   • Listen Port Enabled—. Select this box because it indicates the managed server will enable non-SSL HTTP communication.

   • Listen Port—. Enter the number assigned to your listen port.

   • Startup Mode—. Enter Running for the startup mode of the managed server.

   • External DNSName—. If the managed server will receive HTTP requests from behind a firewall that performs Network Address Translation, enter the DNS name of the machine name, to enable requests to be routed to the appropriate managed server.

4. Click Create to configure your managed server in the WebLogic domain’s config.xml file.

You should also assign your administration server to a machine definition.

After you complete these steps, you can start your remote managed servers by executing the following scripts from the command prompt, which can be located in the BEA_HOME/user_projects/domain directory of the remote physical machine where the managed server is being hosted:

• setEnv.cmd—. Configures the managed server’s operating system environment, including the CLASSPATH variable.

• startManagedWebLogic.cmd—. Starts your managed server. You will be promoted to enter the administrator username and password you specified in the configuration of the managed server using the Configuration Wizard. However, you can securely bypass this prompt using the boot.properties file. You can also provide the respective username and password values to the WLS_USER and WLS_PW variables in the startup script. The disadvantage of this approach is that the username and password are in clear text and viewable through any text editor.

During the startup operation, the managed server connects to its associated administration server and copies over the necessary configuration files it requires to start, which will be cached to the managed server’s root directory. From this point onward, by default, the managed server is configured to start in independence mode if the administration server is not available during its startup operation.

If your domain’s configuration changes frequently—for example, during the development phase of your project—the administration server has an option that can replicate the configuration files to the managed server every five minutes, if required. You can enable this option by selecting the MSI File Replication Enabled option in the Configuration, Tuning tab for a managed server in the Administration Console, as shown in Figure 24.9.

Figure 24.9. Enabling the replication of configuration files for a managed server.

Caution

Because changes to a WebLogic domain should be very tightly controlled in a production environment, MSI should be enabled only for development managed servers. BEA recommends that you not enable file replication for a server that shares an installation or root directory with another server because unpredictable errors can occur for both servers.

WebLogic Server uses network channels to define the basic attributes of a network connection to a WebLogic Server instance. Sample attributes of a network channel include

The previous version of WebLogic Server used one default network channel for all its network communication. When you define multiple network channels, you can configure additional port numbers and protocol settings for use with one or more WebLogic Server instances. For example, you can do the following:

Taking this approach, you can ensure the same network connection properties for each WebLogic Server instance in a domain. Any changes to the network channel’s connection attributes automatically propagate to the WebLogic Server instances that employ that network channel. Network channels, in a way, serve as templates for the network configuration of a WebLogic domain, and can be exploited further when they are used in conjunction with network access points (NAPs), which are discussed in the “Understanding Network Access Points” section later in this chapter.

For each WebLogic Server instance, you can use three types of network channels, which are all bound to the same network IP address:

The following sections describe how to view your default network configuration information, enable the administration port, and configure a simple network channel using the Administration Console.

Enabling the Administration Port

When the administration port is enabled for a WebLogic domain, an administration network channel is automatically created for each WebLogic Server instance in that domain upon startup. This administration network channel is then used for all administration-type traffic within the domain. Having a distinct and dedicated domainwide administration port provides the following advantages:

• The administration traffic is assured no contention with application traffic for critical administration operations.

• WebLogic Server can be started in a standby state, which is a new WebLogic Server Lifecycle feature.

Even though these advantages are very appealing from an administration perspective, the administration port accepts only secure (SSL) connections, which implies that you will have to set up each WebLogic Server in your domain with support for SSL. All managed servers within a domain will need to establish an SSL connection to the administration server. Also, the administration port is a domainwide option, so you cannot configure an administration port for individual managed servers within a domain; it is an all-or-none option.

Because SSL communication is a prerequisite for using the administration port, enabling this feature is a three-step process, which first involves setting up an SSL for each WebLogic Server in your domain, including the administration server. When this task is complete, you can enable the administration port feature. Finally, you must modify the startup scripts for each managed server in the domain so they use the SSL protocol and the administration port to connect to the administration server.

Caution

After you enable the Administration port, no communication between the administration and managed servers is possible over the plain-text HTTP protocol. Only communication using the secure HTTPS protocol is allowed.

The following steps will guide you through enabling the SSL protocol for each WebLogic Server in your domain, using the default certificate (democert.pem) and private keys (demokey.pem) provided with WebLogic Server:

Caution

The default WebLogic certificate and private keys are for demonstration purposes only. They should be used only to proof an SSL configuration.

1. From the Server node in the left pane of the Administration Console, select a WebLogic Server.

2. In the Connections, SSL tab, enter the following information, as shown in Figure 24.12:

   

   Figure 24.12. Setting the demonstration SSL attributes for the SSL protocol using the Administration Console.

   • Server Certificate File Name—. Enter democert.pem.

   • Hostname Verification Ignored—. Enable this option.

     Note

     The Hostname Verification Ignored attribute should be enabled only for demo or trial certificates.

   • Server Key File Name—. Enter demokey.pem.

   • Trusted CA File Name—. Enter ca.pem.

   Note

   Using ca.pem for Trusted CA File Name is required only for two-way SSL communication.

   Click Apply.

3. In the Connections, SSL Ports screen, make sure you have enabled the SSL Listen Port, as shown in Figure 24.13, and click Apply.

   

   Figure 24.13. Enabling the SSL protocol for a WebLogic Server.

The following steps will guide you through enabling the administration port for your domain using the Administration Console:

1. Click the name of your domain in the left pane.

2. Click the Configuration, General tab in the right pane to display the domain’s general configuration information.

3. Select the Enable Domain Wide Administration Port checkbox in the right pane, as shown in Figure 24.14.

   

   Figure 24.14. Enabling the Domain Wide Administration Port.

4. Enter a value in the Domain Wide Administration Port field to specify the default administration port that all servers will use. By default, this value is set to 9002. Click Apply.

5. Shut down all the WebLogic Server instances in your domain, including the administration server.

Before starting the WebLogic Servers, make sure you have modified the startup scripts for your WebLogic Servers as follows:

• Ensure you have specified the following startup options for the JAVA_OPTION variable in both the startWebLogic.cmd and startManagedServer.cmd scripts:

  -Dweblogic.security.SSL.ignoreHostnameVerification=TRUE
  
  -Dweblogic.security.SSL.trustedCAKeyStore=d:eaweblogic700serverlibcacerts
  

  Caution

  Even though you have enabled this feature via the Administration Console, there is currently a problem with the managed servers acknowledging this feature has been enabled. It is only for this reason that you have to be explicit in the startup script of the managed servers.

• For each managed server’s startup script (startManagedServer.cmd), ensure the ADMIN_URL variable specifies the SSL protocol for connecting to the administration server port, as in this example:

  SET ADMIN_URL=https://host:admin_port
  

To restart your domain’s WebLogic Servers, start the administration server first. To use the Administration Console from this point onward, you will need to use the HTTPS protocol and the defined administration port, as shown in this example:

https://host:admin_port/console

You should validate the default administration channel using the Connections, Summary tab in the Administration Console, as shown in Figure 24.15.

Figure 24.15. Validating the configuration of your administration port.

After you start your administration server and validate the default administration port settings, you can start your managed servers using their respective startup scripts.

Note

If you run into any SSL handshake problems, they imply that you have not correctly set the SSL attributes via the Administration Console, or the Hostname Verification Ignored startup option has not been specified in your startup scripts. In such a case, make sure you have declared the following options in your startup scripts:

-Dweblogic.security.SSL.ignoreHostnameVerification=TRUE
-Dweblogic.security.SSL.trustedCAKeyStore=d:eaweblogic700serverlib
cacerts

A network access point (NAP) is an optional configurable resource that is used in the context of a network channel to override certain network channel attributes on a per-server basis. For example, because all network channels inherit their listen address from their target WebLogic Server’s default network channel, you can use NAPs to override this value to take advantage of multiple NICs with different IP addresses or multiple IP addresses assigned to one NIC. However, only one NAP can be assigned to each defined network channel on a WebLogic Server instance.

You can leverage together network channels and NAPs as follows:

If you do not configure a NAP for a network channel, the WebLogic Server instance uses the configuration associated with the network channel to generate a new network connection.

Leveraging Network Access Points in Your Network Channel

As stated earlier, NAPs in conjunction with network channels allow you to leverage multiple NICs and IP addresses, enabling you to physically segment the network traffic within your WebLogic domain. To showcase how you can use NAPs, this section describes how to create an edge server configuration, similar to Figure 24.18.

Tip

If you do not have multiple IP addresses on your machine, you can use ports instead of IP addresses to logically segment your network traffic because the principle is still the same.

As shown in Figure 24.19, the network channel and NAP configuration required for this example are as follows:

Figure 24.19. A simple edge server configuration example showcasing the use of network channels and NAPs.

• An ncPublic network channel will be created to allow public incoming and outgoing network traffic. However, it will not be configured to allow server-server connections between WebLogic Servers in a domain. For this reason, this channel will be assigned to the WebLogic Server that will accept network connections from clients (the edge server). In this example, the AdminServer will serve as the edge server.

• The ncPublic network channel will use the same IP address assigned to the default network channel.

• An ncInternal network channel will be created to service all server-server connections from the edge server (AdminServer) to the managed servers, which in this example will be mServer.

• The ncInternal network channel will use NAP to be assigned to a unique private IP address on the edge server.

The following steps will guide you through creating your edge server configuration:

1. To create the ncPublic and ncInternal network channels, use the steps described earlier in this chapter in the “Configuring a Network Channel” section.

2. Using the Targets, Server tab for each channel, as shown in Figure 24.20, assign the newly created network channels to their WebLogic Servers as follows:

   

   Figure 24.20. Assigning the network channels to their WebLogic Servers.

   • Assign the ncPublic channel to your edge server (AdminServer).

   • Assign the ncInternal channel to your edge and support (mServer) servers, respectively.

   Click Apply.

3. For the ncPublic network channel, disable the Outgoing Enabled option using the Configuration, Tuning tab, as shown in Figure 24.21.

   

   Figure 24.21. Disabling the Outgoing Enabled option for a network channel.

4. In the left pane, select the edge server (AdminServer) and display the Connections, Tuning tab.

5. Click the Channel Overrides link.

6. From the displayed assigned network channels, select the ncInternal channel because this is the channel where you will be applying the new NAP settings (overriding default network channel settings).

7. From the Configuration, General tab, enter a new listen address for this channel, as shown in Figure 24.22.

   

   Figure 24.22. Creating a NAP for the listen address of a network channel.

   If you do not have multiple IP addresses, you can override the default ports for both the listen and SSL ports. This way, you can logically segment your network traffic from the ncPublic channel.

8. Click Apply to save your NAP settings.

Tip

You should always use NAPs to explicitly specify the listen address of a network channel on a machine that has multiple NICs. If you leave the listen address blank or use Localhost, the network channel’s listen port and SSL listen ports will be bound to all available IP addresses on the NICs.

Now that you have learned the objectives and reasons for using a Node Manager within a distributed WebLogic domain, the next step is to learn how to configure and start the Node Manager.

The steps in the following sections guide you through the process of configuring a Node Manager on the machine nodes where your managed servers are located.

-Dweblogic.nodemanager.reverseDnsEnabled=true

You can start the Node Manager Java program by using one of the following methods:

Because you have to specify the same Node Manager environment variables and properties regardless of the startup method you select, you should use the startup script initially. This approach allows you to easily proof your Node Manager startup settings. When you have the Node Manager fully operational with the ability to start, monitor, and shut down a managed server via the Administration Console, you can implement a Windows service or Unix daemon with a proven set of Node Manager environment variables and properties.

The following sections discuss how to configure and start the Node Manager using a startup script and then how to create a Node Manager Windows service.

Starting the Node Manager Using a Startup Script

The default Node Manager startup script, named startNodeManager.cmd, is located in the WL_HOME serverin directory, where WL_HOME is the WebLogic Server installation directory (C:eaweblogic700 by default). To start the Node Manager, you need to review and edit the environment variables and properties (startup arguments) set in this file using any text editor. To assist in this task, you can use the Node Manager and WebLogic environment variables and properties described in Table 24.3 as a guide for correctly configuring your Node Manager startup script.

Table 24.3. The Environment Variables and Properties for a Node Manager Startup Script

Node Manager Startup Variables and Properties	Description
%NODEMGR_HOME%	The Node Manager working directory for storing output and log files
%JAVA_HOME%	The root directory of the installed JDK used to start the Node Manager
%DOMAIN%	The root directory of the managed server domain
%MEM_ARGS%	The memory arguments you want to pass to the JVM
-Dbea.home	The directory where the BEA license files are located
-Djava.security.policy	The path to the WebLogic security policy file
-Dweblogic.nodemanager.sslHostNameVerificationEnabled	Determines if the Node Manager performs host name verification
-Dweblogic.nodemanager.javaHome	The Java home directory that Node Manager uses to start the managed servers
-Dweblogic.nodemanager.reverseDnsEnabled	Determines if DNS names will be used instead of an IP address for the listen port
Dweblogic.ListenAddress	The address on which Node Manager listens for connection requests
Dweblogic.nodemanager.keyFile	The path to the private key file to use for SSL communication
Dweblogic.security.SSL.trustedCAKeyStore	The path to the KeyStore that contains the certificates of trusted authorities
Dweblogic.nodemanager.certificateFile	The path to the certificate file used for SSL authentication

The following are sample values that can be assigned to the environment variables and properties described in Table 24.3:

WL_HOME=C:eaweblogic700

NODEMGR_HOME=%WL_HOME%common
odemanager

JAVA_HOME=C:eajdk131_03

DOMAIN=c:eauser_projects

MEM_ARGS=-Xms32m -Xmx50m

-Djava.security.policy=%WL_HOME% serverlibweblogic.policy

-Dweblogic.nodemanager.sslHostNameVerificationEnabled=false

-Dweblogic.nodemanager.javaHome=%JAVA_HOME%

-Dweblogic.nodemanager.sslHostNameVerificationEnabled=FALSE

weblogic.nodemanager.reverseDnsEnabled=TRUE

-Dweblogic.ListenAddress=SOCRATES

-Dweblogic.ListenPort=7266

-Dweblogic.nodemanager.javaHome=%JAVA_HOME%

-Dweblogic.nodemanager.keyFile=c:eauser_projectsobjectminddemokey.pem

-Dweblogic.nodemanager.certificateFile=c:eauser_projectsobjectminddemocert.pem

After you appropriately edit the Node Manager startup arguments, you can start the Node Manager from the command line by executing the startNodeManager.cmd command, as shown in Figure 24.25.

Figure 24.25. The startup console for the Node Manager.

After a Node Manager is successfully started on a machine, you can engage in starting one, multiple, or a cluster of managed servers on that machine in the context of a WebLogic domain using the Administration Console.

To start a managed server—for example, mServer that was created earlier in this chapter—using the Administration Console, follow these steps:

When you start a managed server using the Administration Console via the Node Manager, you can view the startup messages using the Details tab, as shown in Figure 24.26.

Figure 24.26. Reviewing the startup messages for a remotely started managed server.

To stop the server, you can perform the same steps except that you select the shutdown option. You can also use the Administration Console to start and stop all the managed servers in a cluster or in a domain, as long as the managed servers are configured for remote start.

The Node Manager always starts or restarts a managed server in its last runtime state, regardless of the startup mode you have specified.

If you incur any problems starting a Node Manager or while starting or stopping managed servers via the Node Manager, reviewing the log files associated with Node Manager should be your first task in diagnosing the root cause of the problem. These files hold valuable information that will help you isolate the problem.

The log files related with a Node Manager and the managed servers it starts are located on the machine that hosts the Node Manager within the NodeManagerLogs directory, which is within the directory specified by the %NODEMGR_HOME% variable in the startNodeManager.cmd script.

The Self-Health monitoring capability is a new feature of the WebLogic Server; it enables decoupled critical subsystems such as the WebLogic Server Kernel, JMS, and JTA to provide feedback on their health to determine the overall health of a WebLogic Server instance.

When a WebLogic Server starts, all self-health–enabled subsystems register themselves with their Health Monitoring System. Rather than the WebLogic Server determining the health of these subsystems, which can be a resource/performance overhead, each of the registered subsystems is responsible for internally and asynchronously monitoring its own health based on criteria specific to its subsystem. If at any point a self-health–enabled subsystem determines it can no longer operate in a consistent and reliable manner, it registers a Failed health state with its associated runtime MBean—for example, the JMSRuntimeMBean for a JMS subsystem.

To determine the overall health of a WebLogic Server instance, the Health Monitoring System periodically (the default is 180 seconds) queries the health state attribute of the runtime MBeans associated with self-health–enabled subsystems. If any of these subsystems are found to be in a Failed state, the overall state of the associated WebLogic Server instance is also considered to be in a Failed state because the overall health of a WebLogic Server instance is determined as the sum of all the registered subsystems.

To improve the reliability and availability of your WebLogic domain, you can use the Health Monitoring System in conjunction with the Node Manager to ensure managed servers that are deemed to be in a Failed state are immediately shut down and, if required, restarted again. A Node Manager can deem a managed server to be in Failed state for a number a reasons; the following are some examples:

The only caveat is that the Node Manager can monitor the health state of only those managed servers it has started.

To configure a Node Manager to monitor a managed server’s health, you need to edit the managed server’s Health Monitoring attributes, which you can do using the Administration Console as follows:

Because a Node Manager can apply the Health monitoring and subsequent shutdown and restart activities only on those servers it starts, you need to shut down and then restart those servers that will be monitored via the Node Manager.

The logging characteristics for a local log file can be modified on a per WebLogic Server basis, using the following tabs in the Administration Console:

You can also enable WebLogic Server to create separate local HTTP, JDBC, and JTA subsystem log files.

The following sections describe each of these tabs.

The General Tab

From the General tab, as shown in Figure 24.28, you can specify the following attribute values:

Figure 24.28. A WebLogic Server’s Logging, General tab.

• File Name—. Specifies the location and name of the WebLogic Server’s Local log file.

  Caution

  If you modify the local log filename, you will need to restart WebLogic Server to enable the logging activities to occur to the new file.

• Log to Stdout—. Specifies whether logging information should be sent to standard output as well as the local log file. This is enabled by default.

• Debug to Stdout—. Specifies whether debug messages should be sent to the standard output. This is disabled by default.

• Stdout Severity Threshold—. Specifies the severity level of the messages sent to the standard output, if it has been enabled.

The Rotation Tab

By default, WebLogic Server’s local log file will grow in size indefinitely. To keep the log file to a manageable and viewable size, you can rotate the log file based on its size or on a specific time interval. Upon rotation, the current log file is renamed by adding a sequence number suffix, and a new local log file is created, which will store all subsequent WebLogic Server messages. For example, if you have a log file named AdminServer.log, after the first rotation, it will be renamed AdminServer.log00001.

You can specify the rotation criteria for your local log file using the Rotation tab, as shown in Figure 24.29.

Figure 24.29. WebLogic Server’s Logging, Rotation tab.

From the Rotation tab, you can specify the following:

• Rotation Type—. The criteria to rotate the local log file, which are None, By Size, and By Time. If you select None, your local log file will not rotate.

• File Min Size—. If you selected to rotate the log file using the By Size criteria, you will need to specify the maximum size of the log file upon which it is rotated.

• Rotation Time—. If you selected to rotate the log file using the By Time criteria, you will need to specify the starting time for the time-based rotation to occur. You can create a recurring or nonrecurring start time using the MM-dd-yyyy-k:mm:ss date-time format, where

  • MM—. Month

  • dd—. Day in the month

  • yyyy—. Year

  • k—. Hour in the day (1–24)

  • mm—. Minute in the hour

  • ss—. Second in the minute

  For example, if you want to start the time-based rotation in your current day at 12:55 p.m., you can just enter 12:55.

  Caution

  Log rotation by time is based on the time stamp of the local log file. For this reason, you should not modify the log file, thus causing the time stamp to change.

• File Time Span—. If you selected time-based rotation, you can specify the number of hours between each log file rotation. The minimum is one hour.

• Number of Files Limited and File Count—. If you selected either the size or time-based rotation, enabling this option specifies the File Count number of rotated log files to create, before the oldest log file is overwritten.

You do not need to restart WebLogic Server after you specify your rotation criteria.

You can modify the name and rotation criteria for the default domainwide log file using the domain’s Configuration, Logging tab in the Administration Console, as shown in Figure 24.30.

Figure 24.30. Modifying the default domainwide log file attributes.

Even though messages of varying severity levels are broadcast by managed servers within a domain via their own JMX facilities, the administration server’s Message Listener, by default, filters out messages with the ERROR severity level and higher and writes them to the domainwide log file. Hence, the domainwide log provides only an overall summary of the status of the domain.

DEBUG and stack trace messages are never broadcast from managed servers to the administration server.

However, if you have a service-level agreement that warrants the need to monitor domainwide messages with a different minimum severity level, it is very impractical to try to perform this task by accessing the local WebLogic Server log files, especially if you have a large and distributed WebLogic domain.

When you require comprehensive domainwide log monitoring, you can override this default filter for specific WebLogic Servers in your domain by creating a domain log filter, which can be customized to receive messages based on different criteria.

The following steps describe how to create a domain log filter using the Administration Console:

You can also enable and reselect the domain log filter for a specific WebLogic Server using the Logging, Domain tab in the Administration Console for a specific WebLogic Server, as shown in Figure 24.33.

Figure 24.33. Enabling and selecting a domain log filter for WebLogic Server.