另有：http://wiki.ubuntu.org.cn/JBoss_5.0.0GA安装指南

一．下载与安装JBoss

在本文中，我下载的JBoss版本为：JBOSS5.0 Beta4。

下载地址： http://www.jboss.org/jbossas/downloads/

在如上的下载页中下载JBOSS5.0 Beta4.zip文件。

下载完成后，将其解压缩后即可完成安装，解压 缩后将其放置到一个不带空格的目录(若目录带有空格，例如：C:"Program Files，日后可能会产生一些莫名的错误)，eg：E:"JBossJBOSS5.0 Beta4。同时在“环境变量设置”中设置名为JBOSS_HOME的环境变量，值为JBoss的安装路径，如下图所示：

在此，JBoss的安装工作已经结束，可通过如下方式测试安装是否成功：

运行JBoss安装目 录"bin"run.bat，如果窗口中没有出现异常，且出现：10:16:19,765 INFO [Server] JBoss (MX MicroKernel) [5.0.Beta4 (build: SVNTag=5.0.Beta4 date=20080831605)] Started in 30s:828ms字样，则表示安装成功。

我们可以通过访问： http://localhost:8080/ 进入JBoss的欢迎界面，点击JBoss Management下的JMX Console可进入JBoss的控制台。

若启动失败，可能由以下原因引起：

1）              JBoss所用的端口（8080，1099，1098，8083等）被占用。一般情况下为8080端口被占用（例如，Oracle占用了8080端口）， 此时需要修改JBoss的端口，方法为进入JBoss安装目录"server"default"deployer"jboss-web.deployer 目录，修改其下的server.xml目录，在此文件中搜索8080，将其改成你想要的端口即可（例如8088）；

2）              JDK安装不正确；

3）              JBoss下载不完全。

二．             JBoss 的目录结构说明

三．             JBoss 的配置

1.       日志文件设置

若需要修改JBoss默认的log4j设置， 可修改JBoss安装目录"server"default"conf下的jboss-log4j.xml文件，在该文件中可以看到，log4j的日志输出 在JBoss安装目录"server"default"log下的server.log文件中。对于log4j的设置，读者可以在网上搜索更加详细的信 息。

2.       web 服务的端口号的修改

这点在前文中有所提及，即修改JBoss安装目录"server"default"deployer"jboss-web.deployer下的server.xml文件，内容如下：

<Connector port="8080" address="${jboss.bind.address}"   

         maxThreads="250" maxHttpHeaderSize="8192"

         emptySessionPath="true" protocol="HTTP/1.1"

         enableLookups="false" redirectPort="8443" acceptCount="100"

         connectionTimeout="20000" disableUploadTimeout="true" />

将上面的8080端口修改为你想要的端口即可。重新启动JBoss后访问：http://localhost/:新设置的端口，可看到JBoss的欢迎界面。

3.       JBoss 的安全设置

1） jmx-console 登录的用户名和密码设置

默认情况访问 http://localhost:8080/jmx-console 就可以浏览jboss的部署管理的一些信息，不需要输入用户名和密码，使用起来有点安全隐患。下面我们针对此问题对jboss进行配置，使得访问jmx-console也必须要知道用户名和密码才可进去访问。步骤如下：

i) 找到JBoss安装目录/server/default/deploy/jmx-console.war/WEB-INF/jboss-web.xml文件，去掉<security-domain>java:/jaas/jmx-console</security-domain>的注释。修改后的该文件内容为：

<jboss-web>

   <!-- Uncomment the security-domain to enable security. You will

       need to edit the htmladaptor login configuration to setup the

       login modules used to authentication users.-->

      <security-domain>java:/jaas/jmx-console</security-domain>

</jboss-web>

ii）修改与i）中的jboss-web.xml同级目录下的web.xml文件，查找到<security-constraint/>节点，去掉它的注释，修改后该部分内容为：

