JBoss7配置指南

时间 2019-11-10

标签 jboss7 jboss 配置指南繁體版

原文原文链接

JBoss7配置指南html

1. jboss各主要版本特性... 3前端

1.1. jboss4特性... 3java

1.2. jboss5特性... 5node

1.3. jboss6特性... 6git

1.4. jboss7特性... 7github

2. 为何JBoss AS7 这么快... 8web

3. JBoss AS7中的新概念－域... 10sql

3.1. 域(Domain)的概念及其与群集(Cluster)的区别... 10数据库

3.2. 实验... 11apache

1.1.1. 准备工做... 11

1.1.2. 配置... 12

3.2.1.1. Master上面的配置... 14

3.2.1.1.1. domain.xml 14

3.2.1.1.2. host.xml 15

3.2.1.2. Slave上面的配置... 16

3.2.1.2.1. domain.xml. 16

3.2.1.2.2. host.xml 16

3.3. AS 7.1的安全补充说明... 17

3.4. 部署... 20

3.5. 小结... 25

4. JBoss7配置... 26

4.1. 目标听众... 26

4.1.1. 开始以前... 26

4.1.2. 手册中的示例... 26

4.2. 客户端... 26

4.2.1. web接口... 26

4.2.1.1. HTTP管理接入点... 26

4.2.1.2. 访问管理控制台... 27

4.2.1.3. 对管理控制台进行加密... 27

4.2.2. 命令行接口... 27

4.2.2.1. Native管理接入点... 28

4.2.2.2. 运行命令行管理工具... 28

4.2.2.3. 管理请求... 29

4.2.2.3.1. 管理资源的地址... 30

4.2.2.3.2. 操做类型和操做描述列表... 30

4.2.2.4. 命令行历史信息... 32

4.2.2.5. 批处理... 32

4.2.3. 配置文件... 33

4.3. 核心管理概念... 34

4.3.1. 运行模式... 34

4.3.1.1. 单服务器模式... 34

4.3.1.2. 管理域... 34

4.3.1.2.1. Host(主机) 35

4.3.1.2.2. 主机控制器(HostController) 35

4.3.1.2.3. Domain Controller(域控制器）... 36

4.3.1.2.4. Server Group (服务器组) 37

4.3.1.2.5. Server (服务器）... 38

4.3.1.3. 决定运行在单独服务器或者管理域上... 38

4.3.2. 通用的配置概念... 39

4.3.2.1. Extensions (扩展) 39

4.3.2.2. Profile和subsystem(子系统 ) 40

4.3.2.3. Paths( 路径) 40

4.3.2.4. nterfaces (接口) 42

4.3.2.5. socket binding(socket绑定)和socket binding group(socket绑定组) 43

4.3.2.6. System Properties( 系统属性) 43

4.3.3. Management resources( 管理资源) 44

4.3.3.1. Address (地址) 44

4.3.3.2. operations( 操做) 45

4.3.3.3. Attributes( 属性) 47

4.3.3.4. Children（子节点) 49

4.3.3.5. Descriptions(描述) 51

4.3.3.6. 和JMX Beans相比... 53

4.3.3.7. 管理资源树的基本结构(management resource trees) 53

4.3.3.7.1. 单服务器模式(Standalone server) 53

4.3.3.7.2. 管理域模式 (managed domain) 54

4.4. 管理任务... 56

4.4.1. 网络接口和端口... 56

4.4.1.1. 网络接口声明... 56

4.4.1.2. Socket Binding Groups 58

4.4.2. 管理接口的安全性... 59

4.4.2.1. 初始化设置... 60

4.4.2.2. 快速配置... 61

4.4.2.3. 详细配置... 63

4.4.2.3.1. 管理接口... 63

4.4.2.3.2. 安全域... 64

4.4.2.3.3. Outbound connections(外部链接) 68

4.4.2.4. 问题... 68

4.4.3. JVM设置... 68

4.4.3.1. 管理域... 69

4.4.3.2. 单独运行服务器... 70

4.4.4. 命令行参数... 70

4.4.4.1. 系统属性... 71

4.4.4.2. 单独运行模式（ Standalone) 71

4.4.4.3. 管理域模式 (Managed Domain) 72

4.4.4.4. 其余命令行参数... 72

4.4.4.4.1. 单服务器模式（ Standalone）... 73

4.4.4.4.2. 管理域模式 (Managed Domain) 73

4.4.4.4.3. 通用参数 (Common parameters) 73

4.4.5. 子系统配置... 74

4.4.5.1. 数据源 (Data sources) 74

4.4.5.1.1. JDBC驱动安装... 74

4.4.5.1.2. 数据源定义 (Datasource Definitions) 75

4.4.5.1.3. 参考... 78

4.4.5.2. 消息 (Messaging) 78

4.4.5.2.1. Connection Factories 78

4.4.5.2.2. Queues and Topics 79

4.4.5.2.3. Dead Letter和Redelivery. 80

4.4.5.2.4. 安全性... 81

4.4.5.2.5. 参考... 82

4.4.5.3. Web. 82

4.4.5.3.1. 容器设置 (Container configuration) 82

4.4.5.3.2. Connector设置 (Connector configuration) 84

4.4.5.3.3. Virtual-server配置（Virtual-Server configuration）... 88

4.4.5.3.4. 参考... 89

4.4.5.4. Web services 89

4.4.5.4.1. 参考... 90

jboss各主要版本特性

1.1. jboss4特性

JBoss4包括web服务器(servlet/JSP容器，HTML服务器)、EJB2.0容器。完整的纯Java的数据库引擎，(Java消息服务)JMS，JavaMail,和Java事务处理API/Java事务处理服务（JTA/JTS）支持。早期的JBoss使用了Apache Tomcat Web服务器，但在JBoss4.0中已经吧Apache Tomcat内嵌到JBoss中了。后续又集成Java数据对象(JDO)，对于JMS多点传送机制支持的修补，对J2EE1.4的彻底实现和分布式事务机制。

JBoss的应用服务器控制和配置－JMX机制，运行一次能够部署全部的组件和服务。资源属性和可配置参数能够经过MBeans（可控制beans）映射和更改，这些控制能够在 JBoss的控制台进行设置。一旦咱们的servlet-based的应用程序被部署，JBoss就自动安装一个部署MBeans,这个MBeans会被添加到JMX控制台的导航菜单中。经过这个MBean就能够部署或卸载WAR应用程序，或查看应用程序相关的属性。

JBoss 4基于JBoss 3.2,在J2EE标准特性方面，主要的改进包括：

l JBoss 4是业界第一家取得正式J2EE 1.4认证的应用服务器，彻底符合规范的J2EE标准。

l 彻底支持J2EE web services（JAX-RPC方式和WS4EE架构方式）和SOA。

l 支持AOP模型,JBoss Aop极大的提升了生产力。

l 与Hibernate紧密集成。

l 经过一个内建的Caching构架提高集群功能和分布式Caching（TreeCache）。

JBoss4彻底遵循J2EE1.4标准，因此容许开发者在不一样的应用服务器上重用J2EE组件（如EJB等），好比能够轻易的将部署在Weblogic或Websphere上的EJB迁移到JBoss上赖，JBoss4比JBoss3.2实现了下面几个新的J2EE标准：

l JBoss4支持J2EE Web Services，包括JAX-RPC和J2EE架构的Web Services，使用EJB提供安全的Web Service环境，它是基于J2EE的SOA实现。JBoss3.2中旧的JBoss.NET Web Services API再也不支持，新的Web Service实现是WS BasicProfile-1.0 compliant。

l JBoss4实现JMS1.1替代了JBoss3.2中的JMS1.0

l JBoss4实现了JCA (Java Connector Architecture) 1.5替代了JBoss3.2中的JCA1.0

l JBoss4实现了新的Java Authorization Contract for Containers (JACC),JACC是JAVA2一个基本的权限机制，为访问EJB方法和web资源赋予受权描述，即J2EE应用服务器和特定的受权认证服务器之间定义了一个链接的协约，新的实如今语法上基于JBoss3.2，使用认证过的Subject声明Roles，认证与JAAS的authentication保持一致。而且security配置，JBoss4和JBoss3.2兼容。

l JBoss4实现了EJB2.1规范.替代了JBoss3.2中的EJB2.0规范。

JBoss4特性：

l JBoss4.2必须须要安装jdk5

l JBoss Ejb3默认被安装

l JBoss的web容器使用JBoss Web v2.x (集成tomcat6)

l deploy/jboss-web.deployer 目录替换了原先的deploy/jbossweb-tomcat55.sar

l JBoss Transactions v4.2为默认的事务管理器

l JBoss WS提供web service功能

l JGroups/JBossCache支持 channel multiplexing

l JBoss Remoting更新到stable 2.2.x，JBossMQ(JBoss4.0使用)为默认JMS实现，可是可使用JBoss Messaging替换。

l EJB调用方式由 rmi-invoker替换为JBoss Remoting 的 unified-invoker

l log4j 和 commons-logging 升级到新版本。

1.2. jboss5特性

JBoss AS5中，大部分显著的新特性添加都源自于要将全部主要的JBoss子系统带到下一个阶段去：

JBoss Messaging 1.4如今取代了JBossMQ，成为缺省的JMS提供者。除了透明的故障恢复和智能的消息重分发外，JBM还支持即开即用的集群队列和主题。能够跨节点把消息复制到内存中，从而避免磁盘I/O，或者能使用支持大消息的分页技术将消息持久化到任何流行的关系数据库中。JBM证实，利用已彻底出现的新的只扩展日志存储，本来就很卓越的性能和东西会变得更加优秀。

JBoss WebServices 3.0，彻底支持JAX-WS/JAX-RPC、XOP和SwA的附件、还有一系列WS-*标准。JBWS转向了一个可插拔的架构，该架构容许更换底层的WebServices栈，因此你能够将JBossWS-native换成Sun Metro或Apache CXF。这样的话，你就能够因地制宜，使用最合适WebServices栈。

为了改进可伸缩性和集群Web会话的钝化，AS5中的集群支持SFSB的Buddy复制，以控制内存的使用。EJB3 Entity和Hibernate缓存有了很大的改进，由于能够针对实体和查询使用不一样的缓存，它们分别是失效缓存和复制缓存。在底层的JGroups协议栈中，还有一些其它的性能优化。

JBoss Transactions是JBoss 5默认的事务管理器。JBoss TS已经与JBoss 5的Servlet容器——JBoss Web——一块儿在AS 4.2系列中进行了测试，JBoss Web是基于Apache Tomcat的一个实现，支持原有的APR-based链接器，它在可伸缩性和性能上不但要达到，并且要超越Apache Http服务器的水平。

就API来讲，AS5是Java EE 5的实现，全部相关的API都会包含在内。对大部分Java EE 5“新的”API来讲，好比EJB三、JAX-WS、JPA等，在JBoss AS 4.2系列中已经实现了，但因为JBoss AS5增长了TCK测试的覆盖范围，因此确定会更为严格遵循规范。

JBoss5应用服务器提供了大量的新功能：除了支持最新的EJB 3.0规范外，新版的JBoss AOP也正式发布。Web Services 方面，JBoss 如今支持所有的J2EE Web Services，同时兼容Microsoft.NET；Messaging 项目采用了完整的JMS 1.1 实现，同时充分的改进了分布式目的单元格等功能的高可用性；JBoss Seam 中包括了一系列统一的革命性的组建设计模型和框架。同时JBoss 5中也集成了Hibernate 3.2

JBoss AS 4.2和企业应用平台的第一个版本（EAP 4.2）确实对AS 5形成了很大的影响。从零开始建立一个全新的内核、从MBeans转换到POJO、在最底层集成AOP、统一跨子系统的元数据处理、更改类加载系统、使部署器Aspect化，换句话说，就是改变内部架构、替换应用服务器的核心，同时还要保持与大部分已有服务的向后兼容性，为各类内部子系统引入合适的SPI。长远看来这是好事，由于它容许最大的可插拔性，以及在不一样的运行时环境中（好比独立的EJB3或嵌入到不一样的应用服务器中）按须要选取使用各类JBoss项目。

JBoss AS5不仅是一个Java EE 5应用服务器。对下一代JBoss项目来讲，它还寄托了成为最早进的服务器运行时环境的愿景。

1.3. jboss6特性

JBoss AS6 最大亮点是对Java EE 6 Web Profile规范的支持，一份关于最流行的Java EE标准的报告中，排名前5（JPA、JSP、EJB三、JSF及CDI）的都是Java EE Web Profile的必备组件。除了Java EE 6 Web Profile所需的这些组件外，AS 6还提供了可选的通过认证的组件：RESTEasy 2.1.0——JAX-RS 1.1规范的实现；HornetQ 2.1.2——JMS 1.1规范的实现以及JBoss Web Services CXF栈——JAX-WS 2.2规范的实现。

主要特性就是对JBoss Injection框架的完整实现。这对于知足Java EE 6平台规范所要求的Resources、Naming以及Injection是相当重要的。Infinispan v4.2.0是个开源的数据网格平台，从CR1里程碑发布时就加入了，如今它也集成到了JBoss AS 6中，而且是默认的分布式缓存提供者。Infinispan公开了一个兼容于JSR-107的Cache接口，你能够将对象存储其中。JBoss AS 6服务器能够动态探测并注册到前端的apache httpd服务器。

对于性能来讲，JBoss AS 5与6之间有明显的变化。JBoss AS 6对启动性能的提高很明显，如今的平均启动时间是15秒。用户可以感受到这种改进，必定程度上是由于延迟了随AS一同发布的管理控制台应用的部署，转而以“按需”方式提供，同时还实现了Timer Service的延迟部署。Microcontainer（v2.2）的加强（包括新的注解扫描库的实现）极大下降了应用部署的时间。

