WebLogic Server Configuration Reference

Overview of config.xml

The following sections provide an overview of the WebLogic Server^TM configuration file (config.xml):

About WebLogic Server Management and the config.xml File

WebLogic Server management and configuration services are based on the Java^TM Management Extensions (JMX) API from Sun Microsystems. The config.xml file is a persistent store for the managed objects that WebLogic Server creates and modifies during its executing using the BEA implementation of the JMX API. The purpose of config.xml is to store changes to managed objects so that they are available when WebLogic Server is restarted.

You should normally use the Administration Console to configure WebLogic Server's manageable objects and services and allow WebLogic Server to maintain the config.xml file. Each time you use the Administration Console or other WebLogic Server utilities to modify the config.xml file, WebLogic Server archives the older version. You can configure the number of archived files WebLogic Server keeps. For more information, refer to "WebLogic Server Archives Previous Versions of config.xml" in Configuring and Managing WebLogic Server.

Although config.xml is a well-formed XML document that you can modify using a text editor, you should think of it as a database that you would only directly update under unusual circumstances.

The config.xml file is not a formal XML document with a document type definition (DTD) that can be used to validate its contents. It is truly a repository, where each XML element contains data saved at the request of an in-memory instance of a management object in WebLogic Server. However, the objects that store their data in config.xml are defined within the WebLogic Server Management API and so it is possible to substantially document the contents of the config.xml file. In fact, the reference information in this document is extracted from Javadocs for the weblogic.management.configuration package which contains the WebLogic Server management MBeans. You can see a different view of the same information in the Javadocs and in the Administration Console online help system.

There are cases where config.xml can contain data that is not described in this document:

Some MBean attributes are intentionally not documented because they concern internal mechanisms that are not intended to be exposed and may not be supported in future releases.
MBeans and attributes may be created dynamically by applications executing in WebLogic Server. These applications may include the Administration Console, other BEA products that work with WebLogic Server, and applications supplied by users or third-party vendors.

If you are using other BEA products with WebLogic Server or third-party applications, see the documentation accompanying the other product for additional information about config.xml elements and attributes.

When to Edit config.xml

There are a few instances where you might choose to edit the config.xml file directly instead of using the Administration Console. In these cases, your changes should be minimal and specific. You should not attempt to create a new WebLogic Server configuration by writing a new config.xml file from scratch.

Warning: You cannot edit config.xml while WebLogic Server is executing, since WebLogic Server rewrites the file periodically. Your changes will be lost and, depending on your platform, you could cause WebLogic Server failures.

In all cases, you should make a backup copy of your config.xml file before you make any changes to it.

Here are some situations where it is appropriate to edit config.xml:

If you are deploying several WebLogic Server instances, you can "clone" a config.xml file and edit the values for each new server.
If you have defined an object in one server and want to copy it to another server, you can copy the XML element that defines the object from one config.xml to the other.
To help you correct a problem, BEA Technical Support may suggest that you set an attribute that cannot be set through the Administration Console.
The documentation for a third-party application requires that you modify the config.xml file.

Since config.xml is a well-formed XML file, it is possible to script certain repetitive changes to config.xml using an XML parser application such as Apache Xerces, or JDOM. Be sure to test any scripts you create thoroughly and always make a backup copy of config.xml before you make any changes to it.

Contents of the config.xml File

The config.xml file consists of a series of XML elements. The Domain element is the top-level element, and all elements in the Domain are children of the Domain element. The Domain element includes child elements, such as the Server, Cluster, and Application elements. These child elements may have children themselves.

For example, the Server element includes the child elements WebServer, SSL and Log. The Application element includes the child elements EJBComponent and WebAppComponent.

Each element has one or more configurable attributes. An attribute has a corresponding attribute in the configuration API. For example, the Server element has a ListenPort attribute, and likewise, the weblogic.management.configuration.ServerMBean class has a ListenPort attribute. Configurable attributes are readable and writable, that is, ServerMBean has getListenPort() and setListenPort() methods.

When an attribute references another element in config.xml (such as the SSL attribute of Server), the attribute's value is the value of the referenced element's Name attribute. (All config.xml elements have a Name attribute.) If an attribute references a set or list of other elements, the value of the attribute is a comma-separated list of the referenced elements' names.

All attribute values must be quoted. Boolean attributes are either "true" or "false". Attributes with numeric values are written as quoted strings of digits and symbols that can parsed into the specified destination data type. For example, integer values must not contain commas or decimal points, but may have a leading minus sign if the attribute allows a negative value.

Editing the config.xml File

BEA recommends that you use the Administration Console to modify or monitor a domain configuration. You can also modify the config.xml file in the following ways:

The WebLogic Server Application Programmatic Interface (API) allows other programs to modify configuration attributes of resources in the domain.
You can access the attributes of a domain with the WebLogic Server command-line utility. This utility allows you to create scripts to automate domain management.

BEA XML Editor

The BEA XML Editor is a simple, user-friendly tool for creating and editing XML files. The BEA XML Editor can validate XML documents against a DTD or XML Schema. There is no DTD or XML Schema for config.xml, but using the XML editor can at least ensure that you create a well-formed XML document that WebLogic Server can parse. It cannot, however, verify that you spell element and attribute names correctly and enter valid values for attributes.

See the BEA XML Editor on the BEA dev2dev Online.

Rules for Editing the config.xml File

Consider the following issues before you edit the configuration file manually.

Always save your config.xml file before editing it.

Do not edit the config.xml file for a domain when a domain is active. If you manually edit the configuration file while the domain is active, any changes you make are likely to be overwritten by the system. Furthermore, all manual changes you make while the domain is active are ignored by the system at run time.

Do not change Name attributes of child elements. WebLogic Server requires that the name of a child element match the name of its parent. For example, if the Name attribute of the Server element has the value "myserver", the Name attributes of COM, JTAMigratableTarget, KernalDebug, Log, SSL, ServerStart, SystemDataStore, and WebServer elements that are children of the Server element must also have the value "myserver".

Because no validation or value checking occur while or after you edit config.xml with the command-line utility, type-checking occurs when you load the edited configuration file for the first time, that is, when you restart the domain Server. At that point, any invalid XML or attribute value is detected and the domain fails to boot.