<!-- A security constraint that restricts access to the HTML JMX console

    to users with the role JBossAdmin. Edit the roles to what you want and

    uncomment the WEB-INF/jboss-web.xml/security-domain element to enable

    secured access to the HTML JMX console.-->

   <security-constraint>

     <web-resource-collection>

       <web-resource-name>HtmlAdaptor</web-resource-name>

       <description>An example security config that only allows users with the

          role JBossAdmin to access the HTML JMX console web application

       </description>

       <url-pattern>/*</url-pattern>

       <http-method>GET</http-method>

       <http-method>POST</http-method>

     </web-resource-collection>

     <auth-constraint>

       <role-name>JBossAdmin</role-name>

     </auth-constraint>

   </security-constraint>

   在此处可以看出，为登录配置了角色JBossAdmin。

iii） 在第一步中的jmx-console安全域和第二步中的运行角色JBossAdmin都是在login-config.xml中配置，我们在JBoss安装目录/server/default/config下找到它。查找名字为：jmx-console的application-policy：

<application-policy name = "jmx-console">
       <authentication>
          <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
              flag = "required">
           <module-option name="usersProperties">props/jmx-console-users.properties</module-option>
           <module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
          </login-module>
       </authentication>
    </application-policy>

在此处可以看出，登录的角色、用户等的信息分别在props目录下的jmx-console-roles.properties和jmx-console-users.properties文件中设置，分别打开这两个文件。

其中jmx-console-users.properties文件的内容如下：

# A sample users.properties file for use with the UsersRolesLoginModule

admin=admin

该文件定义的格式为：用户名=密码，在该文件中，默认定义了一个用户名为admin，密码也为admin的用户，读者可将其改成所需的用户名和密码。

jmx-console-roles.properties的内容如下：

# A sample roles.properties file for use with the UsersRolesLoginModule

admin=JBossAdmin, HttpInvoker

该文件定义的格式为：用户名=角色，多个角色以“,”隔开，该文件默认为admin用户定义了JBossAdmin和HttpInvoker这两个角色。

配置完成后读者可以通过访问： http://localhost:8088/jmx-console/ ，输入jmx-console-roles.properties文件中定义的用户名和密码，访问jmx-console的页面。

四．             在MyEclipse 中配置JBoss

笔者的MyEclipse版本：6.5 GA

JBoss版本：5.0
JDK版本：1.6

进入Window-> Preferences-> MyEclipse -> Application Servers -> JBoss5，进行如下设置：
    

选择JBoss 5下的JDK设置所用的JDK.

好了，开始JBoss之旅吧.

当用户执行一个大数据的应用时（净字节码量约为5M）时，系统会提示出错：

前台错误为：HTTP　Status 500-Dispatch[EAITool] to method listCurTree retrun an exception

(以下省略)

………………………………………………………

………………………………………………………

后台错误为：java.lang.OutOfMemoryError: unable to create new native thread
        at java.lang.Thread.start(Native Method)
        at org.apache.catalina.loader.WebappLoader.notifyContext(WebappLoader.ja
va:847)

(以下省略)

………………………………………………………

………………………………………………………

问题分析：

　　　由于TOMCAT内存溢出而引发的问题，主要原因是JVM的虚拟内存默认为128M，当超过这个值时就把先前占用的内存释放，而导致好象TCP/IP丢包的假象，出现HTTP500的错误。　　
      解决方法主要是加大TOMCAT可利用内存，并在程序当中加大内存使用。

解决方法：

方法：加大TOMCAT可利用内存：
　　在TOMCAT的目录下，也就是在TOMCAT41/bin/catalina.bat文件最前面加入
　　set JAVA_OPTS=-Xms800m -Xmx800m
　　表现效果是当你启动TOMCAT时，系统内存会增加近800M使用

操作方法：
　　1）、先关掉WINDOWS服务当中的TOMCAT4服务。
　　2）、再找到TOMCAT/BIN目录下startup.bat，双击打开它，你会发现现WINDOWS内存占用会增加近800M。
　　3）、执行程序，因为是TOMCAT重新编译程序，所以第一次会比较慢。

结论：

经过测试，我们得出如下数据：

当系统传输约2000条数据时，大约近12M的净数据（不压缩时），系统辅助运行的内存大约占用150M左右的空间，也就是近200M的内存占用，而我们扩大了近800M的JAVA内存使用，这对于业务本身来说是足够了。所以你们不用担心大数据量的传递问题。

基于JAVA虚拟机的原理，JAVA自动有垃圾回收机制，也就是在你对一些内存长时间不使用时（近2分钟，取决于使用频度和优先级等），就会自动垃圾回收，从而释放不用的内存占用。

尽管域的范围与目的会有很大差异，但是大多数 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中描述的状态转换。