weblogic中文文档——domain_config

第一章介绍与导览

本文描述Weblogic Server的域以及如何配置域。域是WebLogic Server的基本管理单元。一个域可以包括一个或多个WebLogic Server实例以及相关资源，只需使用一个Administration Server进行管理。

以下章节描述该指南的内容与结构——理解域配置。

文档范围与读者

文档向导

相关文档

关于用于创建和配置Weblogic Server域的工具的更多信息，参见：

使用配置向导创建WebLogic域

WebLogic脚本工具

使用JMX部署可管理的应用

WebLogic Server命令参考

管理控制台在线帮助

关于其他系统管理任务的信息，参见系统管理文档，尤其是：

设计和配置WebLogic Server环境

使用WebLogic Server集群

示例和向导

BEA系统公司为本文档提供了和域配置、管理相关的以下代码示例和指南：

BEA WebLogic Server的示例安装（可选）于目录WL_HOME/samples/server/examples/src/examples，WL_HOME是你安装WebLogic Server的顶级目录，这些示例也可以通过Windows开始菜单使用。集群示例会在BEA WebLogic Server集群指南示例中描述，指导你掌握使用WebLogic配置向导和管理控制台来创建和配置一个新的server实例集群的整个过程。

本版中新的域特性

Weblogic Server 9.0在Weblogic Server域配置中引入了几项重要变化：

config.xml的XML Schema

域目录结构

配置变更管理

config.xml的XML Schema

WebLogic Server域和实例配置的磁盘表现形式在本版本中有所不同。在原版本中，配置信息被保存在单个XML仓库文件config.xml中，默认位于user_projects/domains/domain_name目录下。在本版的WebLogic Server中，config.xml文件符合XML Schema定义（用来验证域配置文件格式的有效性）。而且，config.xml融合了其他配置文件（符合各自的XML Schema）的配置信息。在本版中，config.xml默认位于user_projects/domains/domain_name/config目录下，config.xml核心文件涉及的辅助配置文件位于user_projects/domains/domain_name/config目录的子目录中。更多信息，参见第四章“域配置文件”。

域目录结构

本版中，Weblogic Server域在磁盘上的目录结构有了改变。域的父目录命名为domains。域的配置信息保存在domains/domain_name/config目录和config目录的子目录中。更多信息，参见“域目录内容”。

配置变更管理

WebLogic Server提供了一些新特性用来管理服务配置变更，这使你可以安全、可预知地实现分发某个域的配置变更。当然这要求你在使用控制台进行配置变更前获得管理员控制台锁。

The change management process in WebLogic Server loosely resembles a database transaction. The Administration Server maintains a separate, editable representation of the domain’s configuration, which is referred to as the edit hierarchy. Server instances do not refer to the edit hierarchy. Instead, server instances use a read-only hierarchy to discover their configuration. 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 and distribute them to all server instances in the domain. When you distribute 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.WebLogic Server中的变更管理过程大致类似于数据库事务。管理服务器维护一个域配置的分离、可编辑的表示，指向编辑层。server实例并不指向编辑层。相反，server实例使用一个只读层发现配置。为了开始一个编辑过程，你可以获得编辑层锁以防止其他人更改。当你完成更改后，你保存并将其分发至域中的所有server实例。当你分发完后，每一个server决定是否接受变更。如果所有的server都能够接受该变更，它们更新工作配置层，变更完成。

现在的管理控制台包括一个名为Change Center（变更中心）的区域。当你使用管理控制台进行配置变更时，你必须首先通过点击Change Center的Lock & Make Changes（锁且变更）获得锁。进行期望的配置变更以后，然后可以在Change Center：

点击Activate Changes（激活变更）接受更改，向域中的sever实例分发，或者

点击Undo All Changes（撤销所有变更），释放锁。

WebLogic Server一般采用相同方式控制配置变更，无论变更是使用管理控制台实现，还是WebLogic 脚本工具、配置管理服务或者JMX API。

