Chapter 10. 기타 MBean 서비스

이번 장에서는 유용한 MBean 서비스들에 대해 논의할 것입니다. 이 서비스들은 다른 곳에서는 언급되지 않았으며, 그 이유는 JBoss를 시작하는데 꼭 필요하지 않거나 이 책에서 다루고 있는 섹션에 적합하지 않아서 였습니다.

10.1. 시스템 속성 관리

시스템 속성의 관리는 org.jboss.varia.property.SystemPropertiesService MBean 을 사용하여 하실 수 있습니다. java.lang.System.setProperty 메쏘드와 VM 명령어 라인 인수로 하는 것 처럼 VM의 전역 속성 값의 설정을 지원합니다.

지원하는 설정가능한 속성들은 다음과 같습니다:

  • Properties: tt class="literal">java.util.Properites.load(java.io.InputStream) 메쏘드 포맷을 사용하여 여러 속성 name=value 쌍을 지정합니다. 각각의 property=value 문장은 Properties 속성 요소의 바디내에 별도의 라인으로 주어집니다.
  • URLList: 속성 파일로 포맷되어진 컨텐츠를 로딩하게 되는 URL 문자열의 컴마로 구분된 리스트. 리스트내의 컴포넌트는 URL보다는 상대적 경로이며, <jboss-dist>/server/<config> 디렉터리에 상대적인 파일 경로처럼 다루어지게 됩니다. 가령, conf/local.properties 라는 컴포넌트는 default 설정 파일 셋으로 동작되는 경우 <jboss-dist>/server/default/conf/local.properties 파일을 가르키는 파일 URL로 다루어질 것입니다.

예제 10.1, “SystemPropertiesService jboss-service 서술자의 예제”에서 이 두 속성들을 사용법을 보여주고 있습니다.

예제 10.1. SystemPropertiesService jboss-service 서술자의 예제

<server>
    <mbean code="org.jboss.varia.property.SystemPropertiesService"
           name="jboss.util:type=Service,name=SystemProperties">
            
        <!-- 컴마로 구별되는 각각의 URL들로부터 속성을 로딩 -->
        <attribute name="URLList">
            http://somehost/some-location.properties,
            ./conf/somelocal.properties
        </attribute>
            
        <!-- 속성 파일 스타일을 사용하여 속성 설정. -->
        <attribute name="Properties">
            property1=This is the value of my property
            property2=This is the value of my other property
        </attribute>
            
    </mbean>
</server>

10.2. 속성 편집기 관리

java.bean.PropertyEditor 인스턴스 관리에 대한 지원은 org.jboss.varia.property.PropertyEditorManagerService MBean을 통해 가능합니다. 이것은 java.bean.PropertyEditorManager 클래스를 사용하여 속성 편집기를 정의하는것에 도움을 주는 간단한 서비스입니다. 이 서비스는 커스텀 JBoss PropertyEditor 구현을 사전에 로딩하기 위해 메인 jboss-service.xml 파일내에서 사용됩니다. 시스템의 클래스경로로부터만 속성 편집기를 로딩하게 되는 몇몇 JDK1.3.0 VM의 경우 필요합니다.

지원되는 속성들은 다음과 같습니다:

  • BootstrapEditors: 속성 편집기 자신의 registerEditor(Class targetType, Class editorClass) 메쏘드를 사용하여 속성 PropertyEditorManager 클래스쪽으로 미리 로딩시켜야만 하는 속성 편집기를 타입 매핑으로 정의하는 property_editor_class=editor_value_type_class 쌍의 리스트입니다. 이 속성의 값 형식은 문자열로써 커스텀 속성 편집기가 필요없이 문자열로부터 지정될 수 있습니다.
  • Editors: 이것은 BootstrapEditors 속성과 동일한 기능을 서비스하지만, 타입은 java.util.Properties 클래스이기 때문에 이 값을 문자열 값으로부터 설정하기 위해서는 Properties를 위한 커스텀 속성 편집기가 필요합니다. 커스텀 속성 편집기가 쓰레드 컨텍스트 클래스 로더로부터 로딩될 수 있는 경우, 이것을 BootstrapEditors 속성 대신 사용할 수 있습니다.
  • EditorSearchPath: 이 속성을 통해 여러분은 PropertyEditorManager 편집기 패키지 검색 경로를 지정할 수 있습니다.

10.3. 서비스 바인딩 관리

