The Configuration File in WebLogic Server Domain — config.xml

A WebLogic domain^[1] is the basic administrative unit of WebLogic Server. It consists of one or more WebLogic Server instances, and logically related resources and services that are managed collectively as one unit. A WebLogic Server instance can be either an Admin Server or a Managed Server.  Managed Server instances can be grouped into a cluster which work together to provide scalability and high availability for applications.  Each WebLogic domain has one and only one Admin Server. When the Admin Server is used to perform a configuration task, the changes apply only to the domain managed by that Admin Server.

Each domain's configuration is stored in a separate configuration file called config.xml. The config.xml file is a persistent store for the managed objects that WebLogic Server creates and modifies during its executing using the JMX API. The config.xml file specifies the name of the domain and the configuration parameter settings for each server instance, cluster, resource, and service in the domain.

Since each config.xml is assoicated with a specific domain, it is required to be stored in the Root Directory of the Admin Server. For example, you can find it in the following directory:

• .../user_projects/domains/<domain name>/config

in the standalone WLS installation or

• .../system11.1.1.6.38.62.38/DefaultDomain/config

in the Integrated WLS installation^[2]. Note that the root directory of Admin Server can be configured with the -Dweblogic.RootDirectory=path option in the server's startup command.

config.xml

When the Admin Server starts, it loads the config.xml for the domain. When a Managed Server in the same domain starts up, it connects to the domain's Admin Server to obtain configuration and deployment settings.

You should normally use the WLS Admin Console to configure WebLogic Server's manageable objects and services and allow WebLogic Server to maintain the config.xml file. You would only directly update under unusual circumstances. In this article, we will introduce you one such legitimate usage:

• For performance tests, we need to conduct performance analysis with different WLDF diagnostic volume settings:
• Off — No diagnostic data is automatically produced.
• Low — A minimal volume of diagnostic data is automatically produced. This is the default.
• Medium — Additional diagnostic data is automatically generated beyond the amount that is generated for Low.
• High — Additional diagnostic data is automatically generated beyond the amount that is generated for Medium.

WebLogic Diagnostic Framework (WLDF)

The WebLogic Diagnostic Framework (WLDF)^[4] provides features for generating, gathering, analyzing, and persisting diagnostic data from WebLogic Server instances and from applications deployed to server instances.

You can use Admin Console to configure the WLDF diagnostic volume:

1. In the left pane, select Environment > Servers.
2. In the Servers table, click the name of the server instance for which you want to configure the WLDF diagnostic volume.
3. Select Configuration > General.
4. On the Servers: Configuration: General page, select one of the following values in Diagnostic Volume:
   • Off
   • Low
   • Medium
   • High
5. Click Save.

At runtime, WLS maintains three copies of config.xml:

1. ./servers/domain_bak/config_prev/config.xml
2. ./pending/config.xml
3. ./config/config.xml

Each time the Admin Server starts successfully, and each time the configuration is modified, a backup configuration file is created (i.e., the 1st copy). The number of backup copies of config.xml retained by the Admin Server can be configured.

After the Save action, the changes will be propagated to the pending copy (i.e., the 2nd copy). But, not until you activate the changes, will the changes be propagated to the true final copy (i.e., the 3rd copy).

Preparation of Our Performance Tests

Before making any changes to the config.xml file, you should make a copy of it first. To prepare for our different test scenarios, we launch the WLS Admin Console and set WLDF diagnostic volume to different settings. After activating the changes, we make a copy of config.xml and name it accordingly (e.g., config.xml.high, config.xml.off, etc.).

After we have different copies of config.xml with different volume settings, we then run our automation script in such a way:

1. At the beginning of each test, we copy config.xml with appropriate setting (i.e., config.xml.high) to be the config.xml
2. We then launch WLS with the new config.xml for our performance test
• Note that Admin Server needs to  be restarted to pick up new changes.

References

1. WebLogic Server Domains (WebLogic Server 12c)
2. Integrated WebLogic Server (WLS) (Xml and More)
3. Configuring Fusion Middleware Domains (WebLogic Server 12c)
4. Understanding WLDF Configuration
5. Mining WebLogic Diagnostic Data with XSLT
6. WebLogic: How to Create a WLS Domain? (Xml and More)
7. Diagnosing problems (Fusion Middleware Administrator's Guide, 11g Release 1)
• Note that WLDF does not prevent or stop issues from happening.  It only monitors and captures data for defined conditions and the captured info can be used for troubleshooting.
8. WLDF overhead
• The beauty of the WLDF system is twofold:
• The system gathers data at the lowest level, so impact to gathering that data is minimized
• You can collect only the data that you want by defining data harvesters 
9. Configuring WLDF data storage
10. Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server
11. WLDF: Accessing Diagnostic Data With the Data Accessor