To provide a secure, predictable means for distributing configuration changes in a domain, WebLogic Server imposes a change management process that loosely resembles a two-phase commit database transaction. The following sections describe configuration change management:
The configuration of a domain is represented on the file system by a set of XML configuration files, centralized in the
config.xml file, and at runtime by a hierarchy of Configuration MBeans. When you edit the domain configuration, you edit a separate hierarchy of Configuration MBeans that resides on the Administration Server. To start the edit process, you obtain a lock on the edit hierarchy to prevent other people from making changes. When you finish making changes, you save the changes. The changes do not take effect, however, until you activate them, distributing them to all server instances in the domain. When you activate changes, each server determines whether it can accept the change. If all servers are able to accept the change, they update their working configuration hierarchy and the change is completed.
Note that WebLogic Server's change management process applies to changes in domain and server configuration data, not to security or application data.
Some configuration changes can take effect on the fly, while others require the affected servers to be restarted before they take effect. Configuration changes that can take effect without a server restart are sometimes referred to as dynamic changes; configuration changes that require a server restart are sometimes referred to as non-dynamic changes. In the Administration Console, an attribute that requires a server restart for changes to take effect is marked with this icon:
Edits to dynamic configuration attributes become available once they are activated, without restarting the affected server or system resource. These edits are made available to the server and runtime hierarchies once they are activated. Edits to non-dynamic configuration attributes require that the affected servers or system resources be restarted before they become effective.
If an edit is made to a non-dynamic configuration setting, no edits to dynamic configuration settings will take effect until after restart. This is to assure that a batch of updates having a combination of dynamic and non-dynamic attribute edits will not be partially activated.
As described inin Overview of WebLogic Server System Administration, you can use a variety of different WebLogic Server tools to make configuration changes:
Whichever tool you use to make configuration changes, WebLogic Server handles the change process in basically the same way.
For more detailed information about how configuration changes are carried out through JMX and Configuration MBeans, seein Developing Custom Management Utilities with JMX. For more detailed information about making configuration changes with WLST, see in WebLogic Scripting Tool.
Using the WebLogic Auditing provider or another auditing security provider, you can record audit information about changes made to your WebLogic Server configuration. Seein Securing WebLogic Server.
The WebLogic Administration Console centralizes the configuration change management process in the Change Center pane:
If you want to use the Administration Console to make configuration changes, you must first click the Lock & Edit button in the Change Center. When you click Lock & Edit, you obtain a lock on the editable hierarchy of Configuration MBeans for all servers in the domain (the edit tree).
As you make configuration changes using the Administration Console, you click Save (or in some cases Finish) on the appropriate pages. This does not cause the changes to take effect immediately; instead, when you click Save, you are saving the change to the edit tree and to the
/pending/config.xml file and related configuration files. The changes take effect when you click Activate Changes in the Change Center. At that point, the configuration changes are distributed to each of the servers in the domain. If the changes are acceptable to each of the servers, then they take effect. (Note, however, that some changes require a server to be restarted.) If any server cannot accept a change, then all of the changes are rolled back from all of the servers in the domain. The changes are left in a pending state; you can then either edit the pending changes to resolve the problem or revert the pending changes.
Configuration changes happen in basically the same way, regardless of the JMX tool you choose to use (the Administration Console, WLST, or JMX APIs). The following steps describe the process in detail, starting from when you first boot the domain's Administration Server:
config.xmlfile and any subsidiary configuration files referred to by the
config.xmlfile and uses the data to instantiate the following MBean trees in memory:
|Note:||The Administration Server also instantiates a Runtime MBean tree and a DomainRuntime MBean tree, but these are not used for configuration management.|
config.xmlfile, using the Save button in the Administration Console; using the WLST
savecommand; or using the
saveoperation on the
pending. See Figure 4-2.
pending directory is immediately below the domain's root directory. For example, if your domain is named
mydomain, then the default pathname of the pending
config.xml file is
activatecommand; or using the
activateoperation on the
When you activate changes (see Figure 4-3):
pendingdirectory in the server's root directory.
If a Managed Server shares its root directory with the Administration Server,
ConfigurationManagerMBean does not copy the pending configuration files; the Managed Server uses the Administration Server's pending file.
If any subsystem indicates that it cannot consume the changes, the entire activation process is rolled back and the
ConfigurationManagerMBean emits an exception. You can modify your changes and retry the change activation, or you can abandon your lock, in which case the edit Configuration MBean tree and the pending configuration files are reverted to the configuration in the read-only Configuration MBean tree and configuration files.
on each server instance in the domain with the pending configuration files.
When you start an edit session, whether you use the Administration Console, WLST, or the Management APIs, you obtain a lock on the Configuration MBean edit tree.
The configuration change lock does not by itself prevent you from making conflicting configuration edits using the same administrator user account. For example, if you obtain a configuration change lock using the Administration Console, and then use the WebLogic Scripting Tool with the same user account, you will access the same edit session that you opened in the Administration Console and you will not be locked out of making changes with the Scripting Tool. You can reduce the risk that such a situation might occur by maintaining separate administrator user accounts for each person with an administrative role. Similar problems can still occur, however, if you have multiple instances of the same script using the same user account.
To reduce further the risk of this situation, you can obtain an exclusive configuration change lock. When you have an exclusive configuration lock, a subsequent attempt to start an edit session by the same owner will wait until the edit session lock is released. To obtain an exclusive configuration lock using WLST, use
true for the exclusive argument in the
wls:/mydomain/edit> startEdit(60000, 120000, true)
To obtain an exclusive configuration lock using the Management API, use
true for the exclusive parameter in the
Object  startEdit(60000, 120000, true)
You cannot modify the domain configuration using the compatibility MBean server when either of the following is true:
For information about the compatibility MBean server, which is used with the deprecated
weblogic.management.MBeanHome interface, see in Developing Custom Management Utilities with JMX.
In the event that you have saved more than one change set without activating them and one change would invalidate a prior change, the Change Management service requires you to manually resolve the invalidation before it will save your changes.
The Configuration Management service follows a series of states, which are described in Figure 4-4.
You can block configuration changes by setting a domain to be read-only. Do this by setting the
EditMBeanServerEnabled attribute of the
JMXMBean configuration MBean to false, using either WLST or the Management APIs.
Note that once you have set your domain to be read-only, you can no longer edit its configuration using the Administration Console, WLST online, or the Management APIs. To make the domain editable again, you must either edit the
config.xml file directly in a text editor, or use WLST offline, and then restart the affected servers.
You should also establish appropriate access controls to the domain's configuration, limiting access to users with the proper security roles. In addition, using the WebLogic Auditing provider or another auditing security provider, you can record audit information about changes made to your WebLogic Server configuration. Seein Securing WebLogic Server.