更多信息，参见第五章“管理配置变更”。

第二章理解Weblogic Server域

以下章节介绍Weblogic Server域和域的内容：

域是什么

组织域

域的内容

域约束

域是什么？

一个Weblogic Server管理域是逻辑上相关的Weblogic Server资源组。域包括一个特殊的Weblogic Server实例，叫做管理服务器（Administration Server），这是你配置和管理域的所有资源的关键。通常，你配置的一个域会加入另外的WebLogic Server实例，叫作托管服务器（Managed Server）。你的Web应用、EJB和其他资源会部署在托管服务器上，而管理服务器只是用于配置和管理。

多个托管服务器可以组织成集群（clusters），这使你能够保持负载平衡和对于临界的应用提供失败保护，同时只使用一个管理服务器会使托管服务器实例的管理变得简单。

组织域

如何将WebLogic Server装置组织成域，这取决于你的业务需求。你可以基于系统管理员职责、应用边界或者server运行的地理位置的不同定义多个域。与之相反，你也可以决定将所有WebLogic Server管理行为集中于一个域。

根据你特定的业务需求和系统管理实际，你可以按照如下标准决定如何组织你的域：

应用的逻辑区分。比如，你可以有一个域用于类似购物车的终端用户功能，另一个域用于后台记账。

物理位置。你可以为业务的不同地理位置和分支分别建域。

大小。你会发现域被组织成更小的单元可能会使不同的系统管理员管理效率更高。反之，你也会发现维护单个域或者少量的域，配置更容易保持一致。

一个域由一个管理服务器和一个或多个托管服务器组成，也可以只由单个孤立的server组成，既扮演管理服务器的角色又驻留应用。

由分散的托管服务器组成的域：简单的产品环境由几个驻留应用的托管服务器，一个执行管理操作的管理服务器组成。在这种配置下，应用和资源部署在各自的托管服务器中；类似地，访问应用的客户端与各自的托管服务器连接。

如果产品环境对增强应用性能、吞吐量或者可用性有要求，那么应该将两个或者更多的托管服务器配置成集群。机群允许多个托管服务器作为单个个体驻留应用和资源。关于在孤立的和集群托管服务器之间差异的更多信息，参见“托管服务器和托管服务器集群”。

孤立的server域：对于开发或测试环境而言，你可能想在部署单个应用和server独立于产品域中的server。这种情况下，你可以部署一个简单域，只由单个server实例组成，既作为管理服务器，又驻留你开发的应用。你用WebLogic Server安装的wl_server域就是一个孤立server域的例子。

注意：在产品环境中，BEA建议你只在域中的托管服务器部署应用，管理服务器应当只负责管理任务。

域的内容

尽管域的范围与目的会有很大差异，但是大多数 WebLogic Server域都包含本章节中描述的组件。

下图展示了产品环境，包括一个管理服务器，三个孤立的托管服务器和三个托管服务器组成的集群。

管理服务器

每个Weblogic Server域都必须有一个server实例作为管理服务器。你使用管理服务器（编程或者通过管理服务器）来配置域中的所有其他server实例和资源。

管理服务器的角色

在启动域的托管服务器之前，应先启动管理服务器。当你启动一个孤立或集群托管服务器时，它会按配置信息与管理服务器相联。这种方式下，管理服务器在整个域配置中充当核心控制体。

当管理服务器启动时，加载域的config.xml文件，除非你在创建域时指定另一个目录存储config.xml。

BEA_HOME/user_projects/domains/mydomain/config

这里mydomain是特定域的目录，名称与域相同。config.xml引用的其他配置文件，位于域的config目录的子目录下。

管理服务器每一次成功启动后，将在域目录中创建一份命名为config-booted.jar的备份配置文件。万一配置文件在server实例生命周期内有损坏，有可能恢复原先的配置。

如果管理服务器出错会发生什么？