JBoss에서 사용가능한 독립적으로 배치되어 있는 모든 서비스들에서 해당 컴퓨터상에서 동작하고 있는 여러 인스턴스들은 설정 파일 편집을 통해 진저리 날만큼 연습할 수 있습니다. 바인딩 서비스인 org.jboss.services.binding.ServiceBindingManager는 중앙 로케이션에서 서비스 속성 값으로 매핑할 수 있게 합니다. 서비스의 서술자 파일을 해석한 후, 초기 속성 값들이 서비스에 적용되어지면 ServiceConfiguratorServiceBindingManager에게 서비스를 위해 존재할 수도 있는 값들을 덮어쓰도록 질의합니다. ServicesBindingManager는 설정 오버라이드의 저장소인 ServiceConfigurator 사이에서 코디네이터 역할을 하고 서비스쪽에 설정을 어떻게 적용시킬지 알 고 있는 설정을 위임합니다. 이러한 작용을 하고 있는 클래스들이 그림 10.1, “ServiceBindingManager의 org.jboss.services.binding 패키지에 대한 클래스 다이어그램”에 표시되어 있습니다.

ServiceBindingManager의 org.jboss.services.binding 패키지에 대한 클래스 다이어그램

그림 10.1. ServiceBindingManager의 org.jboss.services.binding 패키지에 대한 클래스 다이어그램

ServiceBindingManager에서 주의해야 할 첫 번째 사항은 이것이 JBoss의 서비스 인터페이스가 아닌 자신의 생명 주기 통지 인터페이스로써 JMX MBeanRegistration 인터페이스 메쏘드를 구현한다는 것입니다. 이것은 ServiceBindingManager가 다른 서비스들의 속성 값쪽에 오퍼레이션하기 때문에 필요합니다. 속성들은 JBoss의 서비스 생명 주기 메쏘드가 호출되기 이전에 설정되어 ServiceBindingManager가 MBean 서버와 함께 등록되어지자마자 곧바로 활설화가 되어야만 합니다. ServiceBindingManager의 설정은 postRegister(Boolean) 콜백 메쏘드내에서 발생합니다.

ServiceBindingManagerServicesStoreFactory를 통해 ServicesStore에 연결됩니다. ServicesStoreFactoryServiceBindingManager의 속성을 통해 설정됩니다. ServiceBindingManager의 설정가능한 속성들은 다음과 같습니다:

  • ServerName: 관리자가 연결되는 서버의 이름. 이 이름은 ServicesStore로부터 ServiceConfig을 룩업하기위해 사용하는 논리적인 이름입니다.
  • StoreFactoryClassName: ServicesStoreFatory 인터페이스를 구현하는 클래스의 이름입니다. 여러분의 구현을 제공하거나 기본 XML 기반의 저장소인 org.jboss.services.binding.XMLServicesStoreFactory를 사용할 수 있습니다.
  • StoreURL: 설정 저장 컨텐츠의 URL 입니다. 이것은 ServicesStoreFactory로부터 획득한 ServicesStore 인스턴스의 load(URL) 메쏘드쪽으로 넘겨집니다.

ServicesStore는 단지 JBoss 인스턴스 이름에 의해 키로 사용되는 ServiceConfig 객체와 서비스의 JMX ObjectName 컬렉션입니다. ServiceConfigServiceBinding을 대상 MBean에 어떻게 매핑시키는 가를 알고 있는 ServiceBinding 객체들의 컬렉션과 ServicesConfigDelegate 입니다. ServiceConfig은 위임(delegate)을 위해 임의의 설정을 포함할 수도 있습니다. ServiceBinding(interface, port) 쌍으로 이름이 붙습니다.

ServiceBindingManager가 서비스의 설정을 덮어쓰도록 요청받으면 어떤 일이 벌어지겠습니까? 이벤트 시퀀스가 그림 10.2, “ServiceConfigurator가 ServiceBindingManager에 질의하는 방법”에 보여지고 있습니다.

ServiceConfigurator가 ServiceBindingManager에 질의하는 방법