1.4. jboss7特性

JBoss AS7可实现为云作好准备的架构，并可以使启动时间缩短十倍，提供更快的部署速度并下降内在的占用。JBoss Enterprise Application Platform 6的核心是JBoss Application Server 7的最新版本，该版本表明着Java应用服务器在从复杂和单一的形式转向更加轻便、模块化和敏捷的变革过程当中的一个意义重大的里程碑。该版本将使开发人员有从新思考如何开发和部署企业Java应用。

JBoss Application Server 7构建于先前版本的良好基础之上，并提供更出色的性能、更低的内存占用率、分布式管理和Java EE6 Web Profile认证。它的新能力包括：

l Java Enterprise Edition（EE）6 Web Profile认证，一种轻型的标准可移植Java EE，专为开发和部署丰富的交换式Web应用而进行了优化。

l Java上下文和依存关系插入（Java Context and Dependency Injection – CDI），这种标准化的统一框架支持类型安全的依存关系插入和定义完善的上下文生命周期，经过简化和优化代码的方式实现了代码的轻松编写、测试和维护。

l Arquillian测试，改善了对测试驱动式开发的支持，提供了远程和嵌入式组件测试，且不会生产完整企业Java容器所带来的没必要要复杂性。

l 构建于轻型的高度优化的模块化服务容器和新型域模型基础上，使JBoss Application Server 7可以从最小的设备扩展至更大的关键任务集群。

l 经过基于Eclipse的JBoss工具来提供开发人员工具支持，改善了对Java CDI、休眠、表明性状态传输和Web服务的支持。

l 全新的复杂域模型和丰富的管理API，可实现强大的服务器和集群自动化。

为何JBoss AS7 这么快

JBoss7项目lead Jason Green,最近在他的blog 上，回答了这个问题. 如下是这篇blog的译文：

用Ahmdahl法则(高效并行)而不是Moore定律(等待硬件能有更高的时钟频率)来设计JBoss7. 目前几乎每台台式机，笔记本和服务器都至少有两个CPU核心，并且多核的趋势还在继续。 CPU 时钟频率竞争的时代其实已经终结。因此软件也必需要适应这一趋势，充分利用硬件的计算能力。

JBoss AS进行了一次重大的改变来得到这一关键的演进(evolution).咱们重写了AS7,使得它的整个架构是一个全新的，高性能的和可管理的。在使人惊谈的工程师的努力下，咱们从在github上一个很小的原型，在一年多的时间里实现了今天看到的具备巨大工做量的遵循Java EE Web Profile标准的J2EE服务器(更不用说咱们在这期间发布了AS6,使得JBoss的用户能够早点获得关于EE6的新特性，新技术)。

在开始详细的解释之前，请容许我给出一些背景知识。应用服务器的核心问题是管理服务(service).在现代的应用服务器中几乎全部的部件都有生命周期，那就意味着在特定的时间点上，这个部件必须被启动，在之后的时间点，它必须被中止。咱们将全部具备生命周期的对象都看做是一个service.另一个service重要的属性是，service和service的之间的依赖关系会影响到相应service的生命周期。举个例子，servlet的service依赖于web server.另外，若是这个sevlet使用到其余的资源，好比数据库链接或者是EJB,那么它也依赖于这些资源，这些依赖的资源可用之后本身才能启动。但一个应用服务器启动或者部署时，它必须保证它可以按照正确的顺序将各类service启动。进一步，若是任何服务因为某种缘由中止了，它必须能中止全部依赖于这个service的其余sevice(以相对于启动相反的顺寻中止).这在单线程的环境下是一个简单的问题。

但JBoss AS7实在并行的启动和部署这些服务。这个复杂的问题经过咱们全新的服务容器解决: JBoss Modula Service Container. MSC是一个高级的并行状态机。它在运行中分析服务之间的依赖关系，而且在同一时间尽量多的启动服务，但同时又遵循服务间的依赖关系。这就意味着不只可以快速启动，并且可以并行的进行部署。

除了并行的service,JBoss AS7还有类模块化和并行的类加载技术。经过将类划分到恰当的类模块中，应用服务器能够天然地优化访问模式，仅仅查找一个点，就能够得到所须要的类。另外，因为限制了类模块之间的可见性，查找就没有没有那么大的开销。对于JBoss Modules, 类模块解析和查找的时间复杂度是O(1).全部的这些操做都有很高的并行性，甚至大部分的类定义也是并行的。

AS7对部署的处理也是高效的。一个主要的优化是咱们经过快速扫描部分class来对annotation信息进行索引。为了取得更好的效率，咱们容许模块预先生成空间效率指数(space efficient index)来更快的加载。另一个部署时的优化，是咱们谨慎的缓冲和再使用relection data，由于JVM在这方面不是颇有效率。

最后，另外一个重要的缘由我想强调的是咱们已经而且会继续会守护CPU和内存在启动和部署方面的使用状况(尽量的少占用内存和CPU，作到尽量的高效）。这就是在设计阶段就做出的好决定。一个有趣的例子是咱们再也不使用JAXB(或者其余内省机制驱动的绑定器)来解析只读一次的配置文件。JAXB或者其余采用内省机制的绑定器带来的是几乎用和真正作实际解析工做同样或者更到时间来处理如何解析。全部的这些意味着: 在AS5和AS6里处理XML的时间都比AS7的启动时间要长。

但愿这些内容可以更好的从大的方面理解AS7如何得到高效性得以快速启动，为何JBoss7与过去有很大的不一样。这篇博客只是一个开始，继续关注个人下一个blog,我将讨论Jboss7的roadmap

JBoss AS7中的新概念－域

JBoss AS7新加入了域（domain）的概念并实现了相关功能。域的提出及实现，其目的是使得多台JBoss AS服务器的配置能够集中于一点，统一配置、统一部署，从而在管理多台JBoss AS服务器时，实现集中管理。本文详细介绍如何使用AS7的这一新特性。

3.1. 域(Domain)的概念及其与群集(Cluster)的区别

对于使用过JBoss AS过往版本的用户，可能对AS所提供的群集功能已经很熟悉了，在理解域的时候可能会遇到困难。那么域和群集有什么区别，用处上有什么不一样呢？

总的来说，JBoss的群集的目的是提供：

l 负载平衡（Load Balance）

l 高可用（High Availablity）

而域的目的则是将多台服务器组成一个服务器组（Server Group），并为一个服务器组内的多台主机（Host）提供：

l 单点集中配置（经过一个域控制器，即Domain Controller，实现组内主机的统一配置）

l 单点统一部署，经过域控制器将项目一次部署至组内所有主机。

简单来说，群集的目标是让多台服务器分摊压力，当一台或多台服务器当机时，服务能够继续保持运转；而域的目标则是提供集中配置和管理多台服务器的能力。

在没有域的概念时，要想让群集内的多台服务器或几组服务器保持统一的配置，一个一个分别的去手工维护，是很是麻烦的事情，而域的引入解决了这一问题。

咱们能够理解域和群集的相互关系是"正交（orthogonal）"的：经过一横一竖这两条轴，JBoss AS为咱们在运维方面提供了强大的可扩展能力。

3.2. 实验

熟悉了AS7中Domain的设计理念，接下来动手实际作个实验，看看Domain是如何在AS7中工做的。

1.1.1. 准备工做

使用两台电脑作为实验器材，两台电脑的IP分别为10.0.1.3及10.0.1.18，分别运行JBoss AS7，并组成一个服务器组（Server Group）。其中，使用10.0.1.3这台机器作为域控制器（Domain Controller）：

如上图所示，两台主机分别被命名为”master“及”slave“。经过配置，将master与slave组成一个服务器组，名为'main-server-group'，其中master将作为这个服务器组的域控制器。

须要说明一点的是，服务器组(Server Group)能够由多台服务器(Host)组成，并不必定只有两台，因此不要被master及slave这样的名字给迷惑了，觉得一个服务器组仅支持一主一从两台hosts。

本文中由于只使用两台服务器作为实验器材，所以出于方便角度将它们分别命名为master及slave。

此外，在一个服务器组中，只有一台域控制器，在本实验中咱们将使用master这台机器作为domain controller。

1.1.2. 配置

AS7因为通过了从新设计，所以在目录结构与配置文件上面与前一版本有了很大不一样，对于熟悉了对AS6的配置和的人来说，使用AS7会接触很多新概念和新思路。为了清楚表达，我会将一些与AS6及之前版本不一样的地方作出必要的说明。

首先是bin目录中的内容：

在AS7之前版本中，用来启动JBoss服务的run.sh不见了，取而代之的是standalone.sh（独立运行模式）及domain.sh（域运行模式）。咱们稍后将使用domain.sh来运行JBoss AS7，但首先要将两台hosts配置好，接下来说解两台服务器的配置：

AS7的目录结构和前一版本有很大不一样，由于配置文件及其所在位置也有很大变更，下面是AS7的目录结构：

能够看到有一个名为"domain"的目录，看一下这个domain目录里面的内容：

这个目录中包含了AS7运行在domain模式下所需的配置及内容，其中名为“configuration”的目录里面含有咱们所须要的配置文件：

其中domain.xml和host.xml是咱们须要关注的内容。咱们须要对master及slave上面的配置文件分别进行配置：

从上图中能够看到，master的JBoss AS中须要配置domain.xml及host.xml两个文件，其中domain.xml是作为域控制器必须配置的内容，host.xml则是master及slave各自的JBoss AS都须要配置的文件。咱们先从master上面的配置看起：

3.2.1.1. Master上面的配置

3.2.1.1.1. domain.xml

这个文件里面有几个部分是值得咱们关注一下的：

# extensions - 这一部分定义了域中服务器在启动时须要加载的模块。AS7使用了全新设计的JBoss Modules来加载模块，大幅提升了服务器的启动。这一内容不是本文讲解重点，后续我会专门写一篇文章来介绍。目前了解到这一程度便可。
# profiles - profiles是domain中定义的一个核心概念，也是domain的核心组成部分。基于profiles，AS7便实现了域中各服务器的统一集中配置：用户可经过profile对各子系统（subsystem）进行配置，完成后将profile配置给某个或多个服务器组，各服务器组内的主机共用一份配置。
# server groups - 服务器组的概念已经在前面的介绍中一再说起，也是AS7的域的设计中一个核心组成部分。在这里，AS7默认定义了两个服务器组：main-server-group及other-server-group，它们分别使用'default' profile及'ha' profile。在本实验中，咱们将使用main-server-group。

3.2.1.1.2. host.xml

上面是一些host.xml中须要配置的关键内容，已经针对要作的测试作了一些配置上面的修改，如下是详细说明：

# host name按照咱们的须要改为了"master"。
# management - management定义了服务器的管理端口，其中：9999端口是所谓"native"二进制端口，后面的jboss-admin.sh管理命令会使用这个端口；9990则提供基于WEB页面的管理端。咱们等一下两种管理端口都会用到。
# domain controller - 定义本服务器所需链接的domain控制器所在地址，由于master自己就是domain controller，因此链接至本机localhost便可。
# interfaces - management及public接口服务所在的地址，咱们要将其设为slave能够访问到的IP地址，保证slave能够链接至host
# servers - 一个物理主机实际上能够同时运行多台JBoss AS7的Server，而每一台Server均可以配置到不一样的服务器组去。在本实验中，咱们使用最简的状况，master上面只跑一个server-one，属于main-server-group，把其它AS7默认设定的server能够都删掉，只留server-one。

3.2.1.2. Slave上面的配置

3.2.1.2.1. domain.xml

Slave这台机器不做为域控制器而存在，所以不须要管它，也能够将domain.xml删掉或更名。

3.2.1.2.2. host.xml

上面的配置有几点须要说明：

* slave里面，host name指定为"slave"。
* domain-controller：指定为master的IP：10.0.1.3，经过9999管理端口进行通信。
* slave上面，属于main-server-group的server也命名为"server-one"，这会和master上面的server冲突吗？实际上不会，由于两台一样名字的server运行在不一样的host当中。

3.3. AS 7.1的安全补充说明

从JBoss AS 7.1 开始，对控制端口（9999及HTTP端的9990）的安全配置成为必须。所以须要补充下述安全配置方面的步骤：

首先要在master上面建立管理员的帐号，在bin目录下有add-user工具能够帮咱们建立帐号密码并进行配置，咱们建立一个管理员帐号admin，密码为123123：

能够看到系统为咱们分别在domain和standalone建立了mgmt-users.properties，咱们是用域模式运行，所以查看domain/configuration/mgmt-users.properties这个文件的最后一行：

能够看到相关帐号密码已经被建立。此时查看host.xml：

能够发现host.xml已经把安全配置应用起来了，使用ManagementRealm这个安全域进行认证。

一样地，咱们须要在slave主机上进行如出一辙的工做。

接下来，咱们须要作一下slave对master的认证链接工做。slave要想和master创建域控关系，须要知道master的管理端帐号密码。在域控这一块，AS7对认证有要求：须要在域控制器上以过来链接的主机host名为用户名添加帐号。

咱们在slave的host.xml文件中指定了slave的host名为slave：

所以，master作为域控制器，须要在上面添加名为slave的管理员帐号，密码仍为123123：

master:~/projs/as7/710/bin$ ./add-user.sh

Enter details of new user to add.

Realm (ManagementRealm) :

Username : slave

Password :

Re-enter Password :

About to add user 'admin' for realm 'ManagementRealm'

Is this correct yes/no? yes

Added user 'slave' to file 'master/as7/710/standalone/configuration/mgmt-users.properties'

Added user 'slave' to file 'master/as7/710/domain/configuration/mgmt-users.properties'

这时再查看mgmt-users.properties，能够看到多了slave帐号：

接下来，咱们要在slave主机的的host.xml作下认证配置，使用这个帐号与master进行认证通讯：

上面的配置中有这些值得注意：

咱们在认证域ManagementRealm中配置了server-identities，这个认证域用在与域控制器master的链接方面。其中secret value是domain上对应slave主机名的那个帐号的密码，用base64加密。咱们在master上面配置的slave帐号的密码为123123，MTIzMTIz=则是123123的base64加密后的文字。这个配置用在链接domain-controller时进行认证：

有关更多的AS7的安全配置的信息，可查看官方文档：

关于host.xml的详细配置方法，也可参考as7目录下自带的xsd文档：

3.4. 部署

配置完成后，接下来便到了实际部署的阶段，咱们将master和slave上面的AS7分别用domain.sh启动起来。

启动成功的话，应该能够在master上面看到上面的日志，slave被成功的注册进来。

完成启动后，咱们须要将待使用的virtual-host启动起来，当AS7以domain的方式启动时，默认是不启动任何virtual server的（在我目前使用的7.0.0 CR1 White Rabbit版本中是这样），咱们能够在domain.xml中配置默认加载virtual-host，也能够在服务器运行起来后，使用管理端命令动态的加载，在这里我准备使用后一种方式，从而讲解AS7管理端的使用方法。

在AS7的bin目录下面有一个jboss-admin.sh，这是AS7提供的全新的管理工具，咱们使用这个工具，链接至master：

能够看到，咱们已经链接到了master的9999管理端口。接下来能够查看"default"这个profile当中的web模块的运行状况：

可见http服务器已经启动，因为咱们的"main-server-group"使用的是default这个profile，所以，服务器组中的两台host的web模块接受profile的统一配置，都是已启动的。继续看一下web模块中的细节：

注意到virtual-server的状态是未定义（undefined），咱们要想将一个web项目部署进服务器组中的各个host，就必须加载一个待部署的virtual-server，所以咱们使用命令来添加：

能够看到，咱们以前在domain.xml中配置的 "other.com" 这个 virtual host被成功添加了。

接下来是部署WEB应用的环节，咱们首先用maven制做一个最简单的web项目，仅包含一个欢迎页面：

生成的项目以下：

使用以下命令将项目打成WAR包：

获得war：

接下来是部署这个war包，对于本次实验来说，关键的部分在于可否经过domain提供的server group管理功能，一次将一个项目部署进server group中的多台服务器。咱们接下来就验证这点，顺便看下AS7提供的WEB管理功能，打开WEB浏览器，访问master的HTTP端口的管理地址：能够看到，管理页识别出AS7正运行在domain模式之下，而且目前共有两台主机运行（左上角的列表分别列有master及slave）。咱们要关注的是server-group：点击右上角的"Server Groups"，进入服务器组的管理页面，而后点击左边的"Manage Deployments"页面，进入部署功能页面：

能够看到，目前尚未任何资源被加至服务器组，此时点击右边的"Add Content"功能，将my-webpp.war添加进Content Repository（域控制器用于保存待部署资源的目录）。
添加完成后以下图所示：

而后点击"Add To Group"将my-webapp.war添加至 "main-server-group"，并将其enable，一切顺利的话结果以下所示：

此时咱们预期的结果应该是my-webapp.war被同时部署至master及slave了，分别试着访问master及slave的http资源，看看是否都部署上my-webapp这个应用了：

结果如咱们所预期的那样，两台服务器均可以访问到这个部署的资源。经过对一个点（Domain Controller）的配置与部署，咱们实现了多AS7服务器的集中管理。

3.5. 小结

经过域这个概念，实现了多服务器统一管理，统一配置，资源统一部署的目标。经过集中管理，咱们能够在此基础上再进行群集的划分与部署，实现群集内多台服务器的单点配置与管理。能够说AS7的Domain概念的引入，与群集的概念组合在一块儿，经过一横一从两条轴，造成了完整的坐标系。

4. JBoss7配置

4.1. 目标听众

这篇文档是为须要安装配置JBoss Application Server(AS7)的人员编写。

4.1.1. 开始以前

你须要知道如何下载，安装和运行JBoss Application Server7. 若是你还不了解这些信息，请参考“入门指导"。

4.1.2. 手册中的示例

手册种大部分的例子会使用部分XML配置文件或者是de-typed的管理模型进行表示。

4.2. 客户端

JBoss AS7提供三种不一样的方式对服务器进行配置和管理: web，命令行和xml 配置文件形式。不管你选择什么样的配置方式，配置信息都会被同步到各个方式的管理界面上，而且被存储到xml配置文件中。

4.2.1. web接口

web管理客户端是一个GWT的应用，它经过HTPP管理接口来管理域(domain)或者是单独运行(standalone)的服务器。

4.2.1.1. HTTP管理接入点

基于HTTP协议的管理接入点负责接入使用http协议与管理层进行交互客户端。它负责接收使用JSON编解码的协议和de-typed RPC形式的的api来对可管理的域服务器或者单独运行服务器进行管理操做。web控制台就是经过它来实现的，但基于HTTP协议的管理接入点也能够与其余的管理终端进行集成，交互。

基于HTTP协议的管理点会运行在域控制器(domain controller)或者是单独运行服务器上，默认运行在9990端口上。

基于HTTP协议的管理接入点运行在两个不一样的context下。一个用于运行管理的操做另一个提供对web管理接口的访问。

l 域API: http://<host>:9990/management

l Web控制台: http://<host>:9990/console

4.2.1.2. 访问管理控制台

管理控制台和基于HTTP协议管理的API在统端口上运行，能够经过如下URL进行访问：

l http://<host>:9990/console

4.2.1.3. 对管理控制台进行加密

web管理控制台经过HTTP管理接口来对服务器进行通讯。对于如何机密HTTP管理接口以及如何启用默认的安全域，请参考一下本文中关于“加密管理接口"章节。

4.2.2. 命令行接口

命令行方式的管理工具（CLI）提供了对域和单独运行服务器的管理。用户可使用命令行来链接域服务器或者单独运行服务器,经过传输de-typede的管理模型来执行管理操做。

4.2.2.1. Native管理接入点

Native的管理接入点负责接入使用AS内部协议与管理层进行交互的客户端.它使用基于java对象来描述的管理操做、二进制协议和RPC形式的API来对域和单独运行服务器进行管理操做。命令行方式的管理工具使用它来实现对服务器的管理，单Native管理接入点也提供了极强的集成能力，能够和其余的客户端进行集成。

Nativeg管理接入点运行在host控制器上或者是一个单独运行服务器上。若是使用命令行管理工具，Native管理接入点必须被启用.默认Native管理接入点运行在9999端口上：

4.2.2.2. 运行命令行管理工具

根据操做系统，使用JBossAS7 bin目录下的jboss-admin.sh或者jboss-admin.bat来启动命令行管理工具.关于AS7目录的详细信息，请参考"入门指南"。

命令行工具启动之后的第一件事情就是链接被管理的Jboss AS7实例。咱们经过命令connect进行：

localhost:9999 是JBossAS7域控制器客户端链接的默认主机和端口名.主机名和端口都是可选的参数，能够被单独或者一块儿指定。想要退出对话，能够键入quit命令来结束。

help命令用来显示参考帮助文档：

查看特定命令的详细帮助文档，须要在命令后加"--help"参数来得到。

4.2.2.3. 管理请求

管理请求容许与管理模型进行低级别的交互。它不一样于高级别的命令(好比建立一个jms的queue命令:create-jms-queue),使用管理请求能够对服务器的配置像对直接对xml配置文件进行编辑而进行读和修改操做。整个配置用一个有地址的资源树进行表示，这个树上的每一个节点提供一系列的操做供执行。

一个管理请求包含三个部分：地址，操做名和可选的操做参数

这是一个管理请求的规约：

举个例子：

管理请求字符串之间的空格是不敏感的。

4.2.2.3.1. 管理资源的地址

管理请求能够不含有地址信息和参数,好比::read-resource, 能够列出当前Node下的全部节点类型。

在管理命令中，为了消除歧义须要如下几个前缀：

l " : " --- 在当前节点上执行操做，好比：

[subsystem=web] :read-resource(recursive="true")

l " ./" ---- 在当前节点的子节点上执行操做,如：

[subsystem=web] ./connector=http:read-resource

这个操做的全路径地址是: subsystem=web,connector=http.

l " /" --- 在根节点上执行操做,如：

[subsystem=web] /:read-resource 或子节点: [subsystem=web] /subsystem=logging:read-resource

4.2.2.3.2. 操做类型和操做描述列表

操做的类型能够分为在任何节点上的通用操做和在特殊节点上的特殊操做(如:subsystem).通用的操做包括：

对于特殊操做列表（好比在logging子系统上能够进行的特殊操做),能够经过管理的节点进行查询。好比，查询一个单独运行服务器上logging子系统上所支持的操做：

