JBoss7詳細配置指南

時間 2019-11-10

標籤 jboss7 jboss 詳細配置指南简体版

原文原文鏈接

1. jboss各主要版本特性... 3html

1.1. jboss4特性... 3前端

1.2. jboss5特性... 5java

1.3. jboss6特性... 6node

1.4. jboss7特性... 7git

2. 爲何JBoss AS7 這麼快... 8github

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

3.1. 域(Domain)的概念及其與羣集(Cluster)的區別... 10sql

3.2. 實驗... 11數據庫

1.1.1. 準備工做... 11apache

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

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。