域的管理服务器出错不会影响域中的托管服务器的操作。如果域的管理服务器变得不可用，而它所管理的server实例——集群或者其他方式——仍在运行，那么那些托管服务器将继续运行。如果该域包含集群server实例，那么由域配置支持的负载平衡和失败性能保持可用，即使管理服务器出错。如果域的管理服务器停止运行而托管服务器继续运行，那么每一个托管服务器会周期性地尝试重新连接管理服务器，周期由ServerMBean属性AdminReconnectIntervalSecs指定。AdminReconnectIntervalSecs默认为10秒。

如果管理服务器因为主机的硬件或软件错误而失败，同一台机器的其它server实例都可能受到同样的影响。然而，管理服务器自身的失败不会中断域的托管服务器的运行。而且即使管理服务器不在运行状态，你也可以启动托管服务器。这种情况下，托管服务器使用配置文件的本地拷贝来作为它的启动配置，然后周期性地向管理服务器作连接尝试，连接后利用管理服务器来同步配置状态。

对于重启管理服务器的指令，参见“管理服务器启动与关闭”。

托管服务器和托管服务器集群

在域中，非管理服务器的server实例，指向托管服务器。托管服务器驻留构成你应用的组件和相关资源，比如JSP和EJB。当某个托管服务器启动后，它会连接域的管理服务器来获得配置和部署设置。

注意：即使管理服务器不可用，域中的托管服务器也可以独立于管理服务器启动。更多信息参见“管理server启动与关闭”中的“避免server失败与恢复”。

两个或更多的托管服务器可以配置成一个WebLogic Server集群，来增加应用的可伸缩性与可用性。在WebLogic Server集群中，大多数资源与服务平均部署给每一个托管服务器（与单个托管服务器相反），来使失败与负载平衡。要想了解哪种组件类型和服务可以进行集群（部署给集群中的所有server实例），参见“使用WebLogic Server集群”中的“理解WebLogic Server集群”。

你可以创建一个非集群的托管服务器，然后通过配置有关server实例和集群的参数将其加入集群。你也可以通过重新配置参数从集群中删除某个托管服务器。在集群与非集群托管服务器之间的根本区别在于对失败和负载平衡的支持。这些特性仅在集群托管服务器中可用。

你对于可伸缩性与可靠性的要求将决定你是否采用集群托管服务器。比如，如果你的应用不常遇到易变的加载，应用服务中可能的中断也是可以接受的，那么就没有必要采用集群。

关于WebLogic Server集群的好处与性能的更多信息，参见“使用WebLogic Server集群”中的“理解WebLogic Server集群”。单个域可以包含多个WebLogic Server集群，同样多个托管服务器也可以不被配置成集群。

资源与服务

除了管理服务器和托管服务器之外，域还包括托管服务器所需的资源和服务及部署在该域上的应用。

域配置包括域运行的网络计算机环境信息，比如：

Machine definitions identify a particular, physical piece of hardware. A machine definition is used to associate a computer with the Managed Servers it hosts. This information is used by Node Manager in restarting a failed Managed Server, and by a clustered Managed Server in selecting the best location for storing replicated session data. For more information about Node Manager, see Using Node Manager to Control Servers in Designing and Configuring WebLogic Server Environments.

网络通道，一个可以用来定义默认端口、协议和协议设置的可选资源。在创建一个网络通道后，可以将它分配给域中任意一个托管服务器和集群。更多信息，参见“设计与配置WebLogic Server环境”中的“配置网络资源”。

域配置还包括与驻留在域中应用相关的资源和服务信息。这些资源和服务的例子包括：

应用组件，比如EJB

连接器

JDBC连接池

JMS server

启动类

资源和服务可能被限制于域中一个或多个托管服务器，而不是对于整个域可用。你可以选择托管服务器或者集群进行部署资源与服务。

域约束

