17.3 주요 설정 항목
JBoss EAP 6에서는 어느 모듈을 이용하는지를 선택할 수 있어, 사용자가 이용하고 싶은 기능을 선택할 수 있다. 미리 준비되어 있는 각 프로파일에는 어떤 기능, 즉 어떤 모듈을 사용할 것인지가 설정 파일(standalone.xml, domain.xml 등)에 정의되었다. 일반적으로JBoss EAP의 설정은 관리 콘솔이나 CLI등의 관리 UI를 통해서 수행되지만, 그 내용도 설정 파일(standalone.xml, host.xml등)에 저장된다. 여기에서 설정 파일을 구성하는 XML 엘리먼트들을 기본적인 설정의 컨셉에 따라서 설명한다. 설정 파일의 주요한 설정 항목은 아래와 같다.
| 구분 | 엘리먼트 | 설명 |
|---|---|---|
| extension | extensions | JBoss EAP 코어 기능확장 모듈 |
| 서브시스템 | subsystems | 모듈들의 기능 세트 |
| 프로파일 | profile | 이용하는 서브시스템 정의 |
| 패스 | path | 파일 시스템 패스의 논리적인 이름 정의 |
| 매니지먼트 | management | Realm / interface의 바인딩 |
| 인터페이스 | interfaces | 바인딩 가능한 IP주소 |
| 소켓 바인딩 | socket-binding-group | 소켓 그룹의 이름 설정 |
| 시스템 프로퍼티 | system-properties | 시스템 프로퍼티 정의 |
| JVM | jvms | jvm 시작 옵션 |
표 2. 주요 설정 항목
extension
extension은 JBoss EAP 6의 코어 기능을 확장하는 모듈이다. JBoss EAP 6의 코어로 정의하는 모듈은 최소한의 기능만으로 구성되어 있어 사용자가 이용하는 대부분의 기능은 extension으로 제공되고 있다. extension들은 JBoss가 설치된 디렉터리에 있는 modules 디렉터리에 모듈로서 패키징 되었다. 각 프로파일에서 사용되는 모듈은 설정 파일의 extension 내의 모듈 이름이 정의된다.
<extensions>
<extension module="org.jboss.as.clustering.infinispan"/>
<extension module="org.jboss.as.clustering.jgroups"/>
<extension module="org.jboss.as.cmp"/>
<extension module="org.jboss.as.configadmin"/>
<extension module="org.jboss.as.connector"/>
<extension module="org.jboss.as.ee"/>
<extension module="org.jboss.as.ejb3"/>
<extension module="org.jboss.as.jacorb"/>
<extension module="org.jboss.as.jaxr"/>
<extension module="org.jboss.as.jaxrs"/>
<extension module="org.jboss.as.jdr"/>
<extension module="org.jboss.as.jmx"/>
<extension module="org.jboss.as.jpa"/>
<extension module="org.jboss.as.jsf"/>
<extension module="org.jboss.as.jsr77"/>
<extension module="org.jboss.as.logging"/>
<extension module="org.jboss.as.mail"/>
<extension module="org.jboss.as.messaging"/>
<extension module="org.jboss.as.modcluster"/>
<extension module="org.jboss.as.naming"/>
<extension module="org.jboss.as.pojo"/>
<extension module="org.jboss.as.remoting"/>
<extension module="org.jboss.as.sar"/>
<extension module="org.jboss.as.security"/>
<extension module="org.jboss.as.threads"/>
<extension module="org.jboss.as.transactions"/>
<extension module="org.jboss.as.web"/>
<extension module="org.jboss.as.webservices"/>
<extension module="org.jboss.as.weld"/>
</extensions>
위의 예에서는 트랜잭션, 웹, 클러스터링, 메시징, 웹 서비스, Weld등이 정의되어 있어 full-ha 프로파일이라는 것을 알 수 있다.
서브시스템
서브시스템(subsystems)은 서블릿, EJB 컨테이너, JTA등의 서비스를 제공하는 모듈들의 기능 집합이다. 사용하는 모듈에 대한 상세 설정은, 설정 파일의 subsystem 내에 모듈 이름이 정의되어 서브시스템 시작시 초기화 파라미터 등이 지정된다. extension과 서브시스템의 관계는, extension이 이용하는 모듈 자체의 정의라고 하면, 서브시스템은 그 모듈을 기능으로서 인스턴스화 할 때의 구체적인 설정 정의라고 할 수 있다.
<subsystem xmlns="urn:jboss:domain:infinispan:1.4">
<cache-container name="web" aliases="standard-session-cache" default-cache="local-web" module="org.jboss.as.clustering.web.infinispan">
<local-cache name="local-web" batching="true">
<file-store passivation="false" purge="false"/>
</local-cache>
</cache-container>
<cache-container name="hibernate" default-cache="local-query" module="org.jboss.as.jpa.hibernate:4">
<local-cache name="entity">
<transaction mode="NON_XA"/>
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<local-cache name="local-query">
<transaction mode="NONE"/>
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<local-cache name="timestamps">
<transaction mode="NONE"/>
<eviction strategy="NONE"/>
</local-cache>
</cache-container>
</subsystem>
그림 5. extension과 서브시스템 설정
extensions 과 서브시스템의 관계는 다음과 같다.
| 구분 | extension | Subsystem | |
|---|---|---|---|
| standalone | infinispan | org.jboss.as.clustering.infinispan | urn:jboss:domain:infinispan:1.4 |
| datasources | org.jboss.as.connector | urn:jboss:domain:datasources:1.1 | deployment-scanner |
| org.jboss.as.deployment-scanner | urn:jboss:domain:deployment-scanner:1.1 | ee | org.jboss.as.ee |
| urn:jboss:domain:ee:1.1 | ejb3 | org.jboss.as.ejb3 | urn:jboss:domain:ejb3:1.4 |
| jaxrs | org.jboss.as.jaxrs | urn:jboss:domain:jaxrs:1.0 | jdr |
| org.jboss.as.jdr | urn:jboss:domain:jdr:1.0 | Jmx | org.jboss.as.jmx |
| urn:jboss:domain:jmx:1.2 | jpa | org.jboss.as.jpa | urn:jboss:domain:jpa:1.1 |
| Jsf | org.jboss.as.jsf | urn:jboss:domain:jsf:1.0 | logging |
| org.jboss.as.logging | urn:jboss:domain:logging:1.2 | org.jboss.as.mail | |
| urn:jboss:domain:mail:1.1 | naming | org.jboss.as.naming | urn:jboss:domain:naming:1.3 |
| pojo | org.jboss.as.pojo | urn:jboss:domain:pojo:1.0 | remoting |
| org.jboss.as.remoting | urn:jboss:domain:remoting:1.1 | sar | org.jboss.as.sar |
| urn:jboss:domain:sar:1.0 | security | org.jboss.as.security | urn:jboss:domain:security:1.2 |
| threads | org.jboss.as.threads | urn:jboss:domain:threads:1.1 | transactions |
| org.jboss.as.transactions | urn:jboss:domain:transactions:1.3 | web | org.jboss.as.web |
| urn:jboss:domain:web:1.4 | webservices | org.jboss.as.webservices | urn:jboss:domain:webservices:1.2 |
| weld | org.jboss.as. weld | urn:jboss:domain:weld:1.0 .5+ | standalone-full |
| cmp | org.jboss.as.cmp | urn:jboss:domain:cmp:1.1 | jacorb |
| org.jboss.as.jacorb | urn:jboss:domain:jacorb:1.3 | jaxr | org.jboss.as.jaxr |
| urn:jboss:domain:jaxr:1.1 | jsr77 | org.jboss.as.jsr77 | urn:jboss:domain:jsr77:1.0" |
표 3. extentions와 서브시스템 간의 관계
도메인 모드의 서브시스템과 extension
도메인 모드에서 하나의 설정 파일 domain.xml 에 모든 프로파일이 정의되어 있기 때문에 extension은 스탠드얼론 모드에서의 전체 기능 standalone-full-ha.xml 와 거의 같은 정의가 되었다. 한가지 차이점은 스탠드얼론 모드에만 deployment-scanner가 있다는 점이다.
반대로, 서브시스템에 대해서는 스탠드얼론 모드에서의 4개의 설정 파일에 해당하는 정의가 하나의 domain.xml파일내에 4개의 프로파일로 설정되었다.
서브시스템의 삭제
JBoss EAP 6에서는 MSC(Modular Service Container)에 의해 서비스(코어 모듈)의 추가, 삭제를 매우 쉽게 할 수 있다. 다음에서 불필요한 서비스의 삭제 방법을 살펴보자.
각 프로파일에서 특정의 서비스를 삭제하려면 설정 파일(standalone.xml, domain.xml 등)에서 해당의 모듈 정의인 <extension>와 <subsystem>를 삭제한다. modules 디렉터리에서 해당의 모듈 자체를 삭제한다.
서브시스템을 삭제하고자 할 경우, 다른 모듈에서 사용되기 때문에 삭제 시 오류가 발생할 수 있는데 아래 모듈들은 대표적인 삭제 가능한 모듈들로 이에 대한 삭제 방법을 설명한다.
| 구분 | 삭제 방법 |
|---|---|
| H2데이타베이스 | <datasource jndi-name="java:jboss/datasources/ExampleDS" …/> 태그 삭제 modules/com/h2database 디렉토리 삭제 |
| 배포스캐너 | <extension module="org.jboss.as.deployment-scanner"/> 태그 삭제 <subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1"/> 태그 삭제 modules/org/jboss/as/deployment-scanner 디렉토리 삭제 |
| 메 일 | <extension module="org.jboss.as.mail"/> 태그 삭제 <subsystem xmlns="urn:jboss:domain:mail:1.0"/> 태그 삭제 <outbound-socket-binding name="mail-smtp"/> 태그 삭제 modules/org/jboss/as/mail 디렉토리 삭제 |
| HornetQ | <extension module="org.jboss.as.messaging"/> 태그 삭제 <subsystem xmlns="urn:jboss:domain:messaging:1.2"/> 태그 삭제 <socket-binding name="messaging-throughput" port="5455"/> 태그 삭제 modules/org/jboss/as/messaging 디렉터리 삭제 |
프로파일
프로파일(profile)은 서브시스템들을 묶어놓은 세트이며, extension에 의해 JBoss EAP 6 코어에 추가된 추가 기능 세트이다. 여러 개의 서브시스템을 포함하고 있는 프로파일은 결과적으로 여러 개의 기능 세트를 제공하는 서버가 된다. 몇 개의 서브시스템만으로 정의된 프로파일은 소규모 기능을 가진 서버가 되어 메모리 사용량이 작은 가벼운 서버가 된다. 예를 들면, 풀 프로파일의 프로파일 정의 파일인 standalone-full.xml 는 웹 컨테이너 만이 아니라 EJB나 JMS등의 Java EE의 전체 기능을 제공하기 때문에, 여러 개의 서브시스템 정의를 포함하지만, 웹 프로파일 정의인 standalone.xml 파일은 웹 컨테이너를 중심으로 한 기능만 제공하기 때문에 보다 적은 서브시스템 정의만 가지고 있다.
스탠드얼론 모드로 정의되는 프로파일(설정 파일명)과 도메인 모드로 정의되는 프로파일 및 각 프로파일에서 사용되는 서브시스템은 다음과 같다.
표 4. 스탠드얼론 모드와 도메인 모드의 프로파일 비교
패스
파일 시스템 패스(path)의 논리적인 이름으로 설정 파일 내부의 다른 부분에서 참조된다.
예를 들어 로깅 서브시스템은 jboss.server.log.dir의 값을 참조하여 서버 log 디렉터리를 지정하게 된다.”
<file relative-to="jboss.server.log.dir" path="server.log"/>
| 구분 | 패스(path) | |
|---|---|---|
| jboss.home.dir | $JBOSS_HOME | JBoss EAP 6 의 루트 디렉터리 |
| user.home | $HOME | 사용자의 홈디렉터리 |
| jboss.server.base.dir | <jboss.home.dir>/standalone | 서버 구성의 루트 디렉터리 |
| jboss.server.config.dir | <jboss.server.base.dir>/configuration | 설정의 베이스 디렉터리 |
| jboss.server.data.dir | <jboss.server.base.dir>/data | 데이터 파일 저장 디렉터리 |
| jboss.server.log.dir | <jboss.server.base.dir>/log | 로그 파일 저장 디렉터리 |
| jboss.domain.base.dir | <jboss.home.dir>/domain | 도메인 모드의 루트 디렉터리 |
| jboss.domain.config.dir | <jboss.domain.base.dir>/configuration | 도메인 설정의 베이스 디렉터리 |
| jboss.domain.data.dir | <jboss.domain.base.dir>/data | 도메인 데이터 파일 저장 디렉터리 |
| jboss.domain.log.dir | <jboss.domain.base.dir>/log | 도메인 로그 파일 저장 디렉터리 |
표 5. 주요 패스(path)
매니지먼트
보안 영역의 설정과 관리용 인터페이스를 정의하는 속성이다.
기본값은 ApplicationRealm와 ManagementRealm의 두개가 파일로 정의되었다. 각각의 Realm에서 사용하는 파일들은 application-realm.properties, application-roles.properties과 management-realm.properties로 정의되었다.
또, 네이티브 관리 포트와 HTTP의 관리 포트의 인터페이스 정의는 ManagementRealm을 사용하도록 보안 설정이 되었다.
인터페이스
소켓이 바인드 가능한 IP주소과 호스트이름의 논리적인 이름을 정의하는 속성이다. 정의된 인터페이스는 다른 설정에서 인터페이스의 논리적 이름으로 참조된다. 인터페이스 설정에는 주소나 인터페이스의 논리적 이름 뿐만 아니라 NIC 설정이나 subnet mask등의 정보도 설정할 수 있다.
<management>
<security-realms>
<security-realm name="ManagementRealm">
<authentication>
<local default-user="$local"/>
<properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
</authentication>
</security-realm>
<security-realm name="ApplicationRealm">
<authentication>
<local default-user="$local" allowed-users="*"/>
<properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>
</security-realms>
<management-interfaces>
<native-interface security-realm="ManagementRealm">
<socket-binding native="management-native"/>
</native-interface>
<http-interface security-realm="ManagementRealm">
<socket-binding http="management-http"/>
</http-interface>
</management-interfaces>
</management>
<interfaces>
<interface name="management">
<inet-address value="$\{jboss.bind.address.management:127.0.0.1}"/>
</interface>
<interface name="public">
<inet-address value="$\{jboss.bind.address:127.0.0.1}"/>
</interface>
<interface name="unsecure">
<inet-address value="$\{jboss.bind.address.unsecure:127.0.0.1}"/>
</interface>`
</interfaces>
소켓 바인딩 그룹
소켓 바인딩 그룹(socket-binding-group)은 포트들의 집합에 이름을 정의하는 속성으로 인터페이스 정의를 참조해 정의한다. 정의된 소켓 바인딩 그룹 설정도 다른 정의에서 논리적 이름으로 참조된다.
또, 각 프로파일마다 필요한 소켓 정의가 그룹으로 정의된다.
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="$\{jboss.socket.binding.port-offset:0}">
<socket-binding name="management-native" interface="management" port="$\{jboss.management.native.port:9999}"/>
<socket-binding name="management-http" interface="management" port="$\{jboss.management.http.port:9990}"/>
<socket-binding name="management-https" interface="management" port="$\{jboss.management.https.port:9443}"/>
<socket-binding name="ajp" port="8009"/>
<socket-binding name="http" port="8080"/>
<socket-binding name="https" port="8443"/>
<socket-binding name="remoting" port="4447"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<outbound-socket-binding name="mail-smtp">
<remote-destination host="localhost" port="25"/>
</outbound-socket-binding>
</socket-binding-group>
여러 개의 포트를 개별적으로 변경하는 것도 가능하지만, 소켓 바인딩에서는 포트 오프셋(port-offset)라고 하는 개념을 가지고 있다. 이 기능은 JBoss가 사용하는 여러 포트에 대해서 일률적으로 값을 더해 사용하는 포트 번호를 일괄 변경하는 것으로 IP주소가 1개 밖에 사용할 수 없는 환경에서도 포트가 충돌하지 않고 여러 개의 JBoss EAP 인스턴스를 사용할 수 있다.
시스템 프로퍼티
Java의 시작 시에 넘겨주는 시스템 프로퍼티를 설정 파일에서 정의하기 위한 속성이다.
property 속성으로 여러 개의 시스템 프로퍼티를 정의할 수 있다.
<system-properties>
<property name="java.net.preferIPv4Stack" value= "true"/>
</system-properties>
시스템 프로퍼티를 관리 CLI로 설정하는 경우의 예는 아래와 같다.
[standalone@localhost:9999 /] ./system-property=org.apache.catalina.JSESSIONID:add(value="MYID")
{"outcome" => "success"}
JVM
Java실행시의 옵션을 설정 파일에 정의하기 위한 속성이다. JVM의 파라미터 정의를 여러 개 정의해 두고, 서버 그룹마다 사용할 JVM정의를 바꾸는 것이 가능하다. 이것은 스탠드얼론 모드에서는 존재하지 않고 도메인의 프로파일에서만 설정 가능하다.
<jvms>
<jvm name="default">
<heap size="64m" max-size="256m"/>
<permgen size="256m" max-size="256m"/>
<jvm-options>
<option value="-server"/>
</jvm-options>
</jvm>
</jvms>
VFS
VFS(Virtual File System)는 파일 시스템을 추상화 하는 기능으로, JBoss EAP 6 의 클래스 로더 정책의 자원 문제를 해결하기 위해 사용되고 있다. JBoss EAP 5에서 추가되어 JBoss EAP 6에서도 라이브러리로 사용하고 있다. VFS를 이용하는 것은 몇 가지 장점이 있다.
우선, VFS를 이용하는 일은 archive파일과 archive파일을 풀어서 배포하는(exploded) 방법과 똑같이 취급할 수 있어 VFS를 이용하여 배포하면 아카이브(archive)화하는 작업을 줄일 수 있다. 이 때문에, 개발 시에는 변경된 파일만 교체하면 배포가 끝나기 때문에, 배포가 빨라져 개발 생산성을 높일 수 있다. 다시 말하면, deployments 디렉터리에 example.war 파일을 배포했을 경우와 example.war 풀어놓은 디렉터리를 배포했을 경우가 같게 다룬다.
그림 6. VFS의 구조
또, VFS에서는 JDK의 파일 조작 API보다 더 추상화된 사용하기 쉬운 API를 제공하고 있다.
예를 들어, Windows상에서 파일이 락이 걸리면 배포할 수 없게 되어 버리지만, 임시 파일을 작성하여 처리하는 방식을 사용하여 피해갈 수 있다. 파일 핸들에 대한 처리가 VFS내부에 포함되어 있기 때문에 기존의 Windows 상에서 파일 락과 같은 문제를 해결하고 있다.