WebLogic Chinese Document

Chapter 1 Introduction and guidance

This document describes the WebLogic Server domain and how to configure the domain. The domain is the basic management unit of WebLogic Server. A domain can contain one or more WebLogic Server instances and related resources. You only need to use an Administration Server for management.

The following sections describe the content and structure of this Guide-Understanding domain configuration.

Document Scope and readers

Document wizard

Related Documents

Examples and guide

New Domain features in the released version

 

Document Scope and readers

This document is applicable to J2EE system architects, application developers, and system administrators who develop and deploy Web applications based on one or more WebLogic Server domains.

The topic of the document is only relevant to the design and development phases of software projects, and does not involve product process management, monitoring, or performance adjustment. For the Weblogic server documentation and resource links for these topics, see "related documentation ".

This document assumes that the reader is familiar with the basic concepts of J2EE and XML and the general concepts of application management.

Document wizard

This chapter describes the purpose, structure, and context of the guide.

Chapter 2 "Understanding the WebLogic Server domain" describes the WebLogic Server domain.

Chapter 3 "using weblogic tool to configure domains" shows several tools you can use to modify domain configurations.

Chapter 4 "Domain Configuration File" describes the disk representation configuration and directory for maintaining the domain and domain content.

Chapter 5 "Managing configuration changes" describes how to change the management features of WebLogic Server.

Related Documents

For more information about the tools used to create and configure the WebLogic Server domain, see:

Use the Configuration Wizard to create a WebLogic domain

WebLogic script Tool

Deploy manageable applications using JMX

WebLogic Server command reference

Management Console online help

For more information about other system management tasks, see system management documents, especially:

Design and configure the WebLogic Server Environment

Use WebLogic Server Cluster

Examples and Wizard

BEA System provides the following code examples and guidelines for domain configuration and management:

The example of BEA WebLogic Server is installed (optional) in the wl_home/samples/Server/examples/src/examples directory. wl_home is the top-level directory for installing WebLogic Server, these examples can also be used in the Windows Start Menu. The cluster example is described in the BEA WebLogic Server Cluster guide example to guide you through the entire process of creating and configuring a new server instance cluster using the Weblogic Configuration Wizard and the management console.

New Domain features in this version

WebLogic Server 9.0 introduces several important changes in WebLogic Server Domain Configuration:

XML schema of config. xml

Domain directory structure

Configuration change management

XML schema of config. xml

The disk format of the WebLogic Server domain and instance configuration is different in this version. In the original version, the configuration information is saved in the config. xml file of a single XML repository, which is in the user_projects/domains/domain_name directory by default. In this version of Weblogic server, the config. xml file complies with the XML schema definition (used to verify the validity of the domain configuration file format ). In addition, config. xml integrates the configuration information of other configuration files (in accordance with their XML Schema. In this version, config. XML is in the user_projects/domains/domain_name/config directory by default, config. the auxiliary configuration file involved in the XML Core File is located in the subdirectory of user_projects/domains/domain_name/config. For more information, see Chapter 4 "Domain Configuration File ".

Domain directory structure

In this version, the directory structure of the WebLogic Server domain on the disk has changed. The parent directory of the domain is named domains. The domain configuration information is stored in the domains/domain_name/config directory and the config directory subdirectory. For more information, see "Domain directory content ".

Configuration change management

WebLogic Server provides some new features to manage service configuration changes, which allows you to securely and intelligently distribute configuration changes for a specific domain. Of course, this requires you to obtain the Administrator console lock before using the console for configuration changes.

The change management process in WebLogic Server is similar to that in database transactions. The Management Server maintains an independent, editable domain configuration representation, called the editing layer. The server instance does not involve the editing layer. On the contrary, server instances use the read-only layer to discover configurations. To enable the editing process, you should be able to get a lock at the editing layer to prevent others from making changes. After you complete the changes, you save and distribute them to all server instances in the domain. After the distribution is complete, each server determines whether to accept the change. Once all servers accept the change, the configuration layer of the update operation is complete.

The current console includes a region named Change Center. When you use the console for configuration change, you must first obtain the lock by clicking lock & make changes (lock and change) in the Change Center. After the expected configuration change, you can go to the Change Center:

Click Activate changes to accept the changes and distribute the changes to the sever instance in the domain, or

Click undo all changes (undo all changes) to release the lock.

WebLogic Server generally controls configuration changes in the same way, whether implemented on the Management Console, WebLogic script tools, configuration management services, or JMX APIs.

For more information, see Chapter 5 "Managing configuration changes ".

Chapter 2 Understanding WebLogic Server domain

The following sections describe the WebLogic Server domain and domain:

What is a domain?

Organization domain

Domain content

Domain Constraints

What is a domain?

A Weblogic server management domain is a logical WebLogic Server Resource Group. The domain includes a special Weblogic server instance called the Administration Server, which is the key to configuring and managing all resources in the domain. Generally, a domain you configure will be added to another Weblogic server instance, called a managed server ). Your web applications, ejbs, and other resources are deployed on managed servers, which are only used for configuration and management.