WebLogic Server环境可以由单个域组成，包括驻留应用所需的所有托管服务器，也可以是多个域。你可以选择创建多个域，根据组织单元、系统管理员职责、应用边界或者其它要考虑的事项来划分。在设计域配置时，注意以下约束：

每一个域都需要自身的管理服务器执行管理操作。当你使用管理控制台执行管理和监控任务时，你可以在域中来回切换，同时你会连接不同的管理服务器。

同一个集群中的所有托管服务器必须位于相同的域，你不能将集群拆分至多个域。

同一个域中的所有托管服务器运行的WebLogic Server软件版本必须相同。域中的管理服务器可以和托管服务器运行相同的版本，也可以是更新的版本。

你不能在域中共享配置资源与子系统。比如，如果你在一个域中创建了一个JDBC连接池，你就不可能在另一个域中的托管服务器或集群中使用。代之，你必须在第二个域中创建一个类似的连接池。

第三章使用Weblogic工具配置域

WebLogic包括了你可以用来创建、修改或者复制域配置的一系列工具。包括以下工具：

域配置向导——域配置向导是创建一个新的域或集群的推荐工具。关于使用域配置向导的更多信息，参见“使用配置向导创建WebLogic域”。

WebLogic Server管理控制台——管理控制台是管理服务器的图形化用户界面（GUI）。管理控制台描述参见“管理控制台在线帮助”。

WebLogic脚本工具（WLST）——你可以使用命令行脚本接口来创建、管理和维护WebLogic Server配置变更。WebLogic脚本工具描述参见“WebLogic脚本工具”。

WebLogic Server应用编程接口（API）—— 你可以使用WebLogic Server提供的API编写程序修改配置属性。JMX API描述参见“使用JMX开发可管理的应用”。

WebLogic Server命令行工具——该工具允许你创建脚本来自动进行域管理。关于该工具的更多信息，参见“WebLogic Server命令参考”。

对于大多数方式而言，要修改域配置域的管理服务器必须运行。然而，你如果使用 WLST 来进行域配置变更不需要运行管理服务器。这种情况下，WLST造成的变更也不会立即生效直到管理服务器和托管服务器重启。

域配置文件

本章节描述如何在文件系统中表示域。它包括以下部分：

配置文件概览

config.xml

域域目录概览

域目录内容

域配置文件概览

WebLogic Server管理和配置服务通过Java管理扩展（JMX）API来访问。域的配置保存在域目录下的配置目录中。这些配置目录中的文件用来持久化存储WebLogic Server在使用JMX API运行期间创建和修改的托管对象。config.xml的目的是存储托管配置对象的变更以使得WebLogic Server重启时可以访问。

域的核心配置文件为domain_name/config/config.xml文件。它指定域的名称和域中每一个server实例、集群、资源和服务的配置参数。域的一些主要子系统配置保存在domain_name/config目录的子目录中。

域目录还包括你用来启动域的管理服务器和托管服务器的默认脚本文件。

config.xml

域的核心配置文件为/domains/domain_name/config/config.xml文件。它指定域的名称和域中每一个server实例、集群、资源与服务的配置参数。

config.xml文件符合XML Schema，URL为 http://www.bea.com/ns/weblogic/config。schema位于文件系统中的JAR文件BEA_HOME/weblogic90/server/lib/schema/configuration-binding.jar中，即META-INF/schemas/schema-0.xsd。XML编辑工具可以使用XML Schema来修改和验证config.xml文件。

编辑配置文件

大多数情况下，你不应该直接修改config.xml或其他配置文件，而应该使用管理控制台或者用第三章“使用WebLogic工具配置域”中列出的某个工具来修改域配置。配置变更将会映射到配置文件中。

Directly modifying configuration files may be appropriate if you choose to place configuration files and other components of your installation under source control, managing them using WLST.

警告：当WebLogic Server运行时你不能编辑配置文件，因为WebLogic Server会周期性地重写该文件。你的更改将会丢失，也可能造成WebLogic Server失败，这取决于你的平台。