能够看出，logging支持三个额外特殊的操做:change-root-log-level , set-root-logger and remove-root-logger

进一步关于被管理节点描述或者被管理节点上操做的描述，能够经过一下命令查询：

4.2.2.4. 命令行历史信息

命令行(和操做请求)历史信息默认是开启的。历史信息在内存中和硬盘文件中都有保存,而且命令行历史信息在命令行对话之间保存。

命令行历史信息文件信息保存在名为.jboss-cli-history的文件中，这个文件会在用户的home目录下自动建立。当启动命令行模式时，这个文件会被读入内存中来对初始化命令行历史信息。

在命令行对话中，你可使用上下键来向前和向后查阅命令行历史信息。

命令行历史能够经过history命令进行操做。若是history命令执行时不带参数，它会将内存中全部的历史命令和操做打印出来(取决于历史信息的最大个数，默认500). history 命令支持3个可选的参数：

4.2.2.5. 批处理

批处理模式容许用户以将一组命令和操做按照原子的方式执行。若是一个命令或者操做失败，那么在批处理中成功执行的子命令将会被回滚。

不是全部的命令均可以批处理种执行。好比: cd, ls, help等不能被转换成操做请求的就不能够在批处理种执行。只有能够转换成为操做请求的命令才能够在批处理种执行。批处理的命令其实是以组合操做请求的方式执行的。

执行batch命令进入批处理模式：

run-batch执行一个批处理：

退出批处理编辑模式而且不丢失更改：

稍后从新激活批处理：

还有一些比较重要的批处理命令(使用tab补全来查看如下列表)：

4.2.3. 配置文件

域管理和单服务器的xml配置能够在configuration子目录下找到：

一个被管理的域有两种类型的配置:一种是对整个域的配置(domain.xml)另一种是对每一个加入到域里主机(host)的配置(host.xml).关于如何配置域拓详细信息请参考"域配置"章节。xml配置是核心可靠的配置源。任何经过web接口或者命令行方式对配置的更改都持久化到XML配置文件中.若是一个域或者单独服务器离线,xml配置文件也能够进行手动更改，任何更改都在下一次启动时生效。

可是，咱们鼓励用户使用web接口或者命令行方式更改配置文件，而不是采用离线编辑的方式对配置文件进行更改。对正在处理的配置文件进行的外部更改将不会被探测到，从而有可能会被覆盖。

4.3. 核心管理概念

4.3.1. 运行模式

JBoss Application Server 7能够被启动到两个不一样的模式.域模式能够用来运行和管理多个jboss服务器的拓扑，或者是单服务器模式，仅运行一个服务器的实例

4.3.1.1. 单服务器模式

对于大多数的使用来讲，经过管理域实现的中心管理能力是不须要的。对于这些使用场景，一个jboss7的实例能够被运行成单服务器模式。一个单服务器的实例是一个独立的进程，像JBoss3 ,4,5 或6的实例，能够经过standalone.sh或者standalone.bat进行启动。

若是须要多个服务器的实例或者多服务器的管理，那么就须要用户来协调管理多个服务器。好比:在全部的单服务器上部署一个相同的应用，用户须要在每台服务器上进行操做。更为可能，用户会启动多个单独运行的服务器来组成高可用的集群，就像是使用JBoss 3, 4 5和6那样。

4.3.1.2. 管理域

JBoss7一个最重要的新特性就是能够经过一个管理点来管理多个JBoss7服务器实例.一个域包含一个DomainController进程（域的中心管理点），这些被管的服务器是这个域的成员。

在这个域里全部的服务器实例共享统一的管理策略，域控制器来保证每一个服务器都使用这一管理策略来配置。域能够横跨几个物理（或者虚拟)机器，全部的JBoss7服务实例运行在一个受HostController进程控制的给定主机（host)上。一个HostController的实例会被配置成为中心的DomainController.在每一个主机上的HostController能够与DomainController进行交互来控制运行在本身主机(host)上服务器实例的生命周期，而且帮助DomainController来管理。

当你经过domain.sh或者domian.bat来在一个主机上运行JBoss7管理域时，那么你的意图是去运行一个HostController，而且通常是至少运行一个JBoss7的服务器实例,并且在主机上的HostController应该被配置来充当DomainController.

下图是一个管理域的拓扑：

4.3.1.2.1. Host(主机)

上图中的每一个Host方框表明一个物理或者虚拟的主机。一个物理的主机能够包含零个，一个或者多个服务器实例(server instance)。

4.3.1.2.2. 主机控制器(HostController)

当domain.sh或者domain.bat在主机上运行时，一个叫HostController的进程也会被启动。HostContoller只负责管理服务器实例；它不会处理服务器实例的平常工做。HostController负责在本身的主机上启动中止单个服务器实例的进程，而且与DomainController进行交互来管理这些服务器实例。

HostController默认在主机文件系统中JBoss7安装目录下读取domain/configuration/host.xml文件。host.xml文件主要包含特定主机的信息：

主要是：

l 在安装要运行的JBoss7服务器的实例名。

