weblogic中文文档——domain_config

第一章 介绍与导览




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




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

文档范围与读者

文档向导

相关文档

示例与指南

该发布版本中新的域特性




文档范围与读者




文档主要适用于基于一个或多个Weblogic server域开发和部署Web应用的J2EE系统架构师、应用开发人员和系统管理员。




文档的主题仅和软件项目的设计与开发阶段相关，不涉及产品过程管理、监控或者性能调整。对于这些主题的WebLogic Server文档和资源链接，参见“相关文档”。




文档假定读者熟悉J2EE，XML的基本概念以及应用管理的一般概念。




文档向导

本章“介绍与导览”，介绍该指南的目的、结构和上下文关系。

第二章“理解WebLogic Server域”介绍Weblogic Server域。

第三章“使用WebLogic工具配置域”，展示你可以用来修改域配置的几种工具。

第四章“域配置文件”描述维护域和域的内容的磁盘表现形式的配置与目录。

第五章“管理配置变更”描述如何变更Weblogic 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提供了一些新特性用来管理服务配置变更，这使你可以安全、可预知地实现分发某个域的配置变更。当然这要求你在使用控制台进行配置变更前获得管理员控制台锁。




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集群，同样多个托管服务器也可以不被配置成集群。




资源与服务




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




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

机器定位依靠硬件上某个特定的物理片段来识别。机器定位被用来关联驻留托管服务器的计算机。该信息由节点管理器（Node Manager）重启一台出错的托管服务器，集群的托管服务器选择存储重复的会话数据的最好位置时使用。关于节点管理器的更多信息，参见“设计与配置WebLogic Server环境”的“使用节点管理器控制服务器”。

网络通道，一个可以用来定义默认端口、协议和协议设置的可选资源。在创建一个网络通道后，可以将它分配给域中任意一个托管服务器和集群。更多信息，参见“设计与配置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工具配置域”中列出的某个工具来修改域配置。配置变更将会映射到配置文件中。

如果你选择放置配置文件，安装的其他组件在源控制之下（使用WLST管理），直接修改配置文件可能是合适的。

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

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

该目录包含安全框架系统模块。包含了当前域的每一种安全供应器的安全供应器配置扩展。更多信息，参见理解“WebLogic 安全”。

config/startup

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

configArchive

该目录包含一组用于保存域配置状态的JAR文件。在未决的配置变更激活前，域的当前配置状态，包括config.xml文件和其他相关文件，保存在带版本号的JAR文件中，命名成config.jar#1，config.jar#2等等。

带版本号的JAR文件的最大数量由DomainMBean的archiveConfigurationCount属性指定。一旦达到最大数，在新版本创建之前删除最旧的版本。

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

该目录存放包含缓存数据的目录和文件。这里“缓存（cached）”表示该数据是其他数据的拷贝，可能是进程中的形式（已编译，已翻译或重新格式化的）。

servers/server-name/cache/EJBCompilerCache

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

servers/server-name/data

和临时的、缓存的或者历史信息相反，该目录存放的文件维护持久化的预服务状态，而不是安全状态，用于运行WebLogic Server实例。该目录中的文件非常重要，必须存在于WebLogic Server实例开始，停止，崩溃，重启或升级至新版本的整个过程中。

servers/server-name/data/ldap

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

servers/server-name/data/store

该目录存放JMS持久化存储。对于每一个持久化存储，都有一个子目录存放表示持久化存储的文件。子目录的名称为持久化存储的名称。照例有一个存储命名为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都可以接受该变更，则更新运行着的配置层，变更完成。




注意WebLogic Server的变更管理过程适用于域的变更和server配置数据，不适用于安全或应用数据。

关于如何通过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的可编辑层（编辑树）的锁。

在你使用管理控制台进行配置变更后，在适当的页面点击Save（保存）（某些情况下为Finish（完成）），这些不会使变更立即生效，而是在你点击Save时，将变更保存至编辑树，domain-name/pending/config.xml文件和相关的配置文件。只有在你点击Change Center的Activate Changes（激活变更）时变更才会生效，此时，配置变更分发至域中的每一个server。只有每一个server都接受该变更，变更才会生效。如果有任何server不接受该变更，那么域中的所有server的所有变更全部回滚。变更保持为未决状态，你既可以编辑该未决变更以解决问题或者恢复未决变更。

配置变更管理过程

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

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

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

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

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

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

a. 获得当前配置锁。

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

c. 将变更保存至config.xml文件的未决版本。

3. 配置管理器服务将来自编辑MBean树的所有数据保存成一份独立的配置文件，目录名为pending。参见图5-2。

pending目录直接位于域的根目录下。比如说，如果你的域命名为mydomain，那么未决的config.xml文件的默认路径名为mydomain/pending/config.xml。



4. 进行其它变更或者取消已做出的变更。

5. 当你准备激活域的变更时，使用管理控制台Change Center的Activate Changes按钮或者使用ConfigurationManagerMBean。

激活变更（参见图 5-3）：

a. 对于域的每一个server实例，配置管理器服务将未决配置文件拷贝至server的根目录下的pending目录。

如果托管服务器和管理服务器共享根目录，ConfigurationManagerMBean不必拷贝未决的配置文件，托管服务器直接使用管理服务器的未决文件。

b. 每一个server实例将它的当前配置和未决文件中的配置进行比较。

c. 每一个server内部的子系统将对自身是否能接受新配置进行投票。

只有要任一子系统表示它不能接受该变更，整个的激活过程将回滚，ConfigurationManagerMBean抛出异常。你可以修改变更，再次进行变更激活，或者放弃锁，编辑配置MBean树和未决配置文件恢复至只读配置MBean树和配置文件的配置。

d. 如果所有server的所有子系统都能接受该变更，配置管理器服务将域的每一个server实例的只读配置文件替换成未决配置文件。

e. 每一个server实例都会更新bean和只读配置MBean树以和新的配置文件的变更保持一致。

f. 然后未决配置文件从pending目录中删除。

6. 你可以保持锁以进行其它的变更或者释放锁以使其他人可以更新配置。你也可以设置超时时限使配置管理器服务放弃锁。

注意：配置变更锁不会防止你在使用相同的管理员账号造成的配置编辑冲突。比如，如果你使用管理控制台获得配置变更锁，然后以相同的用户帐号使用WebLogic脚本工具，你将访问的是在管理控制台中打开的相同的编辑会话，你不会因为使用脚本工具而被锁定。由于这可能造成配置变更的混乱和冲突，这不是一种受推荐的手段。你应该通过为每一个管理员身份的用户维护一个独立的管理员账号来减少发生这种情况是造成的风险。不过如果你有使用相同的用户帐号的多个相同脚本实例，相同的问题仍然会发生，



处理变更冲突

这种情况，你保存的多个变更没有被激活，某个变更会使前一个变更无效，变更管理器服务需要你在保存变更前手动解决该无效问题。




配置管理状态图




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