Since the WebLogic Server configuration files are well-formed XML files, it is possible to script certain repetitive changes 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 each configuration file before you make any changes to it.因为WebLogic Server配置文件是格式友好的XML文件，因此它有可能使用XML解析程序比如 Apache Xerces, or JDOM 。

辅助配置文件

在原版本中，config.xml文件存放了所有配置信息。新版本中，几个WebLogic Server子系统被配置在辅助配置文件中，由核心的config.xml来引用。这些辅助配置文件位于/domains/domain_name/config目录的子目录中。关于辅助配置文件的更多信息，参见“域目录概览”和“域目录内容”。

配置文件压缩包

WebLogic Server对配置文件作备份拷贝。万一配置变更需要推倒重来或者配置文件被破坏（当然这种情况不太可能），这使得恢复很容易。当管理服务器启动时，它将配置文件保存在一个命名为config-booted.jar的JAR文件中。当你变更配置文件时，旧文件以JAR文件的形式保存在域目录下的configArchive目录中，命名带数字序列，比如config-1.jar。

域目录概览

图4-1是域目录树型结构的概览。 domain-name 、deployment-name和server-name目录名称不是字面所示，实际上替换成任何指定的名称都是可以的；其他的目录名称则是字面所示。概览只显示目录，不含目录内的文件。任何实际的特定域目录树，整个结构都可能不会是这样。

域目录内容

本节描述域目录和子目录的内容，以斜体表示的目录名称不是实际的名称，而是要以适当的具体名称来替代，非斜体的名称则是字面上所示的名称。

domain-name

该目录的名称为域的名称。

applications

该目录提供了一种在部署服务器上部署应用的快速方式。当Weblogic Server实例以开发模式运行时，它会自动部署你放置在该目录的任何应用与模块。

你放置在目录的文件可以是：

一个J2EE应用

一个EAR文件

一个WAR、EJB JAR、RAR或者CAR的压缩模块

一个应用或者一个模块的解压目录

bin

该目录包括了一些用来启动或终止域中的管理服务器和托管服务器进程的脚本。它也可以包括一些其他广义上的域脚本，比如启动和终止数据库管理系统、全文检索引擎进程等的脚本。更多信息，参见管理server启动和终止。

config

该目录包含域的当前配置和部署状态，核心域配置文件config.xml即位于本目录中。

config/deployments

保存域部署应用的目录。

config/deployments/library_modules

保存类库模块的目录，也就是说，该目录中的任何文件都将以类库模块自动注册。

config/deployments/deployment-name-1

该目录包含一个应用或者可发布的模块。它所含的子级目录可以包含一个压缩文件（EAR或WAR），一个部署清单，扩展描述符等等。

config/diagnostics

该目录包含WebLogic诊断服务（WebLogic Diagnostic Service）系统模块。更多信息，参见“理解WebLogic诊断服务”。

config/jdbc

该目录包含JDBC系统模块：所有JDBC模块都可以通过JMX直接配置（和JSR-88不同）。更多信息，参见“数据库连接（JDBC）”。

config/jms

该目录包含JMS系统模块：所有JMS模块都可以通过JMX直接配置。更多信息，参见“消息与数据库连接（JDBC）”。

config/nodemanager

该目录保存与节点管理器连接的的配置信息。更多信息，参见“设计与配置WebLogic Server环境”中的“使用节点管理器管理服务”。

config/security

This directory contains system modules for the security framework. It contains one security

provider configuration extension for each kind of security provider in the domain’s current realm.

For more information, see Understanding WebLogic Security.该目录包含安全框架系统模块。

config/startup

该目录包含含启动计划的系统模块。启动计划被用来生成shell脚本，作为server启动的一部分。

configArchive

This directory contains a set of JAR files that save the domain’s configuration state. Just before

pending changes to the configuration are activated, the domain’s existing configuration state,