l 关于HostContraller如何与DomainController联系，而且注册到DomainController种来获取配置的信息。这个配置信息能够是如何查找联系一个远端的DomainController,或者是告诉HostController自己就能够充当DomainController

l 特定于本地安装的各类配置信息，如在domain.xml里(见如下内容)中interface的配置信息能够被映射成host.xml中的IP地址信息。在domain.xml中的抽象路径信息能够被映射成host.xml的真实文件系统信息。

4.3.1.2.3. Domain Controller(域控制器）

一个HostController的实例被配置成整个域的中心管理点，就成为了DomainController.DomainController的主要负责维护域的管理策略，保证全部的HostController可以获取目前的配置信息，以及协同HostController来保证运行的服务器实例都根据当前的策略来配置。中心管理策略默认存储DomainController安装主机的domain/configuration/domain.xml中。

domain.xml必须位于运行Domain Controller Jboss7安装目录下的domain/configuration. 若是不做为Domain Controller运行的AS7则不须要这个文件;好比运行链接到远程DomainController的HostController的服务器。但不做为DomainController运行HostController的AS7安装中存在这个文件，也不会有影响。

domain.xml文件包括各类配置，在Domain下的JBoss7的实例能够配置各类profile去运行。一个profile的配置包含各类组成profile的subsystem的详细配置信息(好比，一个集成的jboss web实例就是一个subsystem,一个JBoss TS的事务管理器也是一个subsystem）.Domain的配置信息也包括在subsystem须要用到的socket组的定义。Domain配置信息也包含Server group的定义。

4.3.1.2.4. Server Group (服务器组)

Server group是一组被统一管理和配置的服务器实例。在一个管理域里，每一个服务器实例都是服务器组的一个成员(即便是一个组里只有一个服务器，这个服务器仍然是一个组的成员)。Domain Controller和Host Controller会保证在一个server group里全部的server具备一致的配置。这些服务器被配置成一样的profile,而且部署相同的内容。

一个domain能够有多个server group.上面的图示种给出了两个server group： "ServerGroupA"和“ServerGroupB"。不一样的Server group能够被配置成不一样的profile和部署不一样的内容:好比在一个domain在不一样层的服务器来提供不一样的服务。不一样的Server group也能够运行一样的profile，部署相同的内容；好比对应用进行升级时候，为了不整个服务不可用，能够首先对一个server group中应用进行升级,而后再对另一个sever group升级。

sever group定义的例子以下：

<server-group name="main-server-group" profile="default">

<socket-binding-group ref="standard-sockets"/>

</deployments>

</server-group>

一个server-group的配置包含如下不可缺省的属性：

l name -- server group名

l profile -- server运行在的profile名

另外，还有如下可选配置：

l socket-binding-group -- 定义在server group中用到的默认的socket binding group名，能够在host.xml里覆盖。若是在server-group里没有定义，那么必须在每一个server的host.xml里定义。

l deployments -- 在组服务器要部署的内容。

l system-properties -- 组服务器种要设置的全部的system properties

l jvm -- 在组服务器种默认的jvm设置。Host Controller将会合并在host.xml里提供的属性，而且用这些属性来启动服务器的JVM.详细配置信息选项请参考JVM配置。

4.3.1.2.5. Server (服务器）

在上述图表中的server表示一个实际的应用服务器实例。Server运行于独立域HostController的JVM进程中。Host Controller负责启动这一JVM进程。(在管理域里，终端用户不能直接从命令行里启动一个server进程)。

HostController合并整理domain.xml里的域配置信息和从host.xml上得到的主机配置信息。

4.3.1.3. 决定运行在单独服务器或者管理域上

什么用例适合管理域，什么适合单独服务器(standalone server)？管理域协调多个服务器的管理--经过JBoss7提供的中心节点，用户能够管理多个服务器,经过域管理的丰富功能来统一服务器的配置，经过协调方式将服务器配置变动(包括部署内容）在各个服务器上生效。

重要的是要理解选择管理域和单独服务器要根据你的服务器是如何管理的,而不是根据为终端用户请求提供什么样服务的能力。管理域和单独服务器的差异对于高可用集群也是十分重要的。理解高可用性对于运行的单独服务器和管理域是正交的。也就是说,一组单独服务器能够被配置成为高可用性集群。管理域和单服务器模式决定服务器是如何管理的，而不是他们所提供的功能：

因此,考虑到以上缘由：

l 若是只有一个服务器，运行在域模式下不会有更多的好处,运行在单服务器模式下是更好的选择。

l 对于多服务器生产环境，运行在域模式和单服务器模式下取决于用户是否想使用管理域提供的中心管理。某些企业已经开发出自有成熟的多服务器管理方式，而且可以轻松协调管理多个单独服务器。读于这些企业，由多个单独运行服务器组成的多服务器架构是一个好的选择。

l 单服务器更适合与大多数的开发环境。任何在管理域下运行的服务器的配置均可以在单服务器模式运行的服务器得到,所以即便应用是未来要运行在域管理模式的生产环境中，不少(几乎是所有)开发均可以在单服务器模式下进行。

l 运行管理域对于一些高级的开发是有帮助的。好比:须要多JBoss7服务器实例之间进行交互的开发。开发人员会发现配置多个服务器做为域成员是进行多服器集群的有效方式。

4.3.2. 通用的配置概念

如下通用的配置概念对于管理域模式和单服器模式都适用：

4.3.2.1. Extensions (扩展)

一个扩展(是一个能扩展服务器功能的模块）. JBoss 7的内核是简单清量级的。全部用户须要用到应用服务器的功能都是经过扩展提供的。一个扩展被打包成为在modules目录下的一个模块。用户若是须要一个特别的扩展，则须要在domain.xml或者standalone.xml里加入<extension/> xml元素来指明这个模块名。

4.3.2.2. Profile和subsystem(子系统 )

在domain.xml和standalone.xml配置中最重要的部分是一个(在standalone.xml)或者多个(在domain.xml里)profile的配置。一个profile是一个命名的子系统集合。一个子系统是使用一个扩展添加到和服务器核心的一组功能(参考以上的扩展)。一个子系统能够提供处理servlet的功能;一个子系统能够提供EJB容器，一个子系统能够提供JTA，等等。一个profile是命名的子系统的列表,而且包含各个子系统详细的配置信息。一个服务器拥有大量子系统的profile会提供丰富的功能.一个拥有数量少而且功能专一的子系统提供的功能相应减小，可是具备更少的内存消耗。

domain.xml和standalone.xml里关于profile的配置看上去大体相同，惟一的不一样是standalone.xml只容许有一个profile的xml元素(服务器运行的proifle）,但domain.xml能够有多个profile,每个profile能够映射到一个或者多个服务器组。

domain.xml和standalone.xml里关于子系统的配置是相同的。

4.3.2.3. Paths( 路径)

路径是一个文件系统路径的逻辑名。在doamin.xml,host.xml和standalone.xml配置种都包含用来来声明路径的部分。其余的配置能够经过逻辑名来引用这些路径，而不须要包含路径的全部所有信息(在不一样的机器都不相同).好比: logging子系统的配置包含对jboss.server.log.dir路径的引用来指向server的log目录:

<file relative-to="jboss.server.log.dir" path="server.log"/>

JBoss7自动提供一系列的标准路径，而不须要用户在配置文件中配置.

    jboss.home - JBossAS安装的跟目录
    user.home - 用户的home目录
    user.dir - 用户当前的工做路径
    java.home - java安装路径
    jboss.server.base.dir - 一个服务器实例的跟目录
    jboss.server.data.dir - 服务器存储数据的目录
    jboss.server.log.dir - 服务器日志文件目录
    jboss.server.tmp.dir - 服务器存储临时文件目录
    jboss.domain.servers.dir -host Controller在此目录为服务器实例建立的工做区(仅在管理域模式下)

用户能够经过在配置文件中使用<path>xml元素来增长本身的路径或者覆盖除了上面前五个路径的配置。

<path name="example" path="example" relative-to="jboss.server.data.dir"/>

Path的属性：

    name -- 路径名
    path -- 实际的物理文件系统名,若是没有relative-to的定义，将会被处理成为绝对路径.
    relative-to -- (可选)前面定义的路径名，或者系统提供的标准路径。
domain里<path>配置不能够包含path和relative-to属性,只须要name属性。

<path name="x"/>

上面这个配置的示例简单的说明:有意个叫"x"的路径，在domain.xml配置的其余部分能够引用。指向x的实际文件系统的路径是主机相关的，须要在每一个机器的host.xml里定义。若是这种在domain.xml里定义path的方式被使用，那么在每一个机器上host.xml里都须要path来有定义实际的文件系统路径:

<path name="x" path="/var/x" />

在standalone.xml里<path/>都必须包含实际文件系统的路径信息。

4.3.2.4. nterfaces (接口)

接口就是对socket能够绑定到的一个物理接口,IP地址或者主机名的逻辑命名。domain.xml,host.xml和standalone.xml的配置信息种都包行有接口声明的部分。其余部分的配置能够根据这些逻辑名来引用这些接口,而不须要包含这些接口所有详细的信息(这些接口信息在不一样的机器上不尽相同)。一个接口的配置包含接口的逻辑名，也包含解析这个接口名成为真实物理地址的信息。详细信息请参考接口和端口部分。

在domain.xml里<interface/>元素只须要name属性,不须要包含任何真实IP地址的信息:

<interface name="internal"/>
这样一个配置简单的代表:"有一个叫internal的接口在domain.xml的其余部分能够引用。指向internal的IP地址是和主机相关的，地址信息将会在每台机器的host.xml里指定。"若是使用这一方法，那么在每台机器上的host.xml里必须有interface元素来指定IP地址:

<interface name="internal">
<nic name="eth1"/>
</interface>

在standalone.xml里的<interface/>元素必须包含IP地址信息。

4.3.2.5. socket binding(socket绑定)和socket binding group(socket绑定组)

socket绑定是对一个socket命名的配置。
在doamin.xml,和standalone.xml配置种都包含用来来声明socket命名的部分。其余的配置能够经过逻辑名来引用这些socket，而不须要包含socket的全部所有信息(在不一样的机器都不相同).请参考interfaces和ports部分。

4.3.2.6. System Properties( 系统属性)

系统属性值能够在domain.xml, host.xml和standalone.xml里的多个地方设置.standalone.xml里设置的值会成为server启动进程的一部分。在domain.xml和host.xml设置的值将在serer启动时生效。

当在domain.xml或者host.xml里设置的一个系统属性，它是否可以最终被应用生效取决于它在什么地方被配置。若是系统属性做为在domain.xml里根节点下的一个子孙节点被设置，那么它将在全部的server上生效。若是在domain.xml中<server-group/>里的<system-property/>设置，那么它将在这个组里全部的server生效。在host.xml里根节点下做为一个子节点设置系统属性，那么它将在这个主机的host controller控制的全部server上生效。最后,在host.xml中<server/>里的<system-property>设置，那么它将在只在那个sever上生效。一样的属性能够被配置在多个地方:<server/> 中的值要优先于在host.xml根节点中直接定义的值，host.xml里定义的值要优先于任何domain.xml里的值，<server-group/>里定义的值要优先于经过domain.xml里根节点里定义的值。

4.3.3. Management resources( 管理资源)

当JBOss7在启动的时候解析配置文件，或者当使用AS7的管理接口的时候，都是在增长，删除或者修改AS7内部管理模型的管理资源。AS7的管理资源具备如下特征:

4.3.3.1. Address (地址)

全部JBossAS的管理资源都以树的结构进行组织。指向一个管理资源树节点的路径就是管理资源的地址。每一个资源地址的片断都是键值对:
    键是在双亲上下文中资源的类型.所以，单服务器模式运行的服务器根资源就有如下类型的子孙:子系统，接口，socket绑定等等。提供AS7web服务器能力的子系统就有类型是connector和virtual-server的子孙。提供AS7 消息服务器的子系统就有jms-queue和jms-topic类型的子孙节点。

   值给定类型特定资源的名字。好比:子系统里的web或者messaging, 子系统connector里的http或者https.
   管理资源的全路径是一个排好序的键值对的列表,这个地址能够指从资源数的根指向这个资源。地址中使用"/"来分割地址元素，使用"="来分割键和值:

    /subsystem=web/connector=http
    /subsystem=messaging/jms-queue=testQueue
    /interface=public

若是使用HTTP API,那么"/:来分割键和值而不是"=":

    http://localhost:9990/management/subsystem/web/connector/http
    http://localhost:9990/management/subsystem/messaging/jms-queue/testQueue
    http://localhost:9990/management/interface/public

4.3.3.2. operations( 操做)

查询更改一个管理资源的状态要经过一个操做。一个操做具备一下特征:

字符串名:

零个或者多个命名的参数.每一个参数都有一个字符串名和一个类型是org.jboss.drm.ModelNode值(或者当经过 CLI调用时，ModelNode用文本内容表示，经过HTTP APi调用时候，model node用JSON对象表示)。参数是可选的:

返回值也是一个类型是org.jboss.dmr.ModelNode的值(或者当经过 CLI调用时，ModelNode用文本内容表示，经过HTTP APi调用时候，model node用JSON对象表示)。

除了根节点的资源，每一个资源应该有一个remove操做("这里应该是由于在AS7.0时不少资源都没有)。 add操做的参数会根据资源而不一样。remove操做没有参数:

全局的操做都适用于全部的资源.详细内容请参考全局操做部分。

一个资源所支持的操做能够经过调用这个资源自己的一个操做得到:read-operation-names.一旦知道了操做的名，关于操做的参数和返回的详细信息就能够经过调用read-operation-description来得到。好比，在单独运行服务器上获取根节点资源所支持的操做名,而后获得一个操做所有的详细信息，在CLI中能够经过如下来得到:

[standalone@localhost:9999 /] :read-operation-names
{
    "outcome" => "success",
    "result" => [
        "add-namespace",
        "add-schema-location",
        "delete-snapshot",
        "full-replace-deployment",
        "list-snapshots",
        "read-attribute",
        "read-children-names",
        "read-children-resources",
        "read-children-types",
        "read-config-as-xml",
        "read-operation-description",
        "read-operation-names",
        "read-resource",
        "read-resource-description",
        "reload",
        "remove-namespace",
        "remove-schema-location",
        "replace-deployment",
        "shutdown",
        "take-snapshot",
        "upload-deployment-bytes",
        "upload-deployment-stream",
        "upload-deployment-url",
        "validate-address",
        "write-attribute"
    ]
}
[standalone@localhost:9999 /] :read-operation-description(name=upload-deployment-url)
{
    "outcome" => "success",
    "result" => {
        "operation-name" => "upload-deployment-url",
        "description" => "Indicates that the deployment content available at the included URL should be added to the deployment content repository. Note that this operation does not indicate the content should be deployed into the runtime.",
        "request-properties" => {"url" => {
            "type" => STRING,
            "description" => "The URL at which the deployment content is available for upload to the domain's or standalone server's deployment content repository.. Note that the URL must be accessible from the target of the operation (i.e. the Domain Controller or standalone server).",
            "required" => true,
            "min-length" => 1,
            "nillable" => false
        }},
        "reply-properties" => {
            "type" => BYTES,
            "description" => "The hash of managed deployment content that has been uploaded to the domain's or standalone server's deployment content repository.",
            "min-length" => 20,
            "max-length" => 20,
            "nillable" => false
        }
    }
}
如何获取一个资源所支持的操做请参考如下Description部分。

4.3.3.3. Attributes( 属性)

管理资源将它们的状态暴露成为属性。属性有string类型名，和一个类型是org.jboss.drm.ModelNode值(或者当经过 CLI调用时，ModelNode用文本内容表示，经过HTTP APi调用时候，model node用JSON对象表示)。
属性能够是只读或者是可读写的。读写属性值能够经过全局的read-attribute和write-attribute操做来进行。
read-attribute操做仅有一个"name"参数，它的值是这个atrribute的名。好比在sorkcet-binding资源里经过CLI来读port属性:

[standalone@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=https:read-attribute(name=port)
{
    "outcome" => "success",
    "result" => 8443
}
若是一个属性是可写的，资源的状态能够经过write-attribute操做来改变。这个操做接受两个参数:

    name – 属性名
    value – 属性值

好比在sorkcet-binding资源里经过CLI来设置port属性:

[standalone@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=https:write-attribute(name=port,value=8444)
{"outcome" => "success"}

属性能够有两种存储类型:

    CONFIGURATION – 表示属性值保存在持久化的配置中，好比管理资源配置要从这些文件读取的:domain.xml,host.xml或者standalone.xml.
    RUNTIME – 表示属性之日仅仅保存在运行的服务器中而不是持久化的配置中。好比一个metric(如已经处理的请求数)十一个RUNTIME属性一个典型的例子。

管理资源暴露出的全部属性值能够经过"read-resource"操做再加上“include-runtime=true"的参数来得到，好比经过CLI:

[standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "bytesReceived" => "0",
        "bytesSent" => "0",
        "errorCount" => "0",
        "maxTime" => "0",
        "processingTime" => "0",
        "protocol" => "HTTP/1.1",
        "requestCount" => "0",
        "scheme" => "http",
        "socket-binding" => "http",
        "ssl" => undefined,
        "virtual-server" => undefined
    }
}

省略include-runtime（或者设置成false)来限制仅仅存储在持久化配置上的值才被输出。

[standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource
{
    "outcome" => "success",
    "result" => {
        "protocol" => "HTTP/1.1",
        "scheme" => "http",
        "socket-binding" => "http",
        "ssl" => undefined,
        "virtual-server" => undefined
    }
}

参考一下Description相关部分来获取更多关于一个特定资源暴露出属性的信息。

4.3.3.4. Children（子节点)

管理资源能够支持子资源。一个资源孩子节点的类型(好比web子系统资源的connector子节点)能够经过查询资源的description来得到(参考如下Description部分)或者经过调用"read-children-types"操做。当你知道了子节点的类型，你就能够经过全局"read-children-types"操做和已知节点类型来得到所有子节点名。这个操做仅接受一个参数类型:child-type,它的值即便已知的子节点类型。好比，一个表示socketbinding 组的资源有孩子节点。使用CLI来得到这些子节点的类型和给定类型全部的资源:

[standalone@localhost:9999 /] /socket-binding-group=standard-sockets:read-children-types
{
    "outcome" => "success",
    "result" => ["socket-binding"]
}
[standalone@localhost:9999 /] /socket-binding-group=standard-sockets:read-children-names(child-type=socket-binding)
{
    "outcome" => "success",
    "result" => [
        "http",
        "https",
        "jmx-connector-registry",
        "jmx-connector-server",
        "jndi",
        "osgi-http",
        "remoting",
        "txn-recovery-environment",
        "txn-status-manager"
    ]
}

4.3.3.5. Descriptions(描述)

全部的管理资源都暴露用于描述管理资源属性，操做和子节点类型的元数据(metadata).经过调用一个或者多个被管理资源所支持的全局操做来获取.以上咱们给出了 read-operation-names, read-operation-description, read-children-types 和 read-children-names操做的例子。
read-resource-description 操做用来得到一个资源属性，子节点的详细信息。好比,经过CLI:

[standalone@localhost:9999 /] /socket-binding-group=standard-sockets:read-resource-description
{
    "outcome" => "success",
    "result" => {
        "description" => "Contains a list of socket configurations.",
        "head-comment-allowed" => true,
        "tail-comment-allowed" => false,
        "attributes" => {
            "name" => {
                "type" => STRING,
                "description" => "The name of the socket binding group.",
                "required" => true,
                "head-comment-allowed" => false,
                "tail-comment-allowed" => false,
                "access-type" => "read-only",
                "storage" => "configuration"
            },
            "default-interface" => {
                "type" => STRING,
                "description" => "Name of an interface that should be used as the interface for any sockets that do not explicitly declare one.",
                "required" => true,
                "head-comment-allowed" => false,
                "tail-comment-allowed" => false,
                "access-type" => "read-write",
                "storage" => "configuration"
            },
            "port-offset" => {
                "type" => INT,
                "description" => "Increment to apply to the base port values defined in the socket bindings to derive the runtime values to use on this server.",
                "required" => false,
                "head-comment-allowed" => true,
                "tail-comment-allowed" => false,
                "access-type" => "read-write",
                "storage" => "configuration"
            }
        },
        "operations" => {},
        "children" => {"socket-binding" => {
            "description" => "The individual socket configurtions.",
            "min-occurs" => 0,
            "model-description" => undefined
        }}
    }
}

注意在上述例子中的输入:"operations" => {}"。若是命令行已经包含参数operation=true,(好比 /socket-binding-group=standard-sockets:read-resource-description(operations=true))，那么操做的结果会包含这个资源所支持的每一个操做的描述。

关于被管理资源上运行read-resource-description和其余全局操做所支持的其余参数的详细信息，请参考全局操做部分。

4.3.3.6. 和JMX Beans相比

JBossAS管理的资源在概念上和Open MBeans极为类似。他们有一下主要的几点不一样:

JBossAS的管理资源经过树形结构进行组织。资源地址的键值顺序是不一样的，由于它定义了被管理资源在数形结构上的位置,而JMX ObjectName的key属性顺序不是很重要。
Open MBean属性的值，操做参数的值和操做的返回值，必须是JDK规定的简单类型(String,Boolen,Integer等等) 或者实现了javax.management.openmbean.CompositeData 或者 javax.management.openmbean.TabularData的对象。JBossAS管理资源的属性值，操做参数值和操做的返回值都是org.jboss.dmr.ModelNode类型。

4.3.3.7. 管理资源树的基本结构(management resource trees)

如同以上提到的，被管理资源以树形结构组织。数的结构决定于你运行在单服务器模式仍是管理域模式。

4.3.3.7.1. 单服务器模式(Standalone server)

单服务器模式下管理树的树形结构和standalone.xml配置文件的十分类似：

根节点资源:
   extension – 在服务器上安装的扩展。
   path – 服务器上可用的路径。
   system-property – 配置文件中设置的系统属性 (如不在命令行种设置的属性)
  core-service=management – 服务器中核心的管理服务。
  core-service=service-container – JBoss7的最核心资源JBoss MSC ServiceContainer
ubsystem – server上安装的子系统.大部分的管理模型都是子系统类型的子节点。
interface – 接口配置
socket-binding-group – server上socket绑定组的中心资源
socket-binding – 单个socket绑定的配置
deployment – server上已经部署的内容

4.3.3.7.2. 管理域模式 (managed domain)

在管理域模式下，管理资源树会跨越整个域，包含域范围的配置(如在domain.xml上定义的配置),和主机相关的配置(如在host.xml配置的内容)以及每一个运行应用服务器暴露出的管理资源。在管理域中Host Controller进程提供对整个资源树的访问.若是Host Controller是主Domain Controller，那么资源树中对于每一个主机相关信息都是可获得的,若是Host Controller是远程Domain Controller的从属(slave)，那么仅与Host Controller所在的host相关部分的资源树的是能够访问的。

整个域的根资源以下。这些资源包括它的子孙，除了host类型都会被持久化到domain.xml中。
   extension – 域模式上运行的扩展。
   path – 在域中可用的路径。
   system-property – 配置文件中设置的系统属性 (如不在命令行种设置的属性),能够在整个域里使用
   profile – 一组子系统的设置，能够分配给server group
   subsystem – 子系统的设置,能够组成profile.
   interface – 接口配置
   socket-binding-group –socket绑定组设置，能够被sever group使用。
   socket-binding – 单个socket绑定的配置
   deployment – 可用的部署内容，能够分配给sever group. deployments available for assignment to server groups
   server-group – server group配置
   host – 单独的Host Controller.每一个host类型的节点都表明是特定主机的根资源。host和host的子孙节点的配置会被持久化存储到主机的host.xml文件中。
   path – 主机服务器上可用的路径
   system-property – 主机服务器配置文件中设置的系统属性
   core-service=management – Host Controller的核心管理服务。
   interface – 能够被Host Controller和主机上服务器使用的接口配置。
   jvm – 用来启动服务器的JVM设置
   server-config – 配置HostController如何启动sever;配置使用什么server group，和覆盖在其余资源上定义的和服务器相关的配置项。
   server – server的根资源.sever和一下资源不会直接被持久化；在域范围和主机级别的持久化的yuan ,组成了server的配置。
   extension – 在服务器上安装的扩展。
   path – 服务器上可用的路径。
   system-property – 配置文件中设置的系统属性 (如不在命令行种设置的属性)
   core-service=management – 服务器中核心的管理服务。
   core-service=service-container – JBoss7的最核心资源JBoss MSC ServiceContainer
   subsystem – server上安装的子系统.大部分的管理模型都是子系统类型的子节点。
   interface – 接口配置
   socket-binding-group – server上socket绑定组的中心资源
   socket-binding – 单个socket绑定的配置
   deployment – server上已经部署的内容

4.4. 管理任务

4.4.1. 网络接口和端口

4.4.1.1. 网络接口声明

JBoss AS 7 在整个配置文件中都引用命名的接口。一个网络接口经过指定一个逻辑名和选择一个物理接口来声明。
[standalone@localhost:9999 /] :read-children-names(child-type=interface)
{
   "outcome" => "success",
   "result" => [
       "management",
       "public"
   ]
}
以上操做意味着server声明了两个接口:一个可使用”management”进行引用，另一个能够用”public”引用。管理层（好比HTTP管理点)须要用到的全部组件和服务均可以使用”management”接口。与网络通信有关的应用(如Web, Message等等)均可以使用”public”接口.接口的名字没有任何特别的要求；能够用任何名字声明接口。配置的其余部分能够用逻辑名来引用这些接口，而不用包含接口的全部详细信息（在管理域里服务器上的这些信息随着机器不一样而不一样).
domain.xml, host.xml 和standalone.xml 都包含声明接口的部分。但咱们看这些在xml文件中接口声明时，就会发现接口的选择条件(selection criteria)。接口选择的条件有两种类型:一种是单独的xml元素，接口绑定到通配符地址；另一种是接口或者地址有一个或者多个特征值须要知足。下面是一个接口条件选择的例子，每一个接口都有特定的IP地址:
<interfaces>
<interface name="management">
   <inet-address value="127.0.0.1"/>
</interface>
<interface name="public">
   <inet-address value="127.0.0.1"/>
</interface>
</interfaces>
另一些使用通配符的例子:
<interface name="global">

<any-address/>
</interface>

<interface name="ipv4-global">

<any-ipv4-address/>
</interface>

<interface name="ipv6-global">

<any-ipv6-address/>
</interface>

<interface name="external">
<nic name="eth0"/>
</interface>

<interface name="default">

<subnet-match value="192.168.0.0/16"/>
<up/>
<multicast/>
<not>
     <point-to-point/>
</not>
</interface>

4.4.1.2. Socket Binding Groups

AS7中socket的配置相似于interface的声明,Sockets用一个逻辑名来声明，能够在整个配置中引用。多个Sockets声明能够用一个特定的名字声明成为一个组。这样在配置一个在管理域里的server group时能够方便的引用一个特定的socket binding group. Socket binding group经过interface逻辑名来引用interface:
<socket-binding-group name="standard-sockets" default-interface="public">
   <socket-binding name="jndi" port="1099"/>
   <socket-binding name="jmx-connector-registry" port="1090"/>
   <socket-binding name="jmx-connector-server" port="1091"/>
   <socket-binding name="http" port="8080"/>
   <socket-binding name="https" port="8443"/>
   <socket-binding name="jacorb" port="3528"/>
   <socket-binding name="jacorb-ssl" port="3529"/>
   <socket-binding name="osgi-http" port="8090"/>
   <socket-binding name="remoting" port="4447"/>
   <socket-binding name="txn-recovery-environment" port="4712"/>
   <socket-binding name="txn-status-manager" port="4713"/>
   <socket-binding name="messaging" port="5445"/>
   <socket-binding name="messaging-throughput" port="5455"/>
</socket-binding-group>
一个socket binding 包含一下信息:

name – socket配置的逻辑名，能够在配置的其余任何地方引用。

port – 这个配置中socket要绑定到的基础端口 (注意server能够经过配置增减全部端口值来覆盖这一配置)

interface （可选) – 配置中socket要绑定接口的逻辑名 (参考上面的接口声明 ) .若是没有指定， socket binding group 配置元素中的default-interface属性值将会被使用。

multicast-address (可选) --若是socket用于多播，将会使用这个多播地址。

multicast-port (可选) – 若是socket用于多播，将会使用这个多播端口

fixed-port (可选, 默认是false) – 若是是true, 端口值将一直使用这个值，这个值不会被使用增减端口值而覆盖。

4.4.2. 管理接口的安全性

除了在运行服务器或者服务器组上的各类服务，JBoss7还提供了两个管理接口容许远程的客户端能够管理JBoss AS7.这个章节中介绍如何使用这些接口，以及如何对这些接口进行加密。
这两个管理接口被暴露成一个HTTP接口和一个Native接口。HTTP接口既用来提供基于GWT的管理控制台(admin console)使用，也提供给使用JSON编码协议和de-typed RPC API各类管理操做使用。当运行在单独运行服务器(standalone)时候，Native接口容许管理操做经过私有的二进制协议访问。这种使用二进制协议类型的操做能够经过AS7提供的命令行工具，也能够经过使用AS7jar文件的远程客户端进行交互。
在管理域下使用这些接口稍有些负责。在每个主机上都有一个host controller的进程。在主机上的host controller会配置成为domain controller.在管理域中能够用一样的方式来使用HTTP接口; HTTP接口容许基于GWT的管理控制台(admin console)运行在主domain controller，也容许任何基于HTTP和JSON的管理控制客户端在任何host controller上执行管理操做。然而其余的一些客户端则使用Natvie接口：一旦host controller启动真正的应用服务器实例，这些应用服务器则经过native接口与host controoler后台创建链接；从host controller则使用native 接口与主domain controller在后台创建链接来获取domain 模型的拷贝，并随后接收主domain cotroller的操做请求。

4.4.2.1. 初始化设置

单独运行服务器的接口配置在standalone.xml里定义，在管理域里运行服务器的接口配置在host.xml 中。在两个文件中，接口配置都有相同的结构:
<management>
   ...
   <management-interfaces>
      <native-interface interface="management" port="9999" />
      <http-interface interface="management" port="9990"/>
   </management-interfaces>
</management>
...
<interfaces>
   <interface name="management">
      <inet-address value="127.0.0.1"/>
   </interface>
   <interface name="public">
      <inet-address value="127.0.0.1"/>
   </interface>
</interfaces>
navtive接口默认监听9999端口，http接口监听9990.管理接口同时与一个命名为 “management”的网络接口(network inteface)相关联。虽然management网络接口(network interface)的配置和public 网络接口的默认配置相同，但咱们推荐不要合并这两个配置。managment和public的网络接口分开配置能够保证任何将应用服务器中服务更为公开的配置更改，不会无心识的公开本不须要公开的管理接口。

4.4.2.2. 快速配置

在本章节剩下的部分咱们讲更为详细的讲述安全域的配置-可是若是你想快速的启用安全域而且完善安全配置来知足需求，默认的配置包含一个预先定义的安全域，它基于一个property文件和一个能够经过命令行来启用的脚本。
安全域定义在standalone.xml或者host.xml文件中<management>元素. 默认的安全域:
<management>
   <security-realms>
      <security-realm name="PropertiesMgmtSecurityRealm">
         <authentication>
            <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir" />
         </authentication>
      </security-realm>
   </security-realms>
   ...
</management>
默认安全域经过调用在configuratiion目录下的mgmt-user.properties来校验链接的用户。property文件默认没有任何用户，所以新的用户要用username=password格式添加到文件中:
手动启用两个接口配置好的管理域:
<management>
   ...
   <management-interfaces>
      <native-interface interface="management" port="9999" security-realm="PropertiesMgmtSecurityRealm" />
      <http-interface interface="management" port="9990" security-realm="PropertiesMgmtSecurityRealm"/>
   </management-interfaces>
</management>
这将为Http interface启用Http Digest authentication,而且在Native interface启用Digest SASL-这也意味着对于原始密码不会在客户端和服务器端进行传输验证。
使用脚原本启用安全域，首先要编辑“mgmt-users.properties”,由于配置会立刻生效。你须要至少定义一个用户，而且执行如下命令:
对于单独运行的服务器:
./jboss-admin.sh --connect --file=scripts/secure-standalone-mgmt.cli
对于在管理域的服务器:
./jboss-admin.sh --connect --file=scripts/secure-host-controller-mgmt.cli
注意这个脚本只能运行在默认配置为master的host上。若是建立了其余具备不一样名称的host，那么须要更新这个脚本或者手动对这个新的配置实施安全性。而且还要注意，这个脚本仅仅改变它要运行的名为master的host,若是有多个host controller,这个脚本须要使用他们全部正确的host名字运行去更改。同时，请阅读这个章节的其余部分关于如何配置从host controller链接主host controller的校验。

禁用JMX远程访问
除了以上的JBoss管理协议，还有容许JDK和应用管理操做的远程JMX 链接。为了安全性，能够经过删除远程链接配置来禁止这一服务，或者删除整个subsystem.
<subsystem xmlns="urn:jboss:domain:jmx:1.0">

<jmx-connector registry-binding="jmx-connector-registry" server-binding="jmx-connector-server" />
</subsystem>

4.4.2.3. 详细配置

管理接口的配置在<management>下的三个节点中:
<management>
   <security-realms />
   <outbound-connections />
   <management-interfaces />
</management>
<security-realms /> - 配置一个或者多个安全域来定义远程用户如何链接到服务器进行验证，而且定义服务器上的身份(identity)。
<outbound-connections /> -有时候安全域的配置须要链接到一个外部的资源；这些链接在这里配置。
<management-interfaces /> - 这里定义Http interface和Native interface，正如咱们在简介里描述的那样。

4.4.2.3.1. 管理接口

对于单个管理接口的配置是最简单的。仅仅须要配置管理接口的”security-realm”属性，来指定使用安全域的名字。由于管理接口启动安全域时，要查询安全域所提供的功能，而且启动安全相依的传输:好比用户的密码若是能够从安全域中得到，Http interface会尝试使用Digest验证，若是用户密码不能从安全域中获取，http interface会转而支持Basic验证。
<management>   ...
   <management-interfaces>
      <native-interface ... security-realm="PropertiesMgmtSecurityRealm" />
      <http-interface   ... security-realm="PropertiesMgmtSecurityRealm"/>
   </management-interfaces>
</management>
管理接口可使用一样的安全域，但这不是必须的。若是须要，不一样的管理接口可使用不一样的安全域。

4.4.2.3.2. 安全域

<security-realms /> 元素用来配置一个或者多个安全域。安全域的配置具备如下结构:
<management>
   <security-realms>
      <security-realm name="SampleRealm">
         <server-identities />
         <authentication />
      </security-realm>
   </security-realms>
   ...
</management>
<server-identities />元素定义server的身份信息。目前能够配置一个SSL身份(identity)来定义服务器如何从一个keystore 取得身份信息。也能够配置一个加密的身份-服务器使用什么样的命令或密码和其余的服务器进行通讯。
<authentication /> 定义如何验证链接到服务器的用户

4.4.2.3.2.1 Authentication(验证)

最初，AS7支持三种机制来验证链接到服务器的用户:
LDAP – 使用LDAP 服务器来验证用户的额身份信息。
Users – 定义在domain model里的用户名和密码信息，这仅做为简单测试使用。
Properties – 用户名和密码定义在一个服务器安装文件目录的 property文件中。
下表归纳了管理接口支持的验证机制，用来对终端用户在传输级别上进行验证:

Authentication Mechanism	HTTP Interface	Native Interface
LDAP	HTTP BASIC	Not Supported¹
Users	HTTP DIGEST	SASL DIGEST
Properties	HTTP DIGEST	SASL DIGEST

1 – 将被增长到AS7-1167
HTTP Basic和SASL Plain(实现之后)在一个表单里传输用户密码，很容易被破解。
下面的章节阐述如何配置这些验证机制:

4.4.2.3.2.1.1 LDAP

LDAP验证操做首先要创建一个和远程目录服务器的链接。而后使用用户提通的用户名去执行查找区别用户的识別名(distinguished name)。最后验证器和目录服务器创建一个新的链接，使用查找到的识別名和用户提供的密码来验证是不是合法用户。
这是一个使用LDAP验证的安全域配置:
<security-realm name="TestRealm">
   <authentication>
      <ldap connection="ldap_connection" base-dn="CN=Users,DC=mydomain,DC=aslab" username-attribute="sAMAccountName" />
   </authentication>
</security-realm>
ldap元素能够配置如下属性:
connection - 定义在 <outbound-connections>的链接来链接到LDAP目录服务器。
base-dn - 开始搜索用户的上下文中的识别名(基准识别名).
Username-attribute – 目录中的用户名的属性，用来匹配提供的用户名
recursive (default - false) - 是否须要迭代查找
user-dn (default - dn) - 用户中存放识别名的属性，用来校验用户信息

4.4.2.3.2.1.2 User

User校验器是一个对存储在domain model里用户名和密码进行验证的简单校验器。校验器仅用做简单的测试使用:
这是一个使用User验证器的例子:
<security-realm name="TestRealm">
   <authentication>
      <users>
         <user username="TestUser">
            <password>TestUserPassword</password>
         </user>
      </users>
   </authentication>
</security-realm>
在这个配置中，每一个用户都用<user>进行定义，用户名使用”username” 属性定义，password定义在user下的<password>中。

4.4.2.3.2.1.3 Properties

Properties校验器和User校验器相似，除了用户名和密码定义在一个properties文件中。比起 User校验的优势是password没必要在domain model中暴露。
这是一个使用properties验证器配置安全域的一个例子:
<security-realm name="TestRealm">
   <authentication>
      <properties path="users.properties" relative-to="jboss.server.config.dir" />
   </authentication>
</security-realm>
Properties文件经过简单定义”path”属性来指定文件的路径和 ”relative-to”属性来引用定义好的路径和path属性相对的路径。在这个例子中，user.properties在存放stadnalone.xml文件相同的目录下。若是”relateive-to”属性没有指定，那么path属性的之必须是一个绝对路径。

4.4.2.3.2..2 Server Identities（服务器身份)

<server-identities>用于配置在多种场景中服务器辨别本身身份的信息。目前在HTTP interface中能够定义一个SSL indentiy而且使用这一indentity来启用SSL，另一个Secret identity能够存放一个密码，当host controller和远程的domain controller 创建链接时，使用这一个定义好的Secret indentity.

SLL

SSL identity的配置目前须要从本地文件系统中加载一个静态的keystore.之后会加强这一个功能来容许多种类型的keystore:
一个SSL indentity的配置示例以下:
<security-realm name="TestRealm">
   <server-identities>
      <ssl>
         <keystore path="server.keystore" relative-to="jboss.server.config.dir" password="keystore_password" />
      </ssl>
   </server-identities>
</security-realm>
keystore的路径信息和properites验证器中properties文件信息相同，使用一个路径指定keystore和一个可选的relative-to 属性来指定path属性相对于一个已知的路径。

Secret

从domain controller链接到一个加密的主domain controller时，须要配置Secret identity.
为了实现链接加密的主domain controoler,下面是在从domain controller中增长的配置：

<host xmlns="urn:jboss:domain:1.0"
      name="slave">

   <management>
      <security-realms>
         <security-realm name="TestRealm">
            <server-identities>
               <secret value="c2xhdmVfcGFzc3dvcmQ=" />
            </server-identities>
         </security-realm>
       </security-realms>
       ...
    </management>

    <domain-controller>
       <remote host="127.0.0.1" port="9999" security-realm="TestRealm" />
    </domain-controller>

    ...
</host>
这里<remote>定义了domain controller引用了一个定义好的安全域。，这个引用意味着这个安全域会被用来加载客户端的配置（之后这将会扩展使得域也一样能够为客户端的链接定义SSL)
secret是密码采用Base64编码，链接会使用host名（在这个示例中是'slave')和从secret中获得的密码进行验证。
AS7-1102列出了密码的处理将会被加强，来更好的保护密码的配置。如采用密码混淆，加密方式以及使用外部的security provider, smart card或者使用 PKCS#11的硬件加密模块。

4.4.2.3.3. Outbound connections(外部链接)

如前面所述，外部链接用来链接一个远程的服务器，目前仅支持LDAP链接，之后会增长数据库链接来支持对存储在数据库中的信息进行验证。

LDAP

下面是一个链接LDAP服务器的例子:
<outbound-connections>
<ldap name="ldap_connection" url="ldap://127.0.0.1" search-dn="CN=AS7 Test Server,CN=Users,DC=mydomain,DC=aslab" search-credential="AS_Password" />
</outboundconnections>
<ladp>能够配置如下属性:
name - 链接名，ladp验证其会使用这个名字来引用这个链接。
url – 链接目录服务器的URL.
search-dn - 用户初始化搜索的识别名
search-credential – 链接进行搜索的密码
initial-context-factory (default - com.sun.jndi.ldap.LdapCtxFactory) -用来创建链接的 initial context factory

4.4.2.4. 问题

Application server如何链接到host controller的native interface上-是如何进行验证的?
当JBossAS7进程启动时会建立一个随机的key而且将这个key传输到启动的服务器实例，applicaiotn server使用这个key来验证native interface的链接。

4.4.3. JVM设置

管理域和单独运行服务器的 JVM设置是不相同的。在管理域中， domain controller组件会负责中止和启动服务器进程，所以由它来决定 JVM的设置。在单独运行服务器中，由启动服务器的进程 (好比经过命令行参数 )负责 JVM的设置。

4.4.3.1. 管理域

在管理域里， JVM设置能够在不一样的做用域上声明 :好比在特定的服务器组，一个主机或者一个特别的服务器。若是没有显式声明， JVM设置从父做用域继承。这样能够在不一样的层次上容许定制或者继承 JVM设置。

咱们来看一下对一个服务器组 JVM的声明 :

<server-groups>

       <server-group name="main-server-group" profile="default">

           <jvm name="default">

               <heap size="64m" max-size="512m"/>

           </jvm>

           <socket-binding-group ref="standard-sockets"/>

       </server-group>

       <server-group name="other-server-group" profile="default">

           <jvm name="default">

               <heap size="64m" max-size="512m"/>

           </jvm>

           <socket-binding-group ref="standard-sockets"/>

       </server-group>

</server-groups>

_{(参见 domain/configuration/domain.xml} ₎

在这个例子里，服务器组 "main-server-group" 的 jvm设置成 64m的 heap size和最大是 512m的 heap size.任何属于这个组的服务器都会集成这些 JVM设置。你能够改变整个组，或者一个特定服务器，主机的 JVM设置 :

<servers>

       <server name="server-one" group="main-server-group" auto-start="true">

           <jvm name="default"/>

       </server>

       <server name="server-two" group="main-server-group" auto-start="true">

           <jvm name="default">

               <heap size="64m" max-size="256m"/>

           </jvm>

           <socket-binding-group ref="standard-sockets" port-offset="150"/>

       </server>

       <server name="server-three" group="other-server-group" auto-start="false">

           <socket-binding-group ref="standard-sockets" port-offset="250"/>

       </server>

</servers>

_{(参考 domain/configuration/host.xml)}

在这个例子中， server-two 属于 main-server-group，所以会继承名字为 default的 JVM设置，可是它在 server-two服务器上声明了一个较低的 maxium heap size。

[domain@localhost:9999 /] /host=local/server-config=server-two/jvm=default:read-resource

   "outcome" => "success",

   "result" => {

       "heap-size" => "64m",

       "max-heap-size" => "256m",

4.4.3.2. 单独运行服务器

对于单独运行的服务器，则须要在执行 $JBOSS_HOME/bin/standalone.sh 脚本时使用命令行参数来设置 JVM，或者在 $JBOSS_HOME/bin/standalone.conf 声明。 (对于 windows用户，须要执行 %JBOSS_HOME%/bin/standalone.bat 和设置

%JBOSS_HOME%/bin/standalone.conf.bat.)

4.4.4. 命令行参数

启动 JBoss AS7的管理域，须要执行 : $JBOSS_HOME/bin/domain.sh 脚本，启动单独运行的服务器须要执行 $JBOSS_HOME/bin/standalone.sh . 使用这两个脚本启动时，将会使用默认的设置。如下内容，咱们讲介绍如何经过额外的命令行参数来覆盖这些默认的设置。

4.4.4.1. 系统属性

单服务器和管理域模式都使用用来设置标准位置 (如 jboss.home.dir,jboss.server.config.dir)的默认设置， B这小节中介绍这些系统属性的默认值。每一个系统属性，均可以经过标准的 JVM设置方式 -Dkey=value覆盖：

$JBOSS_HOME/bin/standalone.sh -Djboss.home.dir=some/location/AS7/jboss-as \

    -Djboss.server.config.dir=some/location/AS7/jboss-as/custom-standalone

以上的命令行启动一个不是标准的 AS home目录，而且使用一个特定的配置文件路径 . 具体系统属性的含义将在如下内容中介绍。

同时，你也可使用一个 properties文件经过下面任何一种方式来覆盖配置默认的系统属性 :

$JBOSS_HOME/bin/domain.sh --properties=/some/location/jboss.properties

$JBOSS_HOME/bin/domain.sh -P=/some/location/jboss.properties

这个 properties文件是一个标准的包含 key=value对的标准 Java property文件 :

jboss.home.dir=/some/location/AS7/jboss-as

jboss.domain.config.dir=/some/location/AS7/custom-domain

4.4.4.2. 单独运行模式（ Standalone)

属性名	说明	默认值
`java.ext.dirs`	指定 JDK extension路径	`null`
`jboss.home.dir`	JBoss AS 7 安装的根目录	`standalone.sh` 设置为 `$JBOSS_HOME`
`jboss.server.base.dir`	server的 base目录	`jboss.home.dir` /standalone
`jboss.server.config.dir`	base configuration目录	`jboss.server.base.dir` /configuration
`jboss.server.data.dir`	用于存放持久化数据的目录	`jboss.server.base.dir` /data
`jboss.server.log.dir`	`存放` `server.log` 的目录	`jboss.server.base.dir` /log
`jboss.server.temp.dir`	临时文件目录	`jboss.server.base.dir` /tmp
`jboss.server.deploy.dir`	部署目录	`jboss.server.data.dir` /content

4.4.4.3. 管理域模式 (Managed Domain)

属性名	说明	默认值
`jboss.home.dir`	The root directory of the JBoss AS 7 installation.	`domain.sh` 设置为 `$JBOSS_HOME`
`jboss.domain.base.dir`	domain的 base目录	`jboss.home.dir` /domain
`jboss.domain.config.dir`	base configuration目录	`jboss.domain.base.dir` /configuration
`jboss.domain.data.dir`	用于存放持久化数据的目录 .	`jboss.domain.base.dir` /data
`jboss.domain.log.dir`	`存放` `host-controller.log` 和 `process-controller.log` 文件的目录	`jboss.domain.base.dir` /log
`jboss.domain.temp.dir`	临时文件目录	`jboss.domain.base.dir` /tmp
`jboss.domain.deployment.dir`	部署目录	`jboss.domain.base.dir` /content
`jboss.domain.servers.dir`	被管服务器输出存放的目录	`jboss.domain.base.dir` /log

4.4.4.4. 其余命令行参数

第一种接收参数的格式是 :

--name=value

好比 :

$JBOSS_HOME/bin/standalone.sh --server-config=standalone-ha.xml

若是参数名是一个单词，那么使用一个” -”前缀，而不是两个” --”:

-x=value

好比 :

$JBOSS_HOME/bin/standalone.sh -P=/some/location/jboss.properties

下面说明在单服务器和管理域模式下可用的的命令行参数 :

4.4.4.4.1. 单服务器模式（ Standalone）

参数名	缺省的默认值	值
`--server-config`	`jboss.server.config.dir` /standalone.xml	一个相对于 `jboss.server.config.dir 的路径或者是一个绝对路径`

4.4.4.4.2. 管理域模式 (Managed Domain)

参数名	缺省的默认值	值
`--domain-config`	`jboss.domain.config.dir`/domain.xml	一个相对于 `jboss.domain.config.dir` `的路径或者是一个绝对路径`
`--host-config`	`jboss.domain.config.dir`/host.xml	一个相对于 `jboss.domain.config.dir` `的路径或者是一个绝对路径`

下面的参数不须要指定值，而且只能被用于 host controller.(好比被配置链接到远程 domain controller的主机 )

参数	功能
`--backup`	使从 host controller建立和维护一个域配置的本地拷贝
`--cached-dc`	若是从 (slave)host controller在启动时不能链接主 domain controller取得配置信息，那么经过 -bakcup建立的本地拷贝将会被使用。同时 slave host controller不会改变任何 domain的配置，仅启动服务器。

4.4.4.4.3. 通用参数 (Common parameters)

这些没有值的参数既适用于单服务器模式也适用于管理域模式。下表介绍这些参数的使用 :

参数	功能
`--version` `-V`	打印 JBossAS的版本信息，而且退出 JVM。
`--help` `-h`	打印各参数的帮助信息，而且退出 JVM

4.4.5. 子系统配置

如下章节中将集中介绍经过 CLI和 web接口进行操做的高级管理用例 .对于每一个子系统详细的配置属性，请参考每一个子系统的参考文档。

配置的 schema 文件都在目录 $JBOSS_HOME/docs/schema

4.4.5.1. 数据源 (Data sources)

Datasources 在经过子系统进行配置。声明一个新的数据源，须要两个步骤 : 提供一个 JDBC 驱动，而后定义一个使用这个 JDBC驱动的数据源。

4.4.5.1.1. JDBC驱动安装

在应用服务器中安装 JDBC驱动推荐使用一个常规的 jar进行部署。由于当在域模式下运行应用服务器时，部署的内容会自动传送到要部署的全部服务器上，所以使用 jar文件将利用这一特性而不须要关心额外的事情。

任何符合 JDBC4的启动将会被自动识别而且按照名字和版本安装到系统中。 JDBC jar使用 Java server provider机制进行识别。 Jar文件中须要包含一个文件名是 META-INF/services/java.sql.Driver 的文本文件 ,这个文件中包含在这个 jar里的驱动类的名称。若是你的 JDBC驱动 jar不符合 JDBC规范，咱们经过其余方式也能够部署这样的驱动。

修改 Jar 文件

最直接的方式是简单的修改 Jar文件添加缺失的文件。你能够经过一下命令添加 :

The most straightforward solution is to simply modify the JAR and add the missing file. You can do

改变路径到或者建立一个空的临时文件夹 .
建立一个 META-INF 子目录
建立一个 META-INF/services 子目录
建立一个只包含一行内容 :JDBC驱动类的全名的文件 META-INF/services/java.sql.Driver .
使用 jar命令来跟新这个 jar文件 :

jar \-uf jdbc-driver.jar META-INF/services/java.sql.Driver

如何部署

JDBC4驱动

jar文件，请参考”应用部署 “章节。

4.4.5.1.2. 数据源定义 (Datasource Definitions)

subsystem xmlns="urn:jboss:domain:datasources:1.0">

<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>

<pool>

<min-pool-size>10</min-pool-size>

<max-pool-size>20</max-pool-size>

</pool>

<user-name>sa</user-name>

</security>

</datasource>

<xa-datasource jndi-name="java:jboss/datasources/ExampleXADS" pool-name="ExampleXADS">

<xa-datasource-property name="URL">jdbc:h2:mem:test</xa-datasource-property>

<xa-pool>

<min-pool-size>10</min-pool-size>

<max-pool-size>20</max-pool-size>

</xa-pool>

<user-name>sa</user-name>

</security>

</xa-datasource>

<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>

</driver>

</drivers>

</datasources>

</subsystem>

₍_{参见 standalone/configuration/standalone.xml} ₎

如以上示例所示，数据源经过逻辑名来引用 JDBC驱动 .经过命令行 (CLI)能够很方便的查询一样的信息 :

[standalone@localhost:9999 /] /subsystem=datasources:read-resource(recursive=true)

{

"outcome" => "success",

"result" => {

"data-source" => {"java:/H2DS" => {

"connection-url" => "jdbc:h2:mem:test;DB_CLOSE_DELAY=-1",

"jndi-name" => "java:/H2DS",

"driver-name" => "h2",

"pool-name" => "H2DS",

"use-java-context" => true,

"enabled" => true,

"jta" => true,

"pool-prefill" => true,

"pool-use-strict-min" => false,

"user-name" => "sa",

"password" => "sa",

"flush-strategy" => "FailingConnectionOnly",

"background-validation" => false,

"use-fast-fail" => false,

"validate-on-match" => false,

"use-ccm" => true

}},

"xa-data-source" => undefined,

"jdbc-driver" => {"h2" => {

"driver-name" => "h2",

"driver-module-name" => "com.h2database.h2",

"driver-xa-datasource-class-name" => "org.h2.jdbcx.JdbcDataSource"

}}

}

[standalone@localhost:9999 /] /subsystem=datasources:installed-drivers-list

{

"outcome" => "success",

"result" => [{

"driver-name" => "h2",

"deployment-name" => undefined,

"driver-module-name" => "com.h2database.h2",

"module-slot" => "main",

"driver-xa-datasource-class-name" => "org.h2.jdbcx.JdbcDataSource",

"driver-class-name" => "org.h2.Driver",

"driver-major-version" => 1,

"driver-minor-version" => 2,

"jdbc-compliant" => true

}]

}

使用 web控制台和命令行能够极大的简化 JDBC驱动的部署和数据源的建立。

命令行方式提供了一些列的命令来建立和更改数据源 :

[standalone@localhost:9999 /] help

Supported commands:

[...]

data-source - allows to add new, modify and remove existing data sources

xa-data-source - allows add new, modify and remove existing XA data sources

特定命令的详细描述请使用”

-b”参数查询。

4.4.5.1.3. 参考

datasource子系统由 IronJacamar 项目提供。更多关于配置属性和属性的详细介绍请参考项目文档 :

IronJacamar 主页 : http://www.jboss.org/ironjacamar
项目文档 : http://www.jboss.org/ironjacamar/docs
Schema描述 : http://docs.jboss.org/ironjacamar/userguide/1.0/en-US/html/deployment.html#deployingds_descriptor

4.4.5.2. 消息 (Messaging)

JMS服务器须要经过 messaging子系统进行配置。在本章节中，咱们将归纳介绍经常使用的配置项。其余详细的介绍，请参考 HornetQ用户指南 (参见 "参考 ").

4.4.5.2.1. Connection Factories

JMS connection factories 能够分为两类 : In-VM connection factory和被远程客户端使用的 connections factories. 每一个 connecton factory都引用一个 connector ，每一个

connector都关联到一个 socket binding. Connection Factory的 entry定义 factory被暴露的 JNDI name.

<subsystem xmlns="urn:jboss:domain:messaging:1.0">

   [...]

<connectors>

   <in-vm-connector name="in-vm" server-id="0"/>

   <netty-connector name="netty" socket-binding="messaging"/>

   <netty-connector name="netty-throughput" socket-binding="messaging-throughput">

       <param key="batch-delay" value="50"/>

   </netty-connector>

</connectors>

   [...]

<jms-connection-factories>

   <connection-factory name="InVmConnectionFactory">

       <connectors>

           <connector-ref connector-name="in-vm"/>

       </connectors>

       <entries>

           <entry name="java:/ConnectionFactory"/>

       </entries>

   </connection-factory>

   <connection-factory name="RemoteConnectionFactory">

       <connectors>

           <connector-ref connector-name="netty"/>

       </connectors>

       <entries>

           <entry name="RemoteConnectionFactory"/>

       </entries>

   </connection-factory>

   <pooled-connection-factory name="hornetq-ra">

       <connectors>

           <connector-ref connector-name="in-vm"/>

       </connectors>

       <entries>

           <entry name="java:/JmsXA"/>

       </entries>

   </pooled-connection-factory>

</jms-connection-factories>

[...]

</subsystem>

( 参见 standalone/configuration/standalone.xml)

4.4.5.2.2. Queues and Topics

Queues 和 topics 是 messaging 子系统的子资源 .每一个 Entry指定一个 queue或者 topic的 JNDI名 :

<subsystem xmlns="urn:jboss:domain:messaging:1.0">

   [...]

   <jms-destinations>

       <jms-queue name="testQueue">

           <entry name="queue/test"/>

       </jms-queue>

       <jms-topic name="testTopic">

           <entry name="topic/test"/>

       </jms-topic>

   </jms-destinations>

</subsystem>

(参见 standalone/configuration/standalone.xml)

JMS endpoints 经过命令行方式能够很容易的建立 :

[standalone@localhost:9999 /] add-jms-queue --name=myQueue --entries=queues/myQueue

[standalone@localhost:9999 /] /subsystem=messaging/jms-queue=myQueue:read-resource

   "outcome" => "success",

   "result" => {"entries" => ["queues/myQueue"]},

   "compensating-operation" => undefined

JbossAS同时也提供了其余不少的维护

JMS子系统的命令

[standalone@localhost:9999 /] help

Supported commands:

[...]

add-jms-queue           - creates a new JMS queue

remove-jms-queue        - removes an existing JMS queue

add-jms-topic           - creates a new JMS topic

remove-jms-topic        - removes an existing JMS topic

add-jms-cf              - creates a new JMS connection factory

remove-jms-cf           - removes an existing JMS connection factory

获取更多命令行的详细信息，请使用”

--help”参数获取。

4.4.5.2.3. Dead Letter和Redelivery

有些设置能够在通配符地址上生效，而不是一个特别的 messaging destination.Dead letter queue和 redelivery设置就可使用通配符地址 :

<subsystem xmlns="urn:jboss:domain:messaging:1.0">

[...]

<address-settings>

   <address-setting match="#">

       <dead-letter-address>

           jms.queue.DLQ

       </dead-letter-address>

       <expiry-address>

           jms.queue.ExpiryQueue

       </expiry-address>

       <redelivery-delay>

       </redelivery-delay>

       [...]

   </address-setting>

</address-settings>

[...]

</subsystem>

_{(参见 standalone/configuration/standalone.xml)}

4.4.5.2.4. 安全性

安全性的设置也可使用通配符地址生效，如同 DLQ和 redelivery设置同样 :

<subsystem xmlns="urn:jboss:domain:messaging:1.0">

[...]

<security-settings>

   <security-setting match="#">

       <permission type="send" roles="guest"/>

       <permission type="consume" roles="guest"/>

       <permission type="createNonDurableQueue" roles="guest"/>

       <permission type="deleteNonDurableQueue" roles="guest"/>

   </security-setting>

</security-settings>

[...]

</subsystem>

_{(参见 standalone/configuration/standalone.xml)}

4.4.5.2.5. 参考

Messaging 子系统由 Hornetq项目提供。详细的关于可用的配置项信息，请查询 hornetq项目文档。

HornetQ主页 : http://www.jboss.org/hornetq
项目文档 : http://www.jboss.org/hornetq/docs

4.4.5.3. Web

Web子系统的配置由三个部分组成 :JSP, connectors和 virtural servers。高级特性如 :负载均衡， failover等将在高”可用性指南”中介绍。默认配置对于大多数的用例均可以提供合理的性能。

须要的扩展 :

<extension module="org.jboss.as.web" />

基本子系统配置的例子 :

  <subsystem xmlns="urn:jboss:domain:web:1.0" default-virtual-server="default-host">

      <connector name="http" scheme="http" protocol="HTTP/1.1" socket-binding="http"/>

      <virtual-server name="default-host" enable-welcome-root="true">

         <alias name="localhost" />

         <alias name="example.com" />

      </virtual-server>

   </subsystem>

依赖于其余子系统 : 无 .

4.4.5.3.1. 容器设置 (Container configuration)

JSP设置 (JSP Configuration)

这里的”配置“包含了全部关于 servlet engine自身的设置。详细的关于配置属性的介绍，请参考 JBossWeb有关文档.

[standalone@localhost:9999 /] /subsystem=web:read-resource

    "outcome" => "success",

    "result" => {

        "configuration" => {

            "static-resources" => {

                "sendfile" => 49152,

                "max-depth" => 3,

                "read-only" => true,

                "webdav" => false,

                "listings" => false,

                "disabled" => false

},

            "jsp-configuration" => {

                "development" => false,

                "keep-generated" => true,

                "recompile-on-fail" => false,

                "check-interval" => 0,

                "modification-test-interval" => 4,

                "display-source-fragment" => true,

                "error-on-use-bean-invalid-class-attribute" => false,

                "java-encoding" => "UTF8",

                "tag-pooling" => true,

                "generate-strings-as-char-arrays" => false,

                "target-vm" => "1.5",

                "dump-smap" => false,

                "mapped-file" => true,

                "disabled" => false,

                "source-vm" => "1.5",

                "trim-spaces" => false,

                "smap" => true

},

        "connector" => {"http" => undefined},

        "virtual-server" => {"localhost" => undefined}

(参见 standalone/configuration/standalone.xml)

4.4.5.3.2. Connector设置 (Connector configuration)

Connecotrs是 web子系统的子资源。每一个 connector都引用一个特定的 socket binding:

[standalone@localhost:9999 /] /subsystem=web:read-children-names(child-type=connector)

    "outcome" => "success",

    "result" => ["http"]

[standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(recursive=true)

    "outcome" => "success",

    "result" => {

        "protocol" => "HTTP/1.1",

        "scheme" => "http",

        "socket-binding" => "http",

        "ssl" => undefined,

        "virtual-server" => undefined

建立一个 connector须要先声明一个 socket binding：

[standalone@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=custom:add(port=8181)

新建立的没有被使用的

socket binding能够用来建立一个新的

connector配置

[standalone@localhost:9999 /] /subsystem=web/connector=test-connector:add(

               socket-binding=custom, scheme=http, protocol="HTTP/1.1", enabled=true

web子系统能够配置三种类型的 connecotr:

HTTP Connectors

默认的 connector,一般运行在 8080端口。配置请参考以上内容

HTTPS Connectors

HTTPS connectors是 web子系统的子资源。默认使用 JSSE.每一个 connector引用一个特定的 socket binding：

[standalone@localhost:9999 /] /subsystem=web:read-children-names(child-type=connector)

    "outcome" => "success",

    "result" => [

        "ajp",

        "http",

        "https"

[standalone@localhost:9999 /] /subsystem=web/connector=https:read-resource(recursive=true)

    "outcome" => "success",

    "result" => {

        "protocol" => "HTTP/1.1",

        "scheme" => "https",

        "secure" => true,

        "socket-binding" => "https",

        "ssl" => {},

        "virtual-server" => undefined

建立一个新的 connector首先须要声明一个新的 socket binding:

[standalone@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=https:add(port=8443)

新建立的，没有使用的

socket binding可被用来设置新建立的

connecotr：

[standalone@localhost:9999 /] /subsystem=web/connector=test-connector:add(socket-binding=https, scheme=https, protocol="HTTP/1.1", enabled=true, ssl = {})

默认 SSL使用” tomcat”别名和” changit”密码。可使用 keytool来建立相应的 keystore:

keytool -genkey -alias tomcat -keyalg RSA

固然须要指定值是” changeit”的密码。

AJP Connectors

AJP Connectors是 web子系统的子资源。它和前段 apache httpd的 mod_jdk,mode_proxy和 mod_cluster一块儿使用。

每一个 connecotor都引用一个特定的 socket binding:

[standalone@localhost:9999 /] /subsystem=web:read-children-names(child-type=connector)

    "outcome" => "success",

    "result" => [

        "ajp",

        "http"

[standalone@localhost:9999 /] /subsystem=web/connector=ajp:read-resource(recursive=true)

    "outcome" => "success",

    "result" => {

        "protocol" => "AJP/1.3",

        "scheme" => "http",

        "socket-binding" => "ajp",

        "ssl" => undefined,

        "virtual-server" => undefined

建立一个新的 connector首先须要声明一个新的 socket binding:

[standalone@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=ajp:add(port=8009)

新建立的，没有使用的

socket binding可被用来设置新建立的

connecotr：

[standalone@localhost:9999 /] /subsystem=web/connector=ajp:add(

               socket-binding=ajpm, protocol="AJP/1.3", enabled=true

Native Connectors

Native connectors是基于 Tomcat native的高性能的 connectors.若是 nativie模块安装的话，就可使用 native connectors 。

目前不少发布已经包含 jboss web native(若是你尚未试用过 JBoss web native)。

在配置层面，因为使用 OpenSSL,只有 SSL部分须要被不一样的配置。

[standalone@localhost:9999 /] /subsystem=web/connector=https:read-resource(recursive=true)

    "outcome" => "success",

    "result" => {

        "protocol" => "HTTP/1.1",

        "scheme" => "https",

        "secure" => true,

        "socket-binding" => "https",

        "ssl" => {

            "certificate-file" => "/home/jfclere/CERTS/SERVER/newcert.pem",

            "certificate-key-file" => "/home/jfclere/CERTS/SERVER/newkey.pem",

            "password" => "xxxxxxx"

},

        "virtual-server" => undefined

4.4.5.3.3. Virtual-server配置（Virtual-Server configuration）

和 connector相似， virtual server 声明 web 子系统的子资源。能够经过使用别名来引用 virtual server,

同时 virtual server 也能够指定默认的 web 应用来充当 root web context 。

[standalone@localhost:9999 /] /subsystem=web:read-children-names(child-type=virtual-server)

    "outcome" => "success",

    "result" => ["localhost"]

[standalone@localhost:9999 /] /subsystem=web/virtual-server=default-host:read-resource

    "outcome" => "success",

    "result" => {

        "access-log" => undefined,

        "alias" => ["example.com"],

        "default-web-module" => undefined,

        "enable-welcome-root" => true,

        "rewrite" => undefined

增长一个 virtual server的声明能够经过默认的 add操做 :

[standalone@localhost:9999 /] /subsystem=web/virtual-server=example.com:add

[standalone@localhost:9999 /] /subsystem=web/virtual-server=example.com:remove

在 configuration tree上任意一个节点上均可以执行增长和删除操做

4.4.5.3.4. 参考

Web子系统部件由 jboss web项目提供。关于 web子系统可配置的属性的详细介绍，请参考 JBoss Web文档 :

JBoss Web 配置和参考 : http://docs.jboss.org/jbossweb/7.0.x/config/index.html
JBossWeb 主页 : http://www.jboss.org/jbossweb
项目文档 : http://docs.jboss.org/jbossweb/7.0.x/

4.4.5.4. Web services

Web service endpoint 经过包含有 webservice endpoint 实现的部署来提供所以他们能够经过部署资源进行查询。

进一步的信息，请参考”应用部署”章节。每一个 webservice endpoint 都须要指定一个 web context 和一个 wsdl的 URL :

[standalone@localhost:9999 /] /deployment="*"/subsystem=webservices/endpoint="*":read-resource

   "outcome" => "success",

   "result" => [{

       "address" => [

           ("deployment" => "jaxws-samples-handlerchain.war"),

           ("subsystem" => "webservices"),

           ("endpoint" => "jaxws-samples-handlerchain:TestService")

],

       "outcome" => "success",

       "result" => {

           "class" => "org.jboss.test.ws.jaxws.samples.handlerchain.EndpointImpl",

           "context" => "jaxws-samples-handlerchain",

           "name" => "TestService",

           "type" => "JAXWS_JSE",

           "wsdl-url" => "http://localhost:8080/jaxws-samples-handlerchain?wsdl"

}]

4.4.5.4.1. 参考

Webservice 子系统由 JBossWS项目提供。关于 websevice子系统可配置的属性的详细介绍，请参考 JBoss WS文档 :

JBossWS 主页 : http://www.jboss.org/jbossws
项目文档 : https://docs.jboss.org/author/display/JBWS