그림 10.2. ServiceConfigurator가 ServiceBindingManager에 질의하는 방법

  • ServiceConfiguratorapplyServiceConfig 메쏘드 JMX ObjectName에 의해 주어진 MBean에 대한 설정을 덮어쓰기 위해 ServiceBindingManager를 질의합니다.
  • ServiceBindingManager는 동작하고 있는 JBoss 서버 인스턴스의 신분을 구별하는 이름이 붙여진 서비스에 대한 ServiceConfig을 위해 ServicesStore에 질의합니다. 이것은 ServiceBindingManager의 속성이며 예제에서 볼 수 있듯이 시스템 속성으로부터 가져올 수 있습니다. ServicesStore가 가르키는 <serverName, serviceName> 쌍에 대한 설정 오버라이드(override)를 포함하는 경우, ServiceConfig을 반환합니다.
  • ServiceConfig이 반환되면, ServiceBindingManagerServicesConfigDelegate 인터페이스를 구현하고 있는 클래스의 이름에 대한 것을 질의합니다.
  • ServicesConfigDelegate 클래스는 쓰레드 컨텍스트 클래스 로더를 사용해 로딩되어지고 인스턴스가 생성됩니다.
  • 그런 다음, ServicesConfigDelegate 인스턴스는 제공되는 MBeanServer을 사용하여 ServiceConfig을 적용시킬지를 묻습니다. 위임(delegate)에서는 호출된 속성 셋터(setter)에 의해 서비스의 가리켜진 속성들을 오버라이드하려는 바인딩과 함께 위임 설정 정보를 사용하거나 MBeanServer를 사용하여 서비스에 대한 오퍼레이션을 사용하게 됩니다. 대상 서비스의 이름은 ServiceConfig내에서 사용가능합니다.

이것이 ServiceBindingManager에 대한 일반적인 개요입니다. 이제 이 내용을 보다 확실히 이해하기 위해 동일한 머신상에서 서비스의 기본 설정 셋을 갖는 두 개의 JBoss 인스턴스를 이 서비스를 사용하여 올려주는 방법을 살펴보도록 하겠습니다.

10.3.1. 두 개의 JBoss 인스턴스 동작시키기

JBoss에는 동일한 호스트상에서 두 개의 JBoss 인스턴스를 시작시킬 수 있는 예제 ServicesStore XML 파일과 함께 ServiceBindingManager 서비스 설정을 포함하고 있습니다. 이번 섹션에서 우리는 두 인스턴스로 구동시키는 방법과 그 설정 에제를 살펴보도록 하겠습니다. 이 책의 예제 디렉터리에서 다음 명령을 통해 두 서버 설정 파일 셋인 jboss0jboss1을 시작시킬 수 있습니다:

[nr@toki examples]$ ant -Dchap=chap10 -Dex=1 run-example
Buildfile: build.xml
...
     [echo] Preparing jboss0 configuration fileset
    [mkdir] Created dir: /tmp/jboss-3.2.6/server/jboss0
     [copy] Copying 259 files to /tmp/jboss-3.2.6/server/jboss0
     [copy] Copying 1 file to /tmp/jboss-3.2.6/server/jboss0/conf
     [copy] Copying 1 file to /tmp/jboss-3.2.6/server
     [echo] Preparing jboss1 configuration fileset
    [mkdir] Created dir: /tmp/jboss-3.2.6/server/jboss1
     [copy] Copying 259 files to /tmp/jboss-3.2.6/server/jboss1
 
BUILD SUCCESSFUL

이것은 server/default 설정 파일 셋을 server/jboss0server/jboss1 이라는 사본으로 생성한 뒤, 다음과 같은 ServiceBindingManager 설정이 가능하게 하는 것으로 conf/jboss-service.xml 서술자를 대체시켜주게 됩니다:

<mbean code="org.jboss.services.binding.ServiceBindingManager"
       name="jboss.system:service=ServiceBindingManager">
    <attribute name="ServerName">${jboss.server.name}</attribute>
    <attribute name="StoreURL">${jboss.server.base.dir}/chap10ex1-bindings.xml</attribute>
    <attribute name="StoreFactoryClassName">
        org.jboss.services.binding.XMLServicesStoreFactory
    </attribute>
</mbean>

속성 값은 다음과 같습니다:

  • ServerName: 어떤 서버에 설정을 적용할것인가를 구별하는데 사용되는 JBoss 인스턴스를 위한 고유한 이름입니다. 여기서 ${jboss.server.name} 변수는 설정 파일 셋의 디렉터리 이름으로 이 예제내의 jboss0 혹은 jboss1 중에 하나를 참조합니다.
  • StoreURL: 이것은 jboss0jboss1 인스턴스를 위한 오버라이드를 정의하는 ServicesStore 설정 데이터의 로케이션입니다. ${jboss.server.base.dir} 변수 레퍼런스는 JBoss 서버 디렉터리의 루트를 가르키는 URL 입니다. 우리는 예제 1 셋업에서 설치된 chap10ex1-bindings.xml을 사용하였습니다.
  • StoreFactoryClassName: 이것은 기본 XML 기반의 ServicesStore 구현이 적용됩니다.

chap10ex1-bindings.xml 파일에는 jboss0jboss1라는 이름을 갖는 두 개의 서버 설정을 포함하고 있습니다. jboss0 설정에서는 기본 포트 설정을 사용하는 반면, jboss1 설정에는 각 포트번호에 100을 더해준 번호를 사용합니다. 바인딩 파일은 서버의 이름으로 jboss0jboss1을 갖는 docs/examples.binding-service.sample-bindings.xml의 사본입니다.