consisting of the config.xml file and the other related configuration files, is saved in a versioned

JAR file with a name like config.jar#1, config.jar#2, etc.该目录包含一组用于保存域配置状态的JAR文件。

The maximum number of versioned JAR files to be kept is specified by the

archiveConfigurationCount property of DomainMBean. Once this maximum number is

reached, the oldest conversion archive is deleted before a new one is created.

lib

放置在该目录中的任何JAR文件在sever的Java虚拟机启动时都会添加至域中每一个server实例的系统classpath。

pending

该目录包含的域配置文件表示已请求，但还没有激活的配置变更。一旦配置变更被激活，该目录中的配置文件将被删除。更多信息，参见“管理配置变更”。

security

该目录保存的安全相关文件对于域中的每一个WebLogic Server实例来说都是相同的。

SerializedSystemIni.dat

该目录还保存只有域管理服务器需要的安全相关文件：

DefaultAuthorizerInit.ldift

DefaultAuthenticatorInit.ldift

DefaultRoleMapperInit.ldift

更多信息，参见“理解WebLogic安全”。

servers

该目录为域中每一个WebLogic Server实例设置一个子目录。

servers/server-name

该目录为server目录，名称和WebLogic Server实例的名称相同。

servers/server-name/bin

该目录存放可执行的或shell文件，对于不同的server可能会不同。server环境脚本（setServerEnv.sh或setServerEnv.cmd）是位于此处的一个文件示例，因为它能区分一个WebLogic Server实例与下一个实例的不同，这取决于server实例是否有自己的启动计划。

servers/server-name/cache

This directory holds directories and files that contain cached data. By “cached” here we mean that

the data is a copy, possibly in a processed form (compiled, translated, or reformatted), of other

data.该目录存放包含缓存数据的目录和文件。这里“缓存（cached）”表示

servers/server-name/cache/EJBCompilerCache

该目录为已编译的EJB缓存。

servers/server-name/data

This directory holds files that maintain persistent per-server state used to run the WebLogic

Server instance, other than security state, as opposed to temporary, cached or historical

information. Files in this directory are important data that must be retained as the WebLogic

Server instance is brought up, is brought down, crashes, restarts, or is upgraded to a new version.

servers/server-name/data/ldap

该目录存放内嵌的LDAP数据库。WebLogic Server实例的运行时安全状态持久化于该目录。

servers/server-name/data/store

This directory holds JMS persistent stores. For each persistent store, there is a subdirectory that

holds the files that represent the persistent store. The name of the subdirectory is the name of the

persistent store. By convention there is one store named default.

servers/server-name/logs

该目录存放日志和诊断信息。实际上只是一些历史信息，对于server的运行并非至关重要，可以删除（不过至少WebLogic Server实例应该终止）而不影响正确的运行。然而，这些信息对于调试和检查相当有用，如果没有好的理由不应当删除。

servers/server-name/logs/diagnostic_images

该目录存放WebLogic诊断服务（WebLogic Diagnostic Service）的Server图片捕获器（Server Image Capture）组件创建的信息。更多信息，参见“理解WebLogic诊断服务”。

servers/server-name/logs/jmsServers

该目录为WebLogic Server实例中的每一个JMS服务提供一个子目录。每一个那样的子目录包含JMS服务的日志。子目录的名称为JMS服务的名称。

servers/server-name/logs/connector

该目录是连接器模块（JCA资源适配器）日志的默认基目录。

servers/server-name/security

该目录存放安全相关文件，每一个WebLogic Server实例都可能不同。文件boot.properties是位于此处的一个文件示例，因为它能区分一个server实例与下一个实例的不同。该目录还维护与SSL key相关的文件。

servers/server-name/tmp

该目录存放server实例运行时创建的临时目录与文件。server运行时该目录中的文件应当保留，但可以在server实例终止后随意删除。

第五章管理配置变更