Multiple managed servers can be organized into clusters, which enables you to maintain load balancing and provide Failure Protection for critical applications, at the same time, using only one management server simplifies the management of managed server instances.

Organization domain

How to organize WebLogic Server devices into domains depends on your business needs. You can define multiple domains based on the responsibilities of the system administrator, application boundaries, or the geographical location where the server runs. In contrast, you can also decide to centralize all WebLogic Server Management Behaviors in one domain.

Based on your specific business needs and system management practices, you can determine how to organize your domain according to the following criteria:

Application logic differentiation. For example, you can use one domain for end-user functions similar to shopping cart, and the other domain for background accounting.

Physical location. You can create domains for different geographical locations and branches of your business.

Size. You will find that the domain is organized into smaller units, which may make the management efficiency of different system administrators more efficient. On the contrary, you will also find that maintaining a single domain or a small number of domains makes it easier to maintain consistent configurations.

A domain is composed of one management server and one or more managed servers. It can also be composed of only one isolated server, playing both the role of a management server and resident applications.

A domain composed of distributed hosting servers: A simple product environment consists of several hosting servers hosting applications and one management server that executes management operations. In this configuration, applications and resources are deployed on their respective hosting servers. Similarly, clients accessing applications are connected to their respective hosting servers.

If the product environment requires enhanced application performance, throughput, or availability, configure two or more hosting servers as clusters. A cluster allows multiple hosted servers to reside in applications and resources as a single individual. For more information about the differences between isolated and cluster-hosted servers, see "managed servers and managed Server Clusters ".

Isolated server domain: For a development or test environment, you may want to deploy a single application and server independent of the server in the product domain. In this case, you can deploy a simple domain consisting of only a single server instance, which serves as both a Management Server and an application that you develop. The wl_server domain installed with WebLogic Server is an example of an isolated server domain.

Note: In the product environment, Bea recommends that you only deploy applications on hosted servers in the domain. The Management Server is only responsible for management tasks.

Domain content

Although the scope and purpose of the domain are quite different, most WebLogic Server domains contain the components described in this section.

The product environment is displayed, including a Management Server, three isolated managed servers, and a cluster composed of three managed servers.

Manage servers

Each WebLogic Server domain must have a server instance as the management server. You can use a Management Server (programmed or managed server) to configure all other server instances and resources in the domain.

Manage Server roles

Before starting the domain hosting server, you should start the management server. When you start an isolated or cluster-hosted server, it is connected to the Management Server according to the configuration information. In this way, the management server acts as the core control body in the entire domain configuration.

When the Management Server is started, load the config. xml file of the domain, unless you specify another directory to store config. xml when creating the domain.

Bea_home/user_projects/domains/mydomain/config

Here, mydomain is the directory of a specific domain with the same name as the domain. Other configuration files referenced by config. XML are located in the subdirectory of the config directory of the domain.