바인딩 서비스 XMLServicesStoreFactory DTD

그림 10.3. 바인딩 서비스 XMLServicesStoreFactory DTD

그림 10.3, “바인딩 서비스 XMLServicesStoreFactory DTD”에서 보여주고 있는 DTD는 XMLServicesStoreFactory 클래스에서 지원하고 있는 것입니다. 요소들은 다음과 같습니다:

  • service-bindings: 설정 파일의 루트 요소. 하나 이상의 server 요소를 포함합니다.
  • server: 이것은 JBoss 서버 인스턴스 설정의 기본(base)입니다. 이것은 적용시킬 JBoss 인스턴스 이름을 정의하는 name 속성이 필요합니다. 이것은 ServiceBindingManagerServerName 속성 값과 관계있는 이름입니다. server 요소 컨텐츠는 하나 이상의 service-config 요소로 구성됩니다.
  • service-config: 이 요소는 MBean 서비스를 위한 설정 오버라이드를 표현합니다. 설정이 적용될 MBean 서비스의 JMX ObjectName 문자열인 name 속성을 필요로 합니다. 또한 대상 서비스에 대한 바인딩을 어떻게 처리해야 되는지 알고 있는 ServicesConfigDelegate 구현의 클래스 이름을 지정하는 delegateClass name 속성을 필요로 합니다. 이것은 delegate-config 옵션 요소와 한 개이상의 binding 요소들로 구성됩니다.
  • binding: binding 요소에는 포트의 이름, 주소 쌍을 지정합니다. 이것은 서비스를 위한 여러 바인딩을 지원하기 위해 사용할 수 있는 name 옵션도 갖습니다. 이것의 예로는 하나의 웹 컨테이너에 대해 여러 가상 호스트들이 있습니다. 포트번호와 주소는 각각 옵션으로 사용되는 port와 host 속성을 통해 지정합니다. 포트번호를 지정하지 않으면, 기본값은 0으로써, 임의의 포트를 선택하게 됩니다. host를 지정하지 않으면, 기본값은 null로써 임의의 주소를 사용하게 됩니다.
  • delegate-config: delegate-config 요소는 ServicesConfigDelegate 구현에 의해 사용되는 임의의 XML 조각(fragment)입니다. hostNameportName 속성은 단지 예제의 AttributeMappingDelegate에만 적용되며 AttributeMappingDelegate 설정내에 존재하는 것들에 대한 DTD 인식 편집기에서의 불만 제기를 방지하기 위해 있습니다. 일반적으로 delegate-config의 속성들과 컨텐츠 모두는 임의의 것이 되지만, 지정할 수 있는 방법은 없고 하나의 요소는 DTD와 함께 속성의 갯수에 제한은 없습니다.

두 개의 ServicesConfigDelegate 구현은 AttributeMappingDelegateXSLTConfigDelegate 입니다. AttributeMappingDelegate 클래스는 다음과 같은 폼으로 delegate-config 요소가 오게 되는 ServicesConfigDelegate의 구현입니다:

<delegate-config portName="portAttrName" hostName="hostAttrName">
    <attribute name="someAttrName">someHostPortExpr</attribute>
    <!-- ... -->
</delegate-config>

portAttrName은 MBean 서비스의 적용되어져야하는 바인딩 포트를 가르키는 속성 이름이며, hostAttrName은 적용되어져야 하는 바인딩 호스트 값을 가르키는 MBean 서비스의 속성 이름입니다. 이와 유사하게, hostName 속성을 지정하지 않는다면, 바인딩 호스트는 적용되지 않습니다. 옵션으로 사용되는 attribute 요소들에서 자신의 값이 host 그리고/또는 포트 설정의 함수인 임의의 MBean 속성을 지정합니다. 속성 컨텐츠내에서 ${host}를 참조하는 것들은 호스트 바인등으로 대체되며 ${port}를 참조하는 것들은 포트 바인딩으로 대체됩니다. portName, hostName 속성 값들과 attribute 요소 컨텐츠는 JBoss 서비스 서술자에서 지원하고 있는 ${x} 문법을 사용하여 시스템 속성을 참조할 수 있습니다.

다음에 오는 에제에서는 AttributeMappingDelegate의 사용법을 보여주고 있습니다.

<service-config name="jboss:service=Naming"
                 delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
     <delegate-config portName="Port"/>
     <binding port="1099" />
</service-config>

여기서 jboss:service=Naming MBean 서비스는 자신의 Port 속성 값을 1099로 덮어씁니다. jboss1 서버 설정으로부터 이에 대응되는 설정은 포트를 1199로 덮어씁니다.