为了提供一个安全、可预期的方式来分发域的配置变更，WebLogic Server采用了大致类似于数据库事务的变更管理进程。域的配置在文件系统中表示为一组XML配置文件，核心为config.xml文件，在运行时表示为配置MBean（Configuration MBeans）树。当你编辑域配置时，你实际上编辑的是分离的管理服务器的配置MBeans树。要开始编辑过程，你应获得编辑树的锁以阻止其他人进行变更。完成变更后，保存变更。不过变更不会生效直到你激活它们，分发给域中的所有server实例。激活变更后，每一个server都决定是否接受变更。如果所有server都可以接受该变更，则更新运行着的配置层，变更完成。

Note that WebLogic Server’s change management process applies to changes in domain and

server configuration data, not to security or application data.

关于如何通过JMX和配置MBean来实现配置变更的更多详细信息，参见“使用JMX开发可管理的应用”中的“理解WebLogic Server MBeans”

如第三章“使用WebLogic工具配置域”中的描述，你可以使用一系列不同的WebLogic Server工具进行配置变更：

管理控制台

WebLogic 脚本工具

JMX API

无论你使用哪一个工具进行配置变更，WebLogic Server都采用大体相同的方式来处理变更过程。

以下章节描述配置变更管理：

管理控制台的变更管理

配置变更管理过程

配置管理状态图

管理控制台的变更管理

WebLogic管理控制台将配置变更管理过程集中于Change Center：

如果你想使用管理控制台进行配置变更，你必须先点击Change Center中的Lock & Edit（锁定并编辑）按钮。当你点击Lock & Edit后，你会获得域中所有server的配置MBean的可编辑层（编辑树）。

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

domain-name

/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. 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.

配置变更管理过程

以下步骤详细描述该过程，从你首先导入域的管理服务器开始：

1.服务器启动时读取域配置文件，包括config.xml文件和config.xml文件涉及的所有附属配置文件，使用这些数据对随后的MBean树进行实例化：

–一个配置 MBean的只读树包含管理服务器的当前资源配置。

–域中所有服务器的所有配置 MBean的可编辑树。

注意：管理服务器也会实例化一个运行时MBean树和一个域运行时MBean树，但是这些不用于配置管理。

2. 按以下步骤开始配置变更：

a. 获得当前配置锁。

b. 使用你选择的工具（管理控制台，WLST，JMX API等），按你的要求变更。

c. Save your changes to a pending version of the config.xml file.保存更改

3. The Configuration Manager service saves all data from the edit MBean tree to a separate set

of configuration files in a directory named pending. See Figure 5-2.

The 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 mydomain/pending/config.xml.

4. Make additional changes or undo changes that you have already made.

5. When you are ready, activate your changes in the domain, using the Activate Changes

button in the Administration Console’s Change Center or using the

ConfigurationManagerMBean.

When you activate changes (see Figure 5-3):

a. For each server instance in the domain, the Configuration Manager service copies the

pending configuration files to a pending directory 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.

b. Each server instance compares its current configuration with the configuration in the

pending file.每一个服务器实例将它的当前配置和文件中配置比较。

c. Subsystems within each server vote on whether they can consume the new configuration.

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.

d. If all subsystems on all servers can consume the change, the Configuration Manager

service replaces the read-only configuration files on each server instance in the domain

with the pending configuration files.

e. Each server instance updates its beans and its read-only Configuration MBean tree

according to the changes in the new configuration files.每一个server实例都会更新bean和只读配置 MBean 树以保持和新的配置文件修改一致。

f. The pending configuration files are then deleted from the pending directory.

6. You can retain your lock to make additional changes or release it so that others can update

the configuration. You can configure a timeout period that causes the Configuration

Manager service to abandon a lock.

Note: The configuration change lock does not 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. Since this can lead to confusion and conflicting

configuration changes, this is not a recommended practice. 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.

处理变更冲突

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.

配置管理状态图

配置管理服务遵循图 5-4中描述的状态转换。