Each time the Management Server is successfully started, a backup profile named config-booted.jar is created in the domain directory. If the configuration file is damaged during the lifecycle of the server instance, the original configuration may be restored.

What will happen if an error occurs on the management server?

Domain Management Server errors do not affect the operations of hosted servers in the domain. If the Domain Management Server becomes unavailable and the server instance managed by the domain-cluster or other methods-is still running, the managed servers will continue to run. If the domain contains a cluster server instance, the load balancing and Failure Performance supported by the domain configuration remain available even if an error occurs on the management server. If the domain management server stops running and the managed server continues running, each managed server periodically tries to reconnect to the management server, which is specified by the adminreconnectintervalsecs attribute of servermbean. The default value of adminreconnectintervalsecs is 10 seconds.

If the Management Server fails due to hardware or software errors on the host, other server instances on the same machine may be affected. However, the failure of the Management Server itself will not interrupt the operation of the domain hosting server. Even if the management server is not running, you can start the managed server. In this case, the hosting server uses the local copy of the configuration file as its startup configuration, and periodically tries to connect to the Management Server. After the connection, the Management Server is used to synchronize the configuration status.

For instructions on restarting the Management Server, see "manage server startup and shutdown ".

Managed servers and managed SERVER CLUSTERS

In the domain, the server instance of the non-managed server points to the managed server. Hosting Server resident constitutes the components and related resources of your application, such as JSP and EJB. When a managed server is started, it connects to the domain's Management Server for configuration and deployment settings.

Note: even if the Management Server is unavailable, the managed server in the domain can be started independently of the management server. For more information, see "avoid Server failure and recovery" in "manage server startup and shutdown ".

Two or more managed servers can be configured as a WebLogic Server Cluster to increase application scalability and availability. In WebLogic Server Clusters, most resources and services are evenly deployed to each managed server (opposite to a single managed server) to balance failure and load. To understand which Component Types and services can be deployed in a cluster (deployed to all server instances in the cluster), see "Understanding WebLogic Server Clusters" in "using WebLogic Server Clusters ".

You can create a non-cluster hosting server and add it to the cluster by configuring the server instance and cluster parameters. You can also delete a managed server from the cluster by reconfiguration parameters. The fundamental difference between a cluster and a hosting server is the support for failure and load balancing. These features are only available on the cluster hosting server.

Your Requirements for scalability and reliability determine whether or not you use cluster-managed servers. For example, if your applications do not often experience variable loading and the possible interruptions in the Application Service are acceptable, there is no need to use a cluster.

For more information about the benefits and performance of WebLogic Server Clusters, see "Understanding WebLogic Server Clusters" in "using WebLogic Server Clusters ". A single domain can contain multiple WebLogic Server clusters, and multiple hosted servers can be not configured as clusters.

Resources and Services

In addition to managing servers and hosting servers, the domain also includes the resources and services required for hosting servers and applications deployed on this domain.

The domain configuration includes information about the network computer environment in which the domain runs, for example:

Machine positioning is identified by a specific physical segment on the hardware. Machine locating is used to associate computers that reside on hosted servers. The Node Manager restarts an error hosting server. The hosting server of the cluster is used when the best location for storing duplicate session data is selected. For more information about Node Manager, see "use Node Manager to control servers" in "design and configure Weblogic server environment ".

Network Channel, an optional resource that can be used to define the default port, protocol, and protocol settings. After creating a network channel, you can allocate it to any hosting server and cluster in the domain. For more information, see "configure network resources" in "design and configure Weblogic server environment ".

The domain configuration also includes the resources and service information related to the applications that reside in the domain. Examples of these resources and services include:

Application components, such as EJB

Connector

JDBC connection pool

JMS Server

Startup class

Resources and Services may be restricted to one or more hosting servers in the domain, rather than being available for the entire domain. You can choose to host servers or clusters to deploy resources and services.

Domain Constraints

The Weblogic server environment can be composed of a single domain, including all the hosted servers required to reside the application, or multiple domains. You can create multiple domains based on the organization unit, system administrator's responsibilities, application boundaries, and other considerations. When designing domain configurations, pay attention to the following constraints:

Each domain requires its own management server to perform management operations. When you use the console to perform management and monitoring tasks, you can switch back and forth in the domain and connect to different management servers.

All hosting servers in the same cluster must be located in the same domain. You cannot split the cluster into multiple domains.

All managed servers in the same domain must run the same WebLogic Server software version. The management server in the domain can run the same version or an updated version as the hosting server.

You cannot share configuration resources and subsystems in the domain. For example, if you create a JDBC connection pool in a domain, you cannot use it in a hosted server or cluster in another domain. Instead, you must create a similar connection pool in the second domain.

Chapter 3 use the Weblogic tool to configure the domain

WebLogic includes a series of tools you can use to create, modify, or copy domain configurations. Includes the following tools:

Domain Configuration Wizard-The Domain Configuration Wizard is a recommended tool for creating a new domain or cluster. For more information about using the Domain Configuration Wizard, see "using the Configuration Wizard to create a WebLogic domain ".

Weblogic server console-the Management Console is a graphical user interface (GUI) for managing servers ). For details about the console, see "console online help ".

WebLogic script tool (wlst)-You can use the command line script interface to create, manage, and maintain Weblogic server configuration changes. For the Weblogic script tool description, see "WebLogic script tool ".

WebLogic Server application programming interface (API)-You can use the API provided by Weblogic server to write programs to modify configuration attributes. For the jmx api description, see "Developing manageable applications using JMX ".

WebLogic Server command line tool-this tool allows you to create scripts for automatic domain management. For more information about the tool, see "WebLogic Server command reference ".

In most cases, the management server that modifies the domain configuration domain must run. However, if you use wlst for domain configuration changes, you do not need to run the management server. In this case, the changes caused by wlst will not take effect immediately until the Management Server and hosting server restart.

Chapter 4 Domain Configuration File

This topic describes how to represent a domain in a file system. It includes the following parts:

Configuration File Overview

Config. xml

Domain Directory Overview

Domain directory content

Domain Configuration File Overview

WebLogic Server Management and Configuration Services are accessed through Java Management extension (JMX) APIs. The domain configuration is saved in the configuration directory under the domain directory. The files in these configuration directories are used to persistently store managed objects created and modified by Weblogic server during jmx api running. Config. XML is used to store changes to managed configuration objects so that WebLogic Server can be accessed upon restart.

The core configuration file of the domain is the domain_name/config. xml file. It specifies the domain name and configuration parameters for each server instance, cluster, resource, and service in the domain. Some major Subsystem Configurations of the domain are saved in the subdirectory of the domain_name/config directory.

The domain directory also contains the default script files that you use to start the domain management server and the hosting server.

Config. xml

The core configuration file of the domain is/domains/domain_name/config. xml. It specifies the domain name and configuration parameters for each server instance, cluster, resource, and service in the domain.

The config. xml file conforms to the XML schema. The URL is http://www.bea.com/ns/weblogic/config. Schema is located in the jar file bea_home/weblogic90/Server/lib/Schema/configuration-binding.jar in the file system, that is, the META-INF/schemas/schema-0.xsd. The XML editing tool can use XML schema to modify and verify the config. xml file.

Edit configuration file

In most cases, you should not directly modify config. for XML or other configuration files, you should use the console or use a tool listed in Chapter 3 "use WebLogic tool configuration domain" to modify the domain configuration. Configuration changes will be mapped to the configuration file.