XSLTConfigDelegate 클래스는 다음 폼의 delegate-config 요소에 오게 되는 ServicesConfigDelegate의 구현입니다:

<delegate-config>
    <xslt-config configName="ConfigurationElement"><![CDATA[
        Any XSL document contents...
        ]]>
     </xslt-config>
     <xslt-param name="param-name">param-value</xslt-param>
     <!-- ... -->
</delegate-config>

xslt-config 자식 요소 컨텐츠에서는 configName 속성에 의해 이름이 주어지는 MBean 서비스 속성에 적용되어지는 임의의 XSL 스크립트 조각을 지정합니다. 이름이 붙은 속성은 org.w3c.dom.Element 타입이어야만 합니다. xslt-param 옵션 요소에서는 스크립트내에서 사용되는 매개변수들을 위한 XSL 스크립트 매개변수 값들을 지정합니다. 기본 호출되는 호스트와 포트에서 정의되는 두 개의 XSL 매개변수가 있으며, 이 값들은 호스트와 포트 바인딩 환경을 설정합니다.

XSLTConfigDelegate 중첨된 XML 조각을 사용하여 지정되어진 port/interface 설정을 갖는 서비스를 변환하는데 사용되어집니다. 다음에 오는 예제에서는 톰캣 서블릿 컨테이너가 8180 포트로 수신되고 8109 포트로 AJP 수신이 되도록 매핑되어 있는 jboss1 서버 섹션의 예를 보여주고 있습니다:

      <!-- jbossweb-tomcat50.sar -->
      <service-config name="jboss.web:service=WebServer"
         delegateClass="org.jboss.services.binding.XSLTFileDelegate"
         >
         <delegate-config>
            <xslt-config configName="ConfigFile"><![CDATA[
   <xsl:stylesheet
         xmlns:xsl='http://www.w3.org/1999/XSL/Transform' version='1.0'>

     <xsl:output method="xml" />
     <xsl:param name="port"/>

     <xsl:variable name="portAJP" select="$port - 71"/>
     <xsl:variable name="portHttps" select="$port + 363"/>

     <xsl:template match="/">
       <xsl:apply-templates/>
     </xsl:template>

      <xsl:template match = "Connector">
         <Connector>
            <xsl:for-each select="@*">
            <xsl:choose>
               <xsl:when test="(name() = 'port' and . = '8080')">
                  <xsl:attribute name="port"><xsl:value-of select="$port" />
                  </xsl:attribute>
               </xsl:when>
               <xsl:when test="(name() = 'port' and . = '8009')">
                  <xsl:attribute name="port"><xsl:value-of select="$portAJP" />
                  </xsl:attribute>
               </xsl:when>
               <xsl:when test="(name() = 'redirectPort')">
                  <xsl:attribute name="redirectPort"><xsl:value-of select="$portHttps" />
                  </xsl:attribute>
               </xsl:when>
               <xsl:when test="(name() = 'port' and . = '8443')">
                  <xsl:attribute name="port"><xsl:value-of select="$portHttps" />
                  </xsl:attribute>
               </xsl:when>
               <xsl:otherwise>
                  <xsl:attribute name="{name()}"><xsl:value-of select="." />
                  </xsl:attribute>
               </xsl:otherwise>
            </xsl:choose>
            </xsl:for-each>
            <xsl:apply-templates/>
         </Connector>
      </xsl:template>

     <xsl:template match="*|@*">
       <xsl:copy>
         <xsl:apply-templates select="@*|node()"/>
       </xsl:copy>
     </xsl:template>
   </xsl:stylesheet>
   ]]>
            </xslt-config>
         </delegate-config>
         <binding port="8180"/>
      </service-config>

샘플 설정을 테스트하려면, 앞에서 chap10 example1 빌드를 실행시켜 생성시킨 jboss0jboss1 설정 파일 셋을 사용하여 두 JBoss 인스턴스를 시작시키면 됩니다. 서비스 포트 번호에 대한 콘솔 아웃풋을 살펴본다면, 여러분은 매핑이 덮어씌여졌다는 것을 확인하실 수 있습니다. 예제의 jboss1 서버에서는 비표준의 포트들이 사용된다는 것을 알 수 있습니다:

16:04:39,246 INFO  [WebService] Using RMI server codebase: http://toki.local:8183/
16:04:40,442 INFO  [NamingService] Started jnpPort=1199, rmiPort=1198, backlog=50, bindAddress=/0.0.0.0, 
Client SocketFactory=null, Server SocketFactory=org.jboss.net.sockets.DefaultSocketFactory@ad093076
16:05:28,596 INFO  [Http11Protocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8180
16:05:55,165 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8180
16:05:56,061 INFO  [ChannelSocket] JK2: ajp13 listening on /0.0.0.0:8109

10.4. 스케쥴링 업무

자바에는 java.util.Timerjava.util.TimerTask 유틸리티 클래스를 통해 간단한 타이머 기반의 기능을 포함하고 있습니다. 또한 JMX에는 javax.management.timer.TimerMBean 에이전트 서비스와 같은 주기적인 반복이 가능한 스케쥴링 JMX 통지 메커니즘도 포함하고 있습니다.

JBoss에는 org.jboss.varia.scheduler.Schedulerorg.jboss.varia.scheduler.ScheduleManager MBeans에서 JMX 타이머 서비스의 두 변형을 포함하고 있습니다. 두 MBeans은 기본 스케쥴링을 위한 JMX 타이머 서비스에 관련됩니다. 이 MBean들은 다음 섹션에 논의되는 것 처럼 타이머 서비스의 특성을 확장했습니다.

10.4.1. org.jboss.varia.scheduler.Scheduler

사용자 정의 클래스나 사용자가 지정한 MBean의 오퍼레이션에 대한 콜백을 직접 호출하는 SchedulerTimerMBean는 다릅니다.

  • InitialStartDate: 첫 호출이 예약된 날짜. 이 값은 다음과 같아야 합니다:

    • NOW: 현재 시간에 1초를 더한 날짜
    • 1/1/1970년 이후부터의 밀리세컨즈 숫자로 표시
    • 기본 포맷 패턴인 "M/d/yy h:mm a"를 갖는 SimpleDateFormat으로 해석되어질 수 있는 문자열형태의 날짜. 날짜가 지난 경우, Scheduler는 앞으로 다시 반복될 시작 날짜를 찾고 다음 주기에 호출을 할 수 있도록 합니다. 즉, 여러분이 MBean을 재시작(JBoss등을 재시작시킴으로써)시키게 되면, 다음 번 스케쥴링된 시간에 시작되어진 다는 것입니다. 앞으로 시작될 날짜가 가능하지 않은 경우, Scheduler는 시작되지 않게 됩니다.

    예를 들어, 매일 정오에 여러분의 Schedulable을 시작시키고 다시 JBoss 서버를 시작시키면, 이것은 다음 번 정도에(정오 이전에 시작되었다면 동일하게 적용되고, 정오가 지난 후 시작시켰다면 다음 날 정오가 됨) 시작됩니다.

  • InitialRepetitions: 스케쥴러가 대상 콜백의 호출하게 되는 횟수. -1이면, 콜백은 서버가 중지될때까지 반복되게 됩니다.
  • StartAtStartup: Scheduler가 시작되면 자신의 startService 생명 주기 통지를 수신받는지를 결정해주는 플래그. true인 경우, 자신이 시작되면서 Scheduler가 시작됩니다. false의 경우, Scheduler가 시작될 때 명시적으로 startSchedule 오퍼레이션이 호출되어야 합니다.
  • SchedulePeriod: 스케쥴링된 호출사이 간격을 밀리세컨즈 단위로 지정. 이 값은 반드시 0보다 커야만 합니다.
  • SchedulableClass: Scheduler에 의해 사용되어질 org.jboss.varia.scheduler.Schedulable 인터페이스 구현의 완전한 형태를 갖는 클래스 이름. SchedulableArgumentsSchedulableArgumentTypesSchedulable 구현의 컨스트럭쳐에 일치하도록 생성되어져야만 합니다.
  • SchedulableArguments: Schedulable 구현 클래스 컨스트럭쳐에 대한 인수의 컴마로 구분된 리스트. 오직 기본 데이터 타입인 String과 자신의 단일 인수로써 String을 받아들이는 컨스트럭쳐를 갖는 클래스가 지원됩니다.
  • SchedulableArgumentTypes: Schedulable 구현 클래스 컨스트럭쳐에 대한 인수 타입의 컴마로 분리된 리스트. 이것은 리플렉션(reflection)을 통해 올바른 컨스트럭쳐를 찾는데 사용됩니다. 오직 기본 데이터 타입인 String과 자신의 단일 인수로써 String을 받아들이는 컨스트럭쳐를 갖는 클래스가 지원됩니다.
  • SchedulableMBean: 호출되어지기 위한 스케쥴링가능한 MBean의 완전한 형태를 갖는 JMX ObjectName을 지정합니다. 사용가능한 MBean이 없다면, 호출되지 않으나 남은 반복횟수는 감소되게 됩니다. SchedulableMBean을 사용하는 경우, SchedulableMBeanMethod는 반드시 지정되어져야만 합니다.
  • SchedulableMBeanMethod: 스케쥴링가능한 MBean에 대해 호출되어질 수 있는 오퍼레이션 이름을 지정합니다. 이것 다음에는 꺾음 괄호(bracket)를 열고 매개변수 키워드의 콤마로 분리된 리스트와 꺾음 괄호 닫기가 선택적으로 오게됩니다. 지원되는 매개변수 키워드는 다음과 같습니다:

    • NOTIFICATION 타이머 통지 인스턴스로 대체되어집니다 (javax.management.Notification)
    • DATE 통지 호출 날짜로 대체되어집니다 (java.util.Date)
    • REPETITIONS 남은 반복횟수(repetition)로 대체되어집니다 (long)
    • SCHEDULER_NAME SchedulerObjectName으로 대체되어집니다
    • Scheduler가 null로 설정되어지는 임의의 완전한 형태를 갖는 클래스 이름.

주어진 스케쥴러 인스턴스는 오직 단일 스케쥴링가능한 인스턴스만을 지원합니다. 여러 스케쥴링된 이벤트를 설정하고자 한다면, 여러 Scheduler 인스턴스를 사용해야 하고, 그 각각은 고유한 ObjectName을 갖아야 합니다. 다음에 오는 예제는 Schedulable 구현을 호출하는 Scheduler 설정뿐만 아니라 MBean을 호출하는 설정까지도 포함하고 있습니다.

예제 10.2. jboss-service 서술자에서의 스케쥴러 예제

<server>
                 
    <mbean code="org.jboss.varia.scheduler.Scheduler"
           name="jboss.docs.chap10:service=Scheduler">
        <attribute name="StartAtStartup">true</attribute>
        <attribute name="SchedulableClass">org.jboss.chap10.ex2.ExSchedulable</attribute>
        <attribute name="SchedulableArguments">TheName,123456789</attribute>
        <attribute name="SchedulableArgumentTypes">java.lang.String,long</attribute>
                 
        <attribute name="InitialStartDate">NOW</attribute>
        <attribute name="SchedulePeriod">60000</attribute>
        <attribute name="InitialRepetitions">-1</attribute>
    </mbean>
                 
</server> 

SchedulableClass org.jboss.chap10.ex2.ExSchedulable 예제 클래스를 예제 10.3, “ExSchedulable 클래스 코드”에서 보여주고 있습니다.

예제 10.3. ExSchedulable 클래스 코드

package org.jboss.chap10.ex2;

import java.util.Date;
import org.jboss.varia.scheduler.Schedulable;

import org.apache.log4j.Logger;

/**
 * 간단한 스케쥴링가능한 예제.
 * @author Scott.Stark@jboss.org
 * @version $Revision: 1.7 $
 */
public class ExSchedulable implements Schedulable
{
    private static final Logger log = Logger.getLogger(ExSchedulable.class);

    private String name;
    private long value;

    public ExSchedulable(String name, long value)
    {
        this.name = name;
        this.value = value;
        log.info("ctor, name: " + name + ", value: " + value);
    }

    public void perform(Date now, long remainingRepetitions)
    {
        log.info("perform, now: " + now +
                 ", remainingRepetitions: " + remainingRepetitions +
                 ", name: " + name + ", value: " + value);
    }
}

다음과 같이 실행시켜 타이머 sar를 배치합니다:

[nr@toki examples]$ ant -Dchap=chap10 -Dex=2 run-example
...
run-example2:
     [copy] Copying 1 file to /tmp/jboss-3.2.6/server/default/deploy

서버 콘솔에서는 다음과 같은 처음 두 타이머 호출을 60초 간격으로 보여주게 됩니다: :

16:44:49,275 INFO  [ExSchedulable] ctor, name: TheName, value: 123456789
16:44:50,365 INFO  [ExSchedulable] perform, now: Fri Oct 15 16:44:50 CDT 2004, remainingRe
petitions: -1, name: TheName, value: 123456789
16:45:50,317 INFO  [ExSchedulable] perform, now: Fri Oct 15 16:45:50 CDT 2004, remainingRe
petitions: -1, name: TheName, value: 123456789
16:46:50,319 INFO  [ExSchedulable] perform, now: Fri Oct 15 16:46:50 CDT 2004, remainingRe
petitions: -1, name: TheName, value: 123456789

10.5. JBoss 로깅 프레임워크

3.2 버전부터 JBoss의 로깅 프레임워크에서 임의의 특정 프레임워크 구현에 대한 로깅을 허용할 수 있도록 범용화되었습니다. JBoss 클래스 자체는 팩토리와 로깅 인터페이스로써 org.jboss.logging.Logger를 사용합니다. 이 클래스는 추적 레벨 우선권에 대한 지원 추가와 함께 Log4j org.apache.log4j.Logger 클래스에 본질적으로는 동일합니다. Logger 클래스는 LoggerPlugin 인스턴스에 위임합니다. LoggerLoggerPlugin에 대한 클래스 다이어그램이 그림 10.4, “JBoss 로깅 프레임워크 클래스”에 보여지고 있습니다.

JBoss 로깅 프레임워크 클래스.

그림 10.4. JBoss 로깅 프레임워크 클래스.

기본적으로 우리는 로깅 구현의 바탕으로 Log4j 프레임워크를 계속해서 사용하는데 이것이 org.jboss.logging.Log4jLoggerPlugin에서 제공하는 것입니다. 교체가능한 로깅 구현과 통합하려면, 여러분은 LoggerPlugin 인터페이스의 구현을 제공하고 구현 클래스 이름을 org.jboss.logging.Logger.pluginClass 시스템 속성을 설정함으로써 사용할 수 있도록 지정해야 합니다. 모든 로깅을 사용하지 않으려면, org.jboss.logging.NullLoggerPlugin을 사용하면 됩니다. 이 구현은 간단한 빈 버전의 LoggerPlugin 메쏘드를 제공합니다.

10.5.1. org.jboss.logging.Log4jService

Log4jService MBean은 아파치 log4j 시스템을 설정합니다. JBoss는 자신의 내부 로깅 API로써 log4j 프레임워크를 사용합니다.

  • ConfigurationURL: log4j 설정 파일에 대한 URL 입니다. 이것은 org.apache.log4j.xml.DOMConfigurator에 의해 해석되는 XML 문서나 org.apache.log4j.PropertyConfigurator에 의해 해석되는 자바 속성 파일중에 하나를 참조할 수 있습니다. 파일의 타입은 URL 컨텐츠 타입에 의해 결정되나, 널인 경우 파일 확장자에 의해 결정됩니다. resource:log4j.xml의 기본 설정은 활성화된 서버의 설정 파일 셋의 conf/log4j.xml 파일을 참조합니다.
  • RefreshPeriod: ConfigurationURL 속성에 의해 지정된 log4 설정내의 변경사항을 점검하는 간격의 초단위로 지정합니다. 기본 값은 60초 입니다.
  • CatchSystemErr: 부울린 플래그로 true인 경우에는 System.err 스트림이 log4j의 STDERR이라는 카테고리로 리다이렉트되어지게 됩니다. 기본값은 true 입니다.
  • CatchSystemOut: 이 부울린 플래그가 true인 경우에는 System.out 스트림이 log4j의 STDOUT이라 불리는 카테고리쪽에 리다이렉트되도록 가르킵니다. 기본값은 true 입니다.
  • Log4jQuietMode: 이 부울린 플래그가 true이면 org.apache.log4j.helpers.LogLog.setQuiteMode로 설정됩니다. log4j 1.2.8에서 이것은 appender 레벨에서 발생될 수 있는 교착(deadlock)을 피할 수 있도록 하기 위해 설정될 필요가 있습니다. 버그#696819 를 참조하십시오.

10.6. RMI 동적 클래스 로딩

10.6.1. org.jboss.web.WebService

WebService MBean에서는 서버 EJB에 액세스하는 RMI 액세스에 대한 동적인 클래스 로딩을 지원합니다. WebService에 대한 설정가능한 속성들은 다음과 같습니다:

  • Port: WebService 수신 포트의 번호. 0인 경우에는 임의의 사용가능한 포트가 됩니다.
  • Host: RMI 코드베이스 URL의 호스트 부분에 대한 사용을 위해 공용 인터페이스의 이름을 설정합니다.
  • BindAddress: WebService를 수신하는 주소를 지정합니다. 이것은 랜카드가 여러개 설치되어 있는 호스트에서 자신의 주소중 하나의 주소만으로 연결 요청을 수신하도록 하는 java.net.ServerSocket에 대해 사용할 수 있습니다.
  • Backlog: 들어오는 커넥션 표시에 대한 최대 큐 길이는 backlog 매개변수로 설정합니다. 커넥션 표시가 도착했을 때 큐가 차있다면, 커넥션은 거부됩니다.
  • DownloadServerClasses: 서버가 클래스 로더의 키 접두사를 갖지 않는 요청이 도착하면 쓰레드 컨텍스트 클래스 로더로부터 클래스를 다운로드 받는 시도를 해야하는지 가르키는 플래그입니다.