If you choose to place the configuration file, it may be appropriate to directly modify the configuration file if other components installed are under source control (managed using wlst.

Warning you cannot edit the configuration file when Weblogic server is running, because WebLogic Server will periodically overwrite the file. Your changes will be lost and may cause WebLogic Server failure, depending on your platform.

Weblogic server configuration file is a format-friendly XML file, so it may use XML parsing applications such as Apache xerces, or JDOM to implement a repetitive change script.

Make sure that the script created in the complete test is backed up and copied to each configuration file before the change is made.

Auxiliary configuration file

In the original version, the config. xml file stores all configuration information. In the new version, several WebLogic Server subsystems are configured in the auxiliary configuration file and referenced by the core config. xml. These auxiliary configuration files are located in the subdirectory of the/domains/domain_name/config directory. For more information about the auxiliary configuration file, see "Domain Directory Overview" and "Domain directory content ".

Configuration file compressed package

WebLogic Server backs up and copies configuration files. In case of a configuration change that requires re-engineering or destruction of the configuration file (which is unlikely to happen), this makes the recovery easy. When the Management Server is started, it saves the configuration file in a jar file named config-booted.jar. When you change the configuration file, the old file is saved as a jar file in the configarchive directory under the domain directory, named as a sequence of numbers, such as config-1.jar.

Domain Directory Overview

Figure 4-1 shows an overview of the tree structure of the domain directory. The domain-name, deployment-name, and server-name directory names are not literally displayed. They can be replaced with any specified name. Other directory names are literally displayed. The overview only displays directories, excluding files in directories. The entire structure of any actual directory tree in a specific domain may not be like this.

Domain directory content

This section describes the contents of the domain directories and subdirectories. The directory names in italics are not the actual names, but should be replaced by appropriate names, A non-italic name is a literal name.

Domain-Name

The directory name is the name of the domain.

Applications

This directory provides a quick way to deploy applications on the Deployment Server. When the Weblogic server instance runs in development mode, it will automatically deploy any applications and modules you place in this directory.

The files you put in the directory can be:

A J2EE Application

An ear File

A compression module for war, EJB jar, rar, or car

Decompress the directory of an application or module

Bin

This directory contains scripts used to start or stop the Management Server and host server processes in the domain. It can also include some other domain scripts in the broad sense, such as scripts for starting and terminating the database management system and full-text search engine processes. For more information, see manage server startup and termination.

Config

This directory contains the current configuration and deployment status of the domain. The core domain configuration file config. XML is located in this directory.

Config/deployments

Save the directory where the application is deployed in the domain.

Config/deployments/library_modules

Save the directory of the class library module, that is, any files in the directory will be automatically registered with the class library module.

Config/deployments/deployment-name-1

This directory contains an application or a publishable module. Its Sub-directories can contain a compressed file (ear or war), a deployment list, extended descriptor, and so on.

Config/diagnostics

This directory contains the Weblogic diagnostic service system module. For more information, see "Understanding WebLogic diagnostic service ".

Config/jdbc

This directory contains JDBC system modules: All JDBC modules can be configured directly through JMX (different from JSR-88 ). For more information, see "database connection (JDBC )".

Config/JMS

This directory contains the JMS system module: All JMS modules can be directly configured through JMX. For more information, see "JDBC )".

Config/nodemanager

This directory stores the configuration information connected to the Node Manager. For more information, see "use Node Manager Management Service" in "design and configure Weblogic server environment ".

Config/security

This directory contains the security framework system module. Includes Security Configuration extensions for each security provider of the current domain. For more information, see "Weblogic Security ".

Config/startup

This directory contains the system modules that contain the startup plan. The startup plan is used to generate shell scripts as part of server startup.

Configarchive

This directory contains a set of jar files used to save the domain configuration status. The current configuration status of the domain, including config. the XML file and other related files are saved in the jar file with the version number and named config. jar #1, config. jar #2 and so on.

The maximum number of jar files with version numbers is specified by the archiveconfigurationcount attribute of domainmbean. Once the maximum number is reached, delete the oldest version before the new version is created.

Lib

Any jar files in this directory will be added to the system classpath of each server instance in the domain when the Java Virtual Machine of sever starts.

Pending

The domain configuration file in this directory indicates that the request has been made, but no configuration changes have been activated. Once the configuration change is activated, the configuration file in this directory will be deleted. For more information, see "manage configuration changes ".

Security

The security-related files stored in this directory are the same for every Weblogic server instance in the domain.

Serializedsystemini. dat

This directory also saves only the security-related files required by the Domain Management Server:

Defaultauthorizerinit. ldift

Defaultauthenticatorinit. ldift

Defaultrolemapperinit. ldift

For more information, see "Understanding Weblogic Security ".

Servers

This directory sets a sub-directory for each Weblogic server instance in the domain.

Servers/Server-name

The directory is the server directory, and the name is the same as that of the Weblogic server instance.

Servers/Server-name/bin

This directory stores executable or shell files, which may vary with servers. Server Environment script (setserverenv. sh or setserverenv. CMD) is a file example here, because it can distinguish a Weblogic server instance from the next instance, depending on whether the server instance has its own startup plan.

Servers/Server-name/Cache

This directory stores directories and files that contain cached data. Here, "cached" indicates that the data is a copy of other data, which may be in the form of a process (compiled, translated, or reformatted ).

Servers/Server-name/Cache/ejbcompilercache

This directory is the compiled EJB cache.

Servers/Server-name/Data

Contrary to temporary, cached, or historical information, the files stored in this directory maintain a persistent pre-service status, rather than a security status, and are used to run WebLogic Server instances. Files in this directory are very important and must exist at the beginning of the Weblogic server instance, stop, crash, restart, or upgrade to the new version.

Servers/Server-name/data/ldap

This directory stores the embedded LDAP database. The security status of the Weblogic server instance persists in this directory.

Servers/Server-name/data/Store

This directory stores JMS persistent storage. For each persistent storage, there is a subdirectory for storing objects that represent persistent storage. The subdirectory name is the name of persistent storage. In this example, a bucket is named "default.

Servers/Server-name/logs

This directory stores logs and diagnostic information. In fact, it is only some historical information. It is not crucial for the server to run. It can be deleted (but at least the Weblogic server instance should be terminated) without affecting the correct operation. However, this information is useful for debugging and checks and should not be deleted if there is no good reason.

Servers/Server-name/logs/diagnostic_images

This directory stores the information created by the server Image Capture Component of the Weblogic diagnostic service. For more information, see "Understanding WebLogic diagnostic service ".

Servers/Server-name/logs/jmsservers

This directory provides a sub-directory for each JMS service in the Weblogic server instance. Each subdirectory contains the logs of the JMS service. The subdirectory name is the name of the JMS service.

Servers/Server-name/logs/connector

This directory is the default base directory for the connector module (JCA resource adapter) logs.

Servers/Server-name/security

This directory Stores security-related files. Each Weblogic server instance may be different. The file boot. properties is a file example located here, because it can distinguish a server instance from the next instance. This directory also maintains files related to the SSL Key.

Servers/Server-name/tmp

This directory stores the temporary directories and files created when the server instance is running. Files in this directory should be retained when the server is running, but can be deleted after the server instance is terminated.

Chapter 5 manage configuration changes

To provide a secure and predictable way to distribute domain configuration changes, Weblogic server adopts a change management process similar to database transactions. Domain Configuration is represented as a set of xml configuration files in the file system. The core is the config. xml file, and the configuration mbeans tree is represented at runtime. When you edit the domain configuration, you actually edit the mbeans tree of the isolated management server. To start the editing process, you should get the lock of the editing tree to prevent others from making changes. After the change is completed, save the change. However, the changes will not take effect until you activate them and distribute them to all server instances in the domain. After the change is activated, each server determines whether to accept the change. If all servers can accept the change, update the running configuration layer and the change is complete.

Note that the change management process of WebLogic Server applies to domain changes and server configuration data, and does not apply to security or application data.

For more information about how to implement configuration changes through JMX and mbean, see "Understanding WebLogic Server mbeans" in "Developing manageable applications using JMX"

As described in Chapter 3 "using weblogic tool to configure domains", you can use a series of different WebLogic Server tools for configuration changes:

Management Console

WebLogic script Tool

JMX API

Regardless of the tool you use for configuration change, Weblogic server uses the same method to handle the change process.

The following sections describe configuration change management:

Management Console change management

Configuration change management process

Configuration Management status chart

Management Console change management

The WebLogic console centralizes the configuration change management process on the Change Center:

If you want to use the console for configuration change, you must first click lock & edit (lock and edit) in the Change Center. After you click lock & edit, you will get the locks for the Editable layer (edit tree) of configuration mbeans for all servers in the domain.

After you use the console to perform configuration changes, click Save on the appropriate page (in some cases, finish). These changes do not take effect immediately, when you click Save, the changes are saved to the editing tree, domain-name/pending/config. XML file and related configuration files. The change takes effect only when you Click Activate changes (activation change) in the Change Center. configuration changes are distributed to every server in the domain. Only when each server accepts the change will the change take effect. If any server does not accept the change, all the changes to all servers in the domain will be rolled back. Changes remain in the pending status. You can edit the pending changes to solve the problem or restore the pending changes.

Configuration change management process

Follow these steps to describe the process in detail, starting from importing the domain's Management Server:

1. When the server starts, it reads the domain configuration file, including all the ancillary configuration files involved in the config. xml file and config. xml file, and uses the data to instantiate the subsequent mbean tree:

-A read-only tree for mbean configuration contains the current resource configuration of the management server.

-Editable tree for all mbean configurations for all servers in the domain.

Note: The management server will also instantiate a runtime mbean tree and a domain runtime mbean tree, but these are not used for configuration management.

2. Follow these steps to start configuration change:

A. Obtain the current configuration lock.

B. Use the tool you selected (Management Console, wlst, JMX API, etc.) to change as required.

C. Save the changes to the pending versions of the config. xml file.

3. The Configuration Manager Service saves all data from the edit mbean tree into an independent configuration file named pending. See Figure 5-2.

The pending directory is directly located in the root directory of the domain. For example, if your domain is named mydomain, the default path name of the pending config. xml file is mydomain/pending/config. xml.

4. make other changes or cancel the changes.

5. When you are about to activate a domain change, use the activate Changes button of the change center on the management console or the configurationmanagermbean.

Activation change (see Figure 5-3 ):

A. For each server instance in the domain, the Configuration Manager Service copies the pending configuration files to the pending directory under the root directory of the server.

If the hosting server and Management Server share the root directory, the configurationmanagermbean does not have to copy the pending configuration files, and the hosting server directly uses the pending files of the management server.

B. Each server instance compares its current configurations with those in the pending files.

C. Each subsystem inside the server will vote on whether it can accept the new configuration.

Only one subsystem means that it cannot accept the change. The entire activation process will be rolled back, And the configurationmanagermbean throws an exception. You can modify the changes, activate the changes again, or discard the lock, edit the configuration mbean tree and the pending configuration file, and restore the configuration to the configuration of the read-only configuration mbean tree and configuration file.

D. If all subsystems of all servers can accept the change, the Configuration Manager Service replaces the read-only configuration file of each server instance in the domain with the pending configuration file.

E. Every server instance will update the bean and the read-only configuration mbean tree to make the changes to the new configuration file consistent.

F. Then the pending configuration files are deleted from the pending directory.

6. You can keep the lock for other changes or release the lock so that others can update the configuration. You can also set a timeout period so that the Configuration Manager Service will discard the lock.

Note: The configuration change lock does not prevent configuration editing conflicts caused by using the same administrator account. For example, if you use the management console to obtain the configuration change lock and use the Weblogic script tool with the same user account, you will access the same edit session opened on the Management Console, you will not be locked because you use the script tool. This may cause configuration change chaos and conflicts, which is not a recommended method. You should maintain an independent Administrator account for each administrator identity to reduce the risks caused by this situation. However, if you have multiple identical script instances using the same user account, the same problem still occurs,

Handle change conflicts

In this case, multiple changes you save are not activated, and a change will invalidate the previous change. The change manager service requires you to manually solve the invalid problem before saving the change.

Configuration Management status chart

The Configuration Management Service follows the status transition described in Figure 5-4.