개발 가이드


Red Hat JBoss Enterprise Application Platform 7.4

Red Hat JBoss Enterprise Application Platform을 위한 Jakarta EE 애플리케이션 개발 지침.

Red Hat Customer Content Services

초록

이 문서에서는 보안성과 확장성이 뛰어난 자카르타 EE 애플리케이션을 신속하게 개발하기 위한 지침과 정보를 제공합니다. 개발 환경 설정,Maven 리포지토리 사용, 배포에서 클래스 로드에 대해 알아봅니다. 이 문서에는 다음과 같은 자세한 정보가 있습니다.

JBoss EAP 문서에 대한 피드백 제공

오류를 보고하거나 문서를 개선하기 위해 Red Hat Jira 계정에 로그인하여 문제를 제출하십시오. Red Hat Jira 계정이 없는 경우 계정을 생성하라는 메시지가 표시됩니다.

절차

  1. 티켓을 생성하려면 다음 링크를 클릭하십시오.
  2. 문서 URL, 섹션 번호 를 포함하고 문제를 설명하십시오.
  3. 요약 에 문제에 대한 간략한 설명을 입력합니다.
  4. 설명에서 문제 또는 개선 사항에 대한 자세한 설명을 제공합니다. 문서에서 문제가 발생한 위치에 URL을 포함합니다.
  5. Submit 을 클릭하고 문제를 적절한 문서 팀으로 라우팅합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

1장. 애플리케이션 개발 시작

1.1. Jakarta EE 정보

1.1.1. 자카르타 EE 8

JBoss EAP 7은 Jakarta EE Web Profile 및 Jakarta EE Platform 사양 모두를 위한 Jakarta EE 8 호환 구현입니다.

Jakarta EE 8에 대한 자세한 내용은 Jakarta EE 정보를 참조하십시오.

1.1.2. Jakarta EE 프로필 개요

자카르타 EE는 다양한 프로필을 정의합니다. 각 프로필은 특정 애플리케이션 클래스에 적합한 구성을 나타내는 API의 하위 집합입니다.

Jakarta EE 8에서는 Web Profile 및 Platform 프로파일에 대한 사양을 정의합니다. 제품은 플랫폼, 웹 프로필 또는 하나 이상의 사용자 지정 프로필을 조합하여 구현할 수 있습니다.

  • Jakarta EE Web Profile에는 웹 애플리케이션 개발에 유용할 수 있도록 설계된 선택된 API 하위 집합이 포함되어 있습니다.
  • Jakarta EE Platform 프로필에는 Jakarta EE 8 Web Profile에서 정의한 API와 엔터프라이즈 애플리케이션 개발에 유용한 전체 Jakarta EE 8 API 세트가 포함되어 있습니다.

JBoss EAP 7.4는 Web Profile 및 Full Platform 사양을 위한 Jakarta EE 8 호환 구현입니다.

Jakarta EE 8 API의 전체 목록은 Jakarta EE 사양을 참조하십시오.

1.2. 개발 환경 설정

  1. Red Hat CodeReady Studio 다운로드 및 설치.

    자세한 내용은 Red Hat CodeReady Studio 설치 가이드에서 Installer를 사용하여 CodeReady Studio 독립 실행형 설치 가이드를 참조하십시오.

  2. Red Hat CodeReady Studio에서 JBoss EAP 서버를 설정합니다.

    자세한 내용은 CodeReady Studio Tools 가이드 의 IDE 내에서 JBoss EAP 다운로드, 설치 및 설정을 참조하십시오.

1.3. Red Hat CodeReady Studio에서 주석 처리 구성

Eclipse에서는 기본적으로 주석 처리(AP)가 꺼져 있습니다. 프로젝트가 구현 클래스를 생성하는 경우 java.lang.ExceptionInInitializerError 예외가 발생하고, 프로젝트를 배포할 때 CLASS_NAME (implementation not found) 오류 메시지가 표시될 수 있습니다.

다음 방법 중 하나로 이러한 문제를 해결할 수 있습니다. 개별 프로젝트의 주석 처리를 활성화하거나 모든 Red Hat CodeReady Studio 프로젝트에서 주석 처리를 전역적으로 활성화할 수 있습니다.

개별 프로젝트의 주석 처리 활성화

특정 프로젝트에 대한 주석 처리를 활성화하려면 프로젝트의 pom .xml 파일에 jdt_apt 값이 있는 m2e. apt.activation 속성을 추가해야 합니다.

<properties>
    <m2e.apt.activation>jdt_apt</m2e.apt.activation>
</properties>
Copy to Clipboard Toggle word wrap

이 기술의 예는 JBoss EAP와 함께 제공되는 logging-tools 및 equipmentsink- 빠른 시작pom.xml 파일에서 확인할 수 있습니다.

Red Hat CodeReady Studio에서 전 세계에 주석 처리 활성화
  1. 기본 설정을 선택합니다.
  2. Maven 을 확장하고 Annotation Processing (주석 처리)를 선택합니다.
  3. Select Annotation Processing Mode (주석 처리 모드 선택) 에서 Automatically configure JDT APT(JDT APT 자동 구성)를 선택합니다(빌드 속도가 더 빠르지만 Maven 빌드와 다를 수 있음)를 선택한 다음 Apply(적용) 및 Close (닫기)를 클릭합니다.

1.4. 기본 시작 웹 애플리케이션 설정

JBoss EAP에는 기본적으로 포트 8080 의 루트 컨텍스트에 표시되는 기본 Welcome 애플리케이션이 포함되어 있습니다.

이 기본 Welcome 애플리케이션은 자체 웹 애플리케이션으로 교체할 수 있습니다. 다음 두 가지 방법 중 하나로 구성할 수 있습니다.

시작 콘텐츠를 비활성화할 수도 있습니다.

welcome-content 파일 핸들러 변경
  1. 기존 welcome-content 파일 핸들러의 경로를 새 배포를 가리키도록 수정합니다.

    /subsystem=undertow/configuration=handler/file=welcome-content:write-attribute(name=path,value="/path/to/content")
    Copy to Clipboard Toggle word wrap
    참고

    또는 서버의 루트에서 사용할 다른 파일 핸들러를 생성할 수도 있습니다.

    /subsystem=undertow/configuration=handler/file=NEW_FILE_HANDLER:add(path="/path/to/content")
    /subsystem=undertow/server=default-server/host=default-host/location=\/:write-attribute(name=handler,value=NEW_FILE_HANDLER)
    Copy to Clipboard Toggle word wrap
  2. 변경 사항을 적용하려면 서버를 다시 로드합니다.

    reload
    Copy to Clipboard Toggle word wrap
default-web-module 변경
  1. 배포된 웹 애플리케이션을 서버의 루트에 매핑합니다.

    /subsystem=undertow/server=default-server/host=default-host:write-attribute(name=default-web-module,value=hello.war)
    Copy to Clipboard Toggle word wrap
  2. 변경 사항을 적용하려면 서버를 다시 로드합니다.

    reload
    Copy to Clipboard Toggle word wrap
기본 시작 웹 애플리케이션 비활성화
  1. default-host위치 항목 / 를 제거하여 시작 애플리케이션을 비활성화합니다.

    /subsystem=undertow/server=default-server/host=default-host/location=\/:remove
    Copy to Clipboard Toggle word wrap
  2. 변경 사항을 적용하려면 서버를 다시 로드합니다.

    reload
    Copy to Clipboard Toggle word wrap

2장. JBoss EAP에서 Maven 사용

2.1. Maven에 대해 알아보기

2.1.1. Maven 리포지토리 정보

Apache Maven은 Java 애플리케이션 개발에 사용되는 분산 빌드 자동화 도구로 소프트웨어 프로젝트를 생성, 관리 및 빌드합니다. Maven은 Project Object Model 또는 POM이라는 표준 구성 파일을 사용하여 프로젝트를 정의하고 빌드 프로세스를 관리합니다. Poms는 XML 파일을 사용하여 결과 프로젝트 패키징 및 출력의 모듈 및 구성 요소 종속성, 빌드 순서 및 타겟을 설명합니다. 이렇게 하면 프로젝트가 올바르고 일관된 방식으로 구축됩니다.

Maven은 리포지토리를 사용하여 이를 수행합니다. Maven 리포지토리는 Java 라이브러리, 플러그인 및 기타 빌드 아티팩트를 저장합니다. 기본 공용 리포지토리는 Maven 2 중앙 리포지토리이지만, 개발 팀 간에 공통 아티팩트를 공유하는 목표를 사용하여 회사 내에서 개인 및 내부 리포지토리가 될 수 있습니다. 타사에서 리포지토리를 사용할 수도 있습니다. JBoss EAP에는 Jakarta EE 개발자가 JBoss EAP에서 애플리케이션을 빌드하는 데 일반적으로 사용하는 많은 요구 사항이 포함된 Maven 리포지토리가 포함되어 있습니다. 이 리포지토리를 사용하도록 프로젝트를 구성하려면 JBoss EAP Maven 리포지토리 구성을 참조하십시오.

Maven에 대한 자세한 내용은 Welcome to Apache Maven 을 참조하십시오.

Maven 리포지토리에 대한 자세한 내용은 Apache Maven Project - Introduction to Repositories (리포지토리 소개)를 참조하십시오.

2.1.2. Maven POM 파일 정보

프로젝트 오브젝트 모델(POM) 파일은 Maven에서 프로젝트를 빌드하는 데 사용하는 구성 파일입니다. 프로젝트에 대한 정보와 소스, 테스트 및 대상 디렉터리의 위치, 테스트 및 대상 디렉터리, 프로젝트 종속성, 플러그인 리포지토리 및 실행할 수 있는 목표를 포함하여 프로젝트에 대한 정보가 포함된 XML 파일입니다. 또한 버전, 설명, 개발자, 메일링 리스트, 라이센스 등 프로젝트에 대한 추가 세부 정보를 포함할 수 있습니다. pom.xml 파일에는 일부 구성 옵션이 필요하며 다른 모든 옵션은 기본값으로 설정됩니다.

pom.xml 파일의 스키마는 http://maven.apache.org/maven-v4_0_0.xsd 에 있습니다.

POM 파일에 대한 자세한 내용은 Apache Maven 프로젝트 POM 참조를 참조하십시오.

Maven POM 파일의 최소 요구 사항

pom.xml 파일의 최소 요구 사항은 다음과 같습니다.

  • 프로젝트 루트
  • modelVersion
  • groupid - 프로젝트 그룹의 ID
  • artifactId - 아티팩트의 ID (프로젝트)
  • Version - 지정된 그룹의 아티팩트 버전

예제: 기본 pom.xml 파일

기본 pom.xml 파일은 다음과 같을 수 있습니다.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.jboss.app</groupId>
  <artifactId>my-app</artifactId>
  <version>1</version>
</project>
Copy to Clipboard Toggle word wrap

2.1.3. Maven 설정 파일 정보

Maven settings.xml 파일에는 Maven에 대한 사용자별 구성 정보가 포함되어 있습니다. 여기에는 개발자 ID, 프록시 정보, 로컬 리포지토리 위치 및 사용자와 관련된 기타 설정과 같은 pom.xml 파일과 함께 배포해서는 안 되는 정보가 포함되어 있습니다.

settings.xml을 찾을 수 있는 위치는 두 가지가 있습니다.

  • Maven 설치에서 다음을 수행합니다. 설정 파일은 $M2_HOME/conf/ 디렉터리에 있습니다. 이러한 설정을 전역 설정이라고 합니다. 기본 Maven 설정 파일은 사용자 설정 파일의 시작점으로 복사하고 사용할 수 있는 템플릿입니다.
  • 사용자 설치에서 다음을 수행합니다. 설정 파일은 ${user.home}/.m2/ 디렉터리에 있습니다. Maven 및 사용자 settings.xml 파일이 모두 있는 경우 내용이 병합됩니다. 중복되는 경우 사용자의 settings.xml 파일이 우선합니다.

예제: Maven 설정 파일

<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <profiles>
    <!-- Configure the JBoss EAP Maven repository -->
    <profile>
      <id>jboss-eap-maven-repository</id>
      <repositories>
        <repository>
          <id>jboss-eap</id>
          <url>file:///path/to/repo/jboss-eap-7.4.0-maven-repository/maven-repository</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>jboss-eap-maven-plugin-repository</id>
          <url>file:///path/to/repo/jboss-eap-7.4.0-maven-repository/maven-repository</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
        </pluginRepository>
      </pluginRepositories>
    </profile>
  </profiles>
  <activeProfiles>
    <!-- Optionally, make the repository active by default -->
    <activeProfile>jboss-eap-maven-repository</activeProfile>
  </activeProfiles>
</settings>
Copy to Clipboard Toggle word wrap

settings.xml 파일의 스키마는 http://maven.apache.org/xsd/settings-1.0.0.xsd 에서 찾을 수 있습니다.

2.1.4. Maven 리포지토리 관리자 정보

리포지토리 관리자는 Maven 리포지토리를 쉽게 관리할 수 있는 툴입니다. 리포지토리 관리자는 다음과 같은 여러 가지 방법으로 유용합니다.

  • 조직과 원격 Maven 리포지토리 간에 프록시를 구성할 수 있는 기능을 제공합니다. 이는 더욱 빠르고 효율적인 배포를 비롯하여 Maven에서 다운로드한 항목에 대한 보다 나은 제어 수준을 비롯하여 여러 가지 이점을 제공합니다.
  • 자체 생성된 아티팩트를 위한 배포 대상을 제공하여 조직 간 다양한 개발 팀 간의 협업이 가능합니다.

Maven 리포지토리 관리자에게 대한 자세한 내용은 모범 사례 - 리포지토리 관리자 사용을 참조하십시오.

일반적으로 사용되는 Maven 리포지토리 관리자
참고

리포지토리 관리자가 일반적으로 사용되는 엔터프라이즈 환경에서 Maven은 이 관리자를 사용하여 모든 프로젝트의 모든 아티팩트를 쿼리해야 합니다. Maven은 선언된 모든 리포지토리를 사용하여 누락된 아티팩트를 찾기 때문에 원하는 항목을 찾을 수 없는 경우 리포지토리 중앙에서 해당 리포지토리(기본 제공 상위 POM에 정의되어 있음)에서 찾습니다. 이 중앙 위치를 재정의하려면 기본 리포지토리가 중앙 리포지토리가 될 수 있도록 정의를 중앙 으로 추가할 수 있습니다. 이 작업은 이미 구축된 프로젝트에 적합하지만, 클린 또는 'new' 프로젝트의 경우 재활용 종속성이 생성되기 때문에 문제가 발생합니다.

2.2. Maven 및 JBoss EAP Maven 리포지토리 설치

2.2.1. Maven 다운로드 및 설치

Maven을 다운로드하고 설치하려면 다음 단계를 따르십시오.

  • Red Hat CodeReady Studio를 사용하여 애플리케이션을 빌드 및 배포하는 경우 다음 절차를 건너뜁니다. Maven은 Red Hat CodeReady Studio와 함께 배포됩니다.
  • Maven 명령줄을 사용하여 애플리케이션을 빌드하고 JBoss EAP에 배포하는 경우 Maven을 다운로드하고 설치해야 합니다.

    1. Apache Maven 프로젝트로 이동 - Maven 을 다운로드하고 운영 체제에 대한 최신 배포를 다운로드합니다.
    2. 운영 체제용 Apache Maven을 다운로드하고 설치하는 방법에 대한 자세한 내용은 Maven 문서를 참조하십시오.

2.2.2. JBoss EAP Maven 리포지토리 다운로드

두 방법 중 하나를 사용하여 JBoss EAP Maven 리포지토리를 다운로드할 수 있습니다.

2.2.2.1. JBoss EAP Maven 리포지토리 ZIP 파일 다운로드

다음 단계에 따라 JBoss EAP Maven 리포지토리를 다운로드합니다.

  1. Red Hat 고객 포털에서 JBoss EAP 다운로드 페이지에 로그인합니다.
  2. Version(버전) 드롭다운 메뉴에서 7.4 를 선택합니다.
  3. 목록에서 Red Hat JBoss Enterprise Application Platform 7.4 Maven 리포지토리 항목을 찾고 다운로드를 클릭하여 리포지토리가 포함된 ZIP 파일을 다운로드합니다.
  4. ZIP 파일을 원하는 디렉토리에 저장합니다.
  5. ZIP 파일을 추출합니다.

Offliner 애플리케이션은 Red Hat Maven 리포지토리를 사용하여 JBoss EAP 애플리케이션을 개발하기 위한 Maven 아티팩트를 다운로드하는 대체 옵션으로 사용할 수 있습니다.

중요

Offliner 애플리케이션을 사용하여 JBoss EAP Maven 리포지토리를 다운로드하는 프로세스는 기술 프리뷰로만 제공됩니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.

  1. Red Hat 고객 포털에서 JBoss EAP 다운로드 페이지에 로그인합니다.
  2. Version(버전) 드롭다운 메뉴에서 7.4 를 선택합니다.
  3. 목록에서 Red Hat JBoss Enterprise Application Platform 7.4 Maven Repository Offliner Content List 항목을 찾고 다운로드를 클릭합니다.
  4. 텍스트 파일을 원하는 디렉터리에 저장합니다.

    참고

    이 파일에는 라이센스 정보가 포함되어 있지 않습니다. Offliner 애플리케이션에서 다운로드한 아티팩트는 JBoss EAP와 함께 배포되는 Maven 리포지토리 ZIP 파일에 지정된 것과 동일한 라이센스를 갖습니다.

  5. Maven 중앙 리포지토리에서 Offliner 애플리케이션을 다운로드합니다.
  6. 다음 명령을 사용하여 Offliner 애플리케이션을 실행합니다.

    $ java -jar offliner.jar -r http://repository.redhat.com/ga/ -d DOWNLOAD_FOLDER jboss-eap-7.4.0-maven-repository-content-with-sha256-checksums.txt
    Copy to Clipboard Toggle word wrap

    JBoss EAP Maven 리포지토리의 아티팩트는 DOWNLOAD_FOLDER 디렉터리에 다운로드됩니다.

Offliner 애플리케이션 실행에 대한 자세한 내용은 Offliner 설명서 를 참조하십시오.

참고

생성된 JBoss EAP Maven 리포지토리에는 현재 JBoss EAP Maven 리포지토리 ZIP 파일에서 사용할 수 있는 것과 동일한 내용이 있습니다. Maven Central 리포지토리에서 사용할 수 있는 아티팩트를 포함하지 않습니다.

2.2.3. JBoss EAP Maven 리포지토리 설치

온라인으로 사용 가능한 JBoss EAP Maven 리포지토리를 사용하거나 나열된 세 가지 방법 중 하나를 사용하여 로컬로 다운로드하여 설치할 수 있습니다.

2.2.3.1. JBoss EAP Maven 리포지토리를 로컬에 설치합니다.

이 옵션을 사용하여 JBoss EAP Maven 리포지토리를 로컬 파일 시스템에 설치합니다. 이 기능은 구성하기 쉽고 로컬 시스템에서 신속하게 가동하고 실행할 수 있습니다.

중요

이 방법은 개발에 Maven을 사용하는 방법을 익히는 데 도움이 될 수 있지만 팀 프로덕션 환경에는 권장되지 않습니다.

새 Maven 리포지토리를 다운로드하기 전에 사용을 시도하기 전에 .m2/ 디렉터리에 있는 캐시된 리포지토리/ 하위 디렉터리를 제거합니다.

JBoss EAP Maven 리포지토리를 로컬 파일 시스템에 설치하려면 다음을 수행합니다.

  1. JBoss EAP Maven 리포지토리 ZIP 파일을 로컬 파일 시스템에 다운로드 했는지 확인합니다.
  2. 선택한 로컬 파일 시스템에서 파일의 압축을 풉니다.

    그러면 maven-repository/ 라는 하위 디렉토리에 Maven 리포지토리가 포함된 새 jboss-eap-7.4.0-maven-repository/ 디렉터리가 생성됩니다.

중요

이전 로컬 리포지토리를 사용하려면 Maven settings.xml 구성 파일에서 별도로 구성해야 합니다. 각 로컬 리포지토리는 자체 <repository> 태그 내에 구성해야 합니다.

2.2.3.2. Apache httpd와 함께 사용할 JBoss EAP Maven 리포지토리 설치

Apache httpd와 함께 사용할 JBoss EAP Maven 리포지토리를 설치하는 것은 웹 서버에 액세스할 수 있는 개발자가 Maven 리포지토리에도 액세스할 수 있기 때문에 다중 사용자 및 팀 간 개발 환경에 적합한 옵션입니다.

JBoss EAP Maven 리포지토리를 설치하기 전에 먼저 Apache httpd를 구성해야 합니다. 자세한 내용은 Apache HTTP Server Project 설명서를 참조하십시오.

  1. JBoss EAP Maven 리포지토리 ZIP 파일이 로컬 파일 시스템에 다운로드되었는지 확인합니다.
  2. Apache 서버에서 웹에 액세스할 수 있는 디렉터리에서 파일의 압축을 풉니다.
  3. 생성된 디렉토리에서 읽기 액세스 및 디렉토리 검색을 허용하도록 Apache를 구성합니다.

    이 구성을 사용하면 다중 사용자 환경에서 Apache httpd의 Maven 리포지토리에 액세스할 수 있습니다.

2.3. Maven 리포지토리 사용

2.3.1. JBoss EAP Maven 리포지토리 구성

개요

프로젝트에서 JBoss EAP Maven 리포지토리를 사용하도록 Maven에 대한 두 가지 접근법이 있습니다.

Maven 설정을 사용하여 JBoss EAP Maven 리포지토리 구성

권장되는 접근 방식입니다. 공유 서버의 리포지토리 관리자 또는 리포지토리와 함께 사용되는 Maven 설정은 프로젝트의 제어 및 관리 용이성을 제공합니다. 설정은 다른 미러를 사용하여 프로젝트 파일을 변경하지 않고 특정 리포지토리의 모든 조회 요청을 저장소 관리자로 리디렉션하는 기능도 제공합니다. 미러에 대한 자세한 내용은 http://maven.apache.org/guides/mini/guide-mirror-settings.html 의 내용을 참조하십시오.

프로젝트 POM 파일에 리포지토리 구성이 포함되지 않는 한 이 구성 방법은 모든 Maven 프로젝트에 적용됩니다.

이 섹션에서는 Maven 설정을 구성하는 방법에 대해 설명합니다. Maven 설치 글로벌 설정 또는 사용자의 설치 설정을 구성할 수 있습니다.

Maven 설정 파일 구성

  1. 운영 체제에 대한 Maven settings.xml 파일을 찾습니다. 일반적으로 ${user.home}/.m2/ 디렉터리에 있습니다.

    • Linux 또는 Mac의 경우 ~/.m2/입니다.
    • Windows의 경우 \Documents 및 Settings\.m2\ 또는 \Users\.m2\입니다.
  2. settings.xml 파일을 찾지 못하는 경우 ${user.home}/ .m2/conf/ 디렉터리에서 settings. xml 파일을 ${user.home}/.m2/ 디렉터리에 복사합니다.
  3. 다음 XML을 settings.xml 파일의 <profiles> 요소에 복사합니다. JBoss EAP 리포지토리의 URL을 확인하고 JBOSS_EAP_REPOSITORY_URL 을 이 리포지토리로 교체합니다.

    <!-- Configure the JBoss Enterprise Maven repository -->
    <profile>
      <id>jboss-enterprise-maven-repository</id>
      <repositories>
        <repository>
          <id>jboss-enterprise-maven-repository</id>
          <url>JBOSS_EAP_REPOSITORY_URL</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>jboss-enterprise-maven-repository</id>
          <url>JBOSS_EAP_REPOSITORY_URL</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
        </pluginRepository>
      </pluginRepositories>
    </profile>
    Copy to Clipboard Toggle word wrap

    다음은 온라인 JBoss EAP Maven 리포지토리에 액세스하는 구성의 예입니다.

    <!-- Configure the JBoss Enterprise Maven repository -->
    <profile>
      <id>jboss-enterprise-maven-repository</id>
      <repositories>
        <repository>
          <id>jboss-enterprise-maven-repository</id>
          <url>https://maven.repository.redhat.com/ga/</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>jboss-enterprise-maven-repository</id>
          <url>https://maven.repository.redhat.com/ga/</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
        </pluginRepository>
      </pluginRepositories>
    </profile>
    Copy to Clipboard Toggle word wrap
  4. 다음 XML을 settings.xml 파일의 <activeProfiles> 요소에 복사합니다.

    <activeProfile>jboss-enterprise-maven-repository</activeProfile>
    Copy to Clipboard Toggle word wrap
  5. Red Hat CodeReady Studio가 실행되는 동안 settings.xml 파일을 수정하면 사용자 설정을 새로 고쳐야 합니다.

    1. 메뉴에서 기본 설정을 선택합니다.
    2. Preferences(기본 설정 ) 창에서 Maven 을 확장하고 User Settings (사용자 설정)를 선택합니다.
    3. Update Settings (설정 업데이트) 버튼을 클릭하여 Red Hat CodeReady Studio에서 Maven 사용자 설정을 새로 고칩니다.
중요

Maven 리포지토리에 오래된 아티팩트가 포함된 경우 프로젝트를 빌드하거나 배포할 때 다음 Maven 오류 메시지 중 하나가 발생할 수 있습니다.

  • 누락된 아티팩트 ARTIFACT_NAME
  • [오류] 프로젝트 PROJECT_NAME에서 목표를 실행하지 못했습니다. PROJECT_NAME 에 대한 종속성을 확인할 수 없습니다.

이 문제를 해결하려면 캐시된 버전의 로컬 리포지토리를 삭제하여 최신 Maven 아티팩트를 강제로 다운로드합니다. 캐시된 리포지토리는 ${user.home}/.m2/repository/에 있습니다.

프로젝트 POM을 사용하여 JBoss EAP Maven 리포지토리 구성
주의

구성된 프로젝트의 전역 및 사용자 Maven 설정을 재정의하므로 이 구성 방법은 피해야 합니다.

POM 프로젝트를 사용하여 리포지토리를 구성하기로 결정한 경우 신중하게 계획해야 합니다. Maven이 누락된 아티팩트에 대해 외부 리포지토리를 쿼리해야 하고 이로 인해 빌드 프로세스가 느려지기 때문에 절대 포함된 POM은 이러한 유형의 구성에서 문제가 됩니다. 또한 아티팩트가 들어오는 위치를 제어하지 못하도록 할 수도 있습니다.

참고

리포지토리의 URL은 리포지토리가 있는 위치(파일 시스템 또는 웹 서버의 위치)에 따라 달라집니다. 리포지토리 설치 방법에 대한 자세한 내용은 다음을 참조하십시오. JBoss EAP Maven 리포지토리 설치. 다음은 각 설치 옵션에 대한 예입니다.

파일 시스템
file:///path/to/repo/jboss-eap-maven-repository
Apache 웹 서버
http://intranet.acme.com/jboss-eap-maven-repository/
Nexus 리포지토리 관리자
https://intranet.acme.com/nexus/content/repositories/jboss-eap-maven-repository

프로젝트의 POM 파일 구성

  1. 텍스트 편집기에서 프로젝트의 pom.xml 파일을 엽니다.
  2. 다음 리포지토리 구성을 추가합니다. 파일에 이미 <repositories> 구성이 있는 경우 <repository> 요소를 추가합니다. <url> 을 실제 리포지토리 위치로 변경하십시오.

    <repositories>
       <repository>
          <id>jboss-eap-repository-group</id>
          <name>JBoss EAP Maven Repository</name>
          <url>JBOSS_EAP_REPOSITORY_URL</url>
          <layout>default</layout>
          <releases>
             <enabled>true</enabled>
             <updatePolicy>never</updatePolicy>
          </releases>
          <snapshots>
             <enabled>true</enabled>
             <updatePolicy>never</updatePolicy>
          </snapshots>
       </repository>
    </repositories>
    Copy to Clipboard Toggle word wrap
  3. 다음 플러그인 리포지토리 구성을 추가합니다. 파일에 이미 <pluginRepositories> 구성이 있는 경우 <pluginRepository> 요소를 추가합니다.

    <pluginRepositories>
       <pluginRepository>
          <id>jboss-eap-repository-group</id>
          <name>JBoss EAP Maven Repository</name>
          <url>JBOSS_EAP_REPOSITORY_URL</url>
          <releases>
             <enabled>true</enabled>
          </releases>
          <snapshots>
             <enabled>true</enabled>
          </snapshots>
       </pluginRepository>
    </pluginRepositories>
    Copy to Clipboard Toggle word wrap
JBoss EAP 리포지토리의 URL 확인

리포지토리 URL은 리포지토리가 있는 위치에 따라 다릅니다. 다음 리포지토리 위치를 사용하도록 Maven을 구성할 수 있습니다.

  • 온라인 JBoss EAP Maven 리포지토리를 사용하려면 다음 URL을 지정합니다. https://maven.repository.redhat.com/ga/
  • 로컬 파일 시스템에 설치된 JBoss EAP Maven 리포지토리를 사용하려면 리포지토리를 다운로드한 다음 URL에 대한 로컬 파일 경로를 사용해야 합니다. 예: file:///path/to/repo/jboss-eap-7.4.0-maven-repository/maven-repository/
  • Apache 웹 서버에 리포지토리를 설치하는 경우 리포지토리 URL은 다음과 유사합니다. http://intranet.acme.com/jboss-eap-7.4.0-maven-repository/maven-repository/
  • Nexus Repository Manager를 사용하여 JBoss EAP Maven 리포지토리를 설치하는 경우 URL은 다음과 같습니다. https://intranet.acme.com/nexus/content/repositories/jboss-eap-7.4.0-maven-repository/maven-repository/
참고

원격 리포지토리는 HTTP 서버의 리포지토리에 http:// 와 같은 일반 프로토콜을 사용하거나 파일 서버의 리포지토리에 file:// 와 같은 일반 프로토콜을 사용하여 액세스합니다.

2.3.2. Red Hat CodeReady Studio에서 사용할 Maven 구성

Red Hat JBoss Enterprise Application Platform에 애플리케이션을 빌드하고 배포하는 데 필요한 아티팩트 및 종속성은 공용 리포지토리에 호스팅됩니다. 애플리케이션을 빌드할 때 이 리포지토리를 사용하도록 Maven을 지시해야 합니다. 이 섹션에서는 Red Hat CodeReady Studio를 사용하여 애플리케이션을 빌드 및 배포하려는 경우 Maven을 구성하는 단계를 설명합니다.

Maven은 Red Hat CodeReady Studio와 함께 배포되므로 별도로 설치할 필요가 없습니다. 그러나 JBoss EAP에 배포하려면 Java EE Web Project 마법사에서 사용하도록 Maven을 구성해야 합니다. 아래 절차에서는 Red Hat CodeReady Studio 내에서 Maven 구성 파일을 편집하여 JBoss EAP와 함께 사용하도록 Maven을 구성하는 방법을 보여줍니다.

참고

Red Hat CodeReady Studio에서 Target 런타임7.4 또는 이후 런타임 버전으로 설정하면 프로젝트가 Jakarta EE 8 사양과 호환됩니다.

Red Hat CodeReady Studio에서 Maven 구성

  1. WindowPreferences 를 클릭하고 JBoss Tools 를 확장한 다음 JBoss Maven Integration 을 선택합니다.

    그림 2.1. 기본 설정 창의 JBoss Maven Integration Pane

  2. Configure Maven Repositories(Maven 리포지토리 구성)를 클릭합니다.
  3. Add Repository (리포지토리 추가)를 클릭하여 JBoss Enterprise Maven 리포지토리를 구성합니다. 다음과 같이 Add Maven Repository(Maven 리포지토리 추가) 대화 상자를 완료합니다.

    1. Profile ID,Repository ID, Repository Name (리포지토리 이름 ) 값을 jboss-ga-repository 로 설정합니다.
    2. 리포지토리 URL 값을 http://maven.repository.redhat.com/ga 로 설정합니다.
    3. Active by default (기본적으로 활성화) 확인란을 클릭하여 Maven 리포지토리를 활성화합니다.
    4. OK(확인)를 클릭합니다.

      그림 2.2. Maven 리포지토리 추가

  4. 리포지토리를 검토하고 Finish (완료)를 클릭합니다.
  5. "Are you have to update the file MAVEN_HOME/settings.xml?"라는 메시지가 표시됩니다. Yes (예)를 클릭하여 설정을 업데이트합니다. OK(확인 )를 클릭하여 대화 상자를 닫습니다.

이제 JBoss EAP Maven 리포지토리가 Red Hat CodeReady Studio와 함께 사용하도록 구성됩니다.

2.3.3. 프로젝트 종속성 관리

이 섹션에서는 Red Hat JBoss Enterprise Application Platform용 BSM(Bill of Materials) POM의 사용법에 대해 설명합니다.

BOM은 지정된 모듈에 대한 모든 런타임 종속성 버전을 지정하는 Maven pom.xml (POM) 파일입니다. 버전 종속성은 파일의 종속성 관리 섹션에 나열됩니다.

프로젝트는 프로젝트 pom.xml 파일의 종속성 관리 섹션에 groupId:artifactId:version: v(groupId:artifactId:version)를 추가하고 <scope>import</scope> 및 <type&gt;pom</type> 요소 값을 지정하여 BOM을 사용합니다.

참고

대부분의 경우 프로젝트 POM 파일의 종속 항목은 제공된 범위를 사용합니다. 이러한 클래스는 런타임 시 애플리케이션 서버에서 제공하며 사용자 애플리케이션으로 패키징할 필요가 없기 때문입니다.

지원되는 Maven Artifacts

제품 빌드 프로세스의 일환으로 JBoss EAP의 모든 런타임 구성 요소는 제어된 환경의 소스에서 빌드됩니다. 이렇게 하면 바이너리 아티팩트에 악성 코드가 포함되어 있지 않으며 제품 수명 동안 지원할 수 있습니다. 이러한 아티팩트는 -redhat 버전 한정자(예: 1.0.0-redhat -1) 로 쉽게 식별할 수 있습니다.

지원되는 아티팩트를 빌드 구성 pom.xml 파일에 추가하면 빌드에서 로컬 빌드 및 테스트에 올바른 바이너리 아티팩트를 사용하고 있는지 확인합니다. -redhat 버전이 있는 아티팩트는 지원되는 공용 API의 일부인 것은 아니며 향후 개정판에서는 변경될 수 있습니다. 지원되는 공개 API에 대한 자세한 내용은 릴리스에 포함된 Javadoc 설명서 를 참조하십시오.

예를 들어 지원되는 Hibernate 버전을 사용하려면 다음과 유사한 버전을 빌드 구성에 추가합니다.

<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-core</artifactId>
  <version>5.3.1.Final-redhat-1</version>
  <scope>provided</scope>
</dependency>
Copy to Clipboard Toggle word wrap

위의 예에는 <version/> 필드의 값이 포함되어 있습니다. 그러나 Maven 종속성 관리를 사용하여 종속성 버전을 구성하는 것이 좋습니다.

종속성 관리

Maven에는 빌드 전체에서 직접 및 전이적 종속성 버전을 관리하는 메커니즘이 포함되어 있습니다. 종속성 관리 사용에 대한 일반적인 정보는 Apache Maven 프로젝트를 참조하십시오. 종속성 메커니즘 소개.

하나 이상의 지원 Red Hat 종속 항목을 빌드에 직접 사용하면 빌드의 모든 이전 종속성이 완전히 지원되는 Red Hat 아티팩트를 보장하지 않습니다. Maven 빌드에서는 Maven 중앙 리포지토리 및 기타 Maven 리포지토리의 아티팩트 소스를 혼합하여 사용하는 것이 일반적입니다.

JBoss EAP Maven 리포지토리에 종속성 관리 BOM이 포함되어 있으며, 지원되는 모든 JBoss EAP 바이너리 아티팩트를 지정합니다. 이 BOM은 빌드에서 Maven이 빌드의 모든 직접 및 전이적 종속성에 대해 지원되는 JBoss EAP 종속성에 우선 순위를 정하도록 할 수 있습니다. 즉, 이전 종속성은 해당하는 경우 올바른 지원 종속성 버전으로 관리됩니다. 이 BOM의 버전은 JBoss EAP 릴리스 버전과 일치합니다.

<dependencyManagement>
  <dependencies>
    ...
    <dependency>
      <groupId>org.jboss.bom</groupId>
      <artifactId>eap-runtime-artifacts</artifactId>
      <version>7.4.0.GA</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
    ...
  </dependencies>
</dependencyManagement>
Copy to Clipboard Toggle word wrap
참고

JBoss EAP 7에서는 이 BOM의 이름이 eap6-supported-artifacts에서 eap- runtime-artifacts 로 변경되었습니다. 이 변경의 목적은 이 POM의 아티팩트가 JBoss EAP 런타임의 일부이지만 지원되는 공용 API의 일부인 것을 더 명확히 하기 위한 것입니다. 일부 JAR에는 내부 API 및 기능이 포함되어 있으며, 릴리스마다 변경될 수 있습니다.

JBoss EAP Jakarta EE 사양 BOM

jboss-jakartaee-8.0 BOM에는 JBoss EAP에서 사용하는 Jakarta EE 사양 API JAR이 포함되어 있습니다.

프로젝트에서 이 BOM을 사용하려면 먼저 POM 파일의 dependencyManagement 섹션에 jboss-jakartaee-8.0 BOM에 대한 종속성을 추가하고 groupIdorg.jboss.spec 을 지정한 다음 애플리케이션에 필요한 특정 API에 대한 종속성을 추가합니다. API가 jboss-jakartaee-8.0 BOM에 포함되어 있기 때문에 이러한 종속성에는 버전이 필요하지 않으며 제공된 범위를 사용합니다.

다음 예제에서는 jboss-jakartaee-8.0 BOM의 1.0.0.Alpha1 버전을 사용하여 서블릿 및 Jakarta Server Pages API에 대한 종속성을 추가합니다.

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.jboss.spec</groupId>
      <artifactId>jboss-jakartaee-8.0</artifactId>
      <version>1.0.0.Alpha1</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
    ...
  </dependencies>
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>org.jboss.spec.javax.servlet</groupId>
    <artifactId>jboss-servlet-api_4.0_spec</artifactId>
    <scope>provided</scope>
  </dependency>
  <dependency>
    <groupId>org.jboss.spec.javax.servlet.jsp</groupId>
    <artifactId>jboss-jsp-api_2.3_spec</artifactId>
    <scope>provided</scope>
  </dependency>
  ...
</dependencies>
Copy to Clipboard Toggle word wrap
참고

JBoss EAP는 대부분의 제품 구성 요소의 API에 BOM을 패키징하고 제공합니다. 이러한 BOM 중 상당수는 org.jboss.bom 이라는 groupId 가 있는 더 큰 jboss-eap-jakartaee8 BOM로 편리하게 패키징됩니다. groupIdorg.jboss.specjboss-jakartaee-8.0 BOM이 이 대형 BOM에 포함됩니다. 즉, 이 BOM에 패키지된 추가 JBoss EAP 종속성을 사용하는 경우 jboss-jakartaee -8.0 및 기타 BOM 종속성을 별도로 추가하지 않고 프로젝트의 POM 파일에 하나의 jboss-eap-jakartaee 8 BOM만 추가하면 됩니다.

애플리케이션 개발에 사용 가능한 JBoss EAP BOM

다음 표에는 애플리케이션 개발에 사용할 수 있는 Maven BOM이 나열되어 있습니다.

Expand
표 2.1. JBoss BOMs
BOM Artifact ID사용 사례

eap-runtime-artifacts

지원되는 JBoss EAP 런타임 아티팩트.

jboss-eap-jakartaee8

지원되는 JBoss EAP Jakarta EE 8 API 및 추가 JBoss EAP API JAR.

jboss-eap-jakartaee8-with-tools

jboss-eap-jakartaee8 및 Arquillian과 같은 개발 툴.

참고

JBoss EAP 6의 이러한 BOM은 대부분의 사용 사례에서 더 간단하게 사용할 수 있도록 BOM이 더 적은 수로 통합되었습니다. 이제 Hibernate, 로깅, 트랜잭션, 메시징 및 기타 공용 API JAR이 각 사례에 별도의 BOM이 아닌 jboss-eap-jakartaee8 BOM에 포함됩니다.

다음 예제에서는 jboss-eap-jakartaee8 BOM의 7.4.0.GA 버전을 사용합니다.

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.jboss.bom</groupId>
      <artifactId>jboss-eap-jakartaee8</artifactId>
      <version>7.4.0.GA</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
    ...
  </dependencies>
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-core</artifactId>
    <scope>provided</scope>
  </dependency>
  ...
</dependencies>
Copy to Clipboard Toggle word wrap
JBoss EAP 클라이언트 BOM

클라이언트 BOM은 종속성 관리 섹션을 생성하거나 종속성을 정의하지 않습니다. 대신, 다른 BOM의 집계이며 원격 클라이언트 사용 사례에 필요한 종속성 집합을 패키징하는 데 사용됩니다.

The wildfly-ejb-client-bom,wildfly-jms-client-bom, and wildfly-jaxws-client-bomjboss-eap-jakartaee8 BOM에서 관리하므로 프로젝트 종속 항목에서 버전을 관리할 필요가 없습니다.

다음은 프로젝트에 wildfly-ejb-client-bom,wildfly- jms-client-bom 및 wildfly- jaxws-client-bom 종속성을 추가하는 방법의 예입니다.

<dependencyManagement>
  <dependencies>
    <!-- JBoss stack of the Jakarta EE APIs and related components.  -->
    <dependency>
      <groupId>org.jboss.bom</groupId>
      <artifactId>jboss-eap-jakartaee8</artifactId>
      <version>7.4.0.GA</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
  ...
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>org.jboss.eap</groupId>
    <artifactId>wildfly-ejb-client-bom</artifactId>
    <type>pom</type>
  </dependency>
  <dependency>
    <groupId>org.jboss.eap</groupId>
    <artifactId>wildfly-jms-client-bom</artifactId>
    <type>pom</type>
  </dependency>
  <dependency>
    <groupId>org.jboss.eap</groupId>
    <artifactId>wildfly-jaxws-client-bom</artifactId>
    <type>pom</type>
  </dependency>
  ...
</dependencies>
Copy to Clipboard Toggle word wrap

Maven 종속성 및 BOM POM 파일에 대한 자세한 내용은 Apache Maven Project - Introduction to Dependency Mechanism을 참조하십시오.

3장. 클래스 로드 및 모듈

3.1. 소개

3.1.1. 클래스 로드 및 모듈 개요

JBoss EAP는 모듈식 클래스 로드 시스템을 사용하여 배포된 애플리케이션의 클래스 경로를 제어합니다. 이 시스템은 기존의 계층형 클래스 로더 시스템보다 더 높은 유연성과 제어력을 제공합니다. 개발자는 애플리케이션에 사용할 수 있는 클래스를 세부적으로 제어할 수 있으며, 자체 애플리케이션에 대해 애플리케이션 서버에서 제공하는 클래스를 무시하도록 배포를 구성할 수 있습니다.

모듈식 클래스 로더는 모든 Java 클래스를 모듈이라는 논리 그룹으로 분리합니다. 각 모듈은 해당 모듈의 클래스를 자체 클래스 경로에 추가하기 위해 다른 모듈에 대한 종속성을 정의할 수 있습니다. 배포된 각 JAR 및 WAR 파일은 모듈로 처리되므로 개발자는 모듈 구성을 애플리케이션에 추가하여 애플리케이션 클래스 경로의 콘텐츠를 제어할 수 있습니다.

3.1.2. 배포에서 클래스 로드

클래스 로드의 목적을 위해 JBoss EAP는 모든 배포를 모듈로 처리합니다. 이러한 모듈을 동적 모듈이라고 합니다. 클래스 로드 동작은 배포 유형에 따라 다릅니다.

WAR 배포
WAR 배포는 단일 모듈로 간주됩니다. WEB-INF/lib 디렉토리의 클래스는 WEB-INF/classes 디렉토리의 클래스와 동일하게 처리됩니다. WAR에 패키지된 모든 클래스가 동일한 클래스 로더로 로드됩니다.
EAR 배포

EAR 배포는 두 개 이상의 모듈로 구성되며 다음 규칙에 의해 정의됩니다.

  1. EAR의 lib/ 디렉터리는 상위 모듈이라는 단일 모듈입니다.
  2. EAR 내의 각 WAR 배포는 단일 모듈입니다.
  3. EAR 내의 각 Jakarta Enterprise Beans JAR 배포는 단일 모듈입니다.

하위 배포 모듈(예: EAR 내에 WAR 및 JAR 배포)에는 상위 모듈에 대한 자동 종속성이 있습니다. 그러나 서로에 대한 자동 종속성은 없습니다. 이는 하위 배포 격리라고 하며 배포당 또는 전체 애플리케이션 서버에 대해 비활성화할 수 있습니다.

하위 배포 모듈 간의 명시적 종속성은 다른 모듈과 동일한 방법으로 추가할 수 있습니다.

3.1.3. 클래스 로드 우선 순위

JBoss EAP 모듈식 클래스 로더는 우선 순위 시스템을 사용하여 클래스 로드 충돌을 방지합니다.

배포하는 동안 각 배포 및 각 종속 항목에 대해 전체 패키지 및 클래스 목록이 생성됩니다. 목록은 클래스 로드 우선 순위 규칙에 따라 정렬됩니다. 런타임 시 클래스를 로드할 때 클래스 로더가 이 목록을 검색하고 첫 번째 일치 항목을 로드합니다. 이렇게 하면 배포 클래스 경로 내의 동일한 클래스 및 패키지가 서로 충돌하지 않도록 합니다.

클래스 로더는 가장 높은 순서에서 가장 낮은 순서로 클래스를 로드합니다.

  1. 암시적 종속성: 이러한 종속성은 자카르타 EE API와 같은 JBoss EAP에서 자동으로 추가합니다. 이러한 종속성은 JBoss EAP에서 제공하는 공통 기능과 API를 포함하므로 가장 높은 수준의 로더 우선 순위를 가집니다.

    암시적 종속성에 대한 자세한 내용은 암시적 모듈 종속성을 참조하십시오.

  2. 명시적 종속성: 이러한 종속성은 애플리케이션의 MANIFEST.MF 파일 또는 새로운 선택적 JBoss 배포 설명자 jboss-deployment-structure.xml 파일을 사용하여 애플리케이션 구성에 수동으로 추가됩니다.

    명시적 종속성을 추가하는 방법에 대해서는 Add an Explicit Module Dependency to a Deployment 를 참조하십시오.

  3. 로컬 리소스: 배포 자체에 패키지된 클래스 파일입니다(예: WAR 파일의 WEB-INF/classes 또는 WEB-INF/lib 디렉토리).
  4. 배포 간 종속성: EAR 배포의 다른 배포에 종속되어 있습니다. EAR의 lib 디렉토리에 클래스 또는 다른 Jakarta Enterprise Beans jar에 정의된 클래스가 포함될 수 있습니다.

3.1.4. jboss-deployment-structure.xml

jboss-deployment-structure.xml 파일은 JBoss EAP의 선택적 배포 설명자입니다. 이 배포 설명자는 배포에서 클래스 로드를 제어합니다.

이 배포 설명자의 XML 스키마는 EAP_HOME/docs/schema/jboss-deployment-structure-1_2.xsd의 제품 설치 디렉터리에 있습니다.

이 배포 설명자를 사용하여 수행할 수 있는 주요 작업은 다음과 같습니다.

  • 명시적 모듈 종속성 정의.
  • 특정 암시적 종속성이 로드되지 않도록 합니다.
  • 해당 배포의 리소스에서 추가 모듈 정의.
  • 해당 EAR 배포에서 하위 배포 격리 동작 변경.
  • EAR의 모듈에 리소스 루트 추가.

3.2. 배포에 명시적 모듈 종속성 추가

명시적 모듈 종속성을 애플리케이션에 추가하여 해당 모듈의 클래스를 배포 시 애플리케이션의 클래스 경로에 추가할 수 있습니다.

참고

JBoss EAP는 배포에 몇 가지 종속성을 자동으로 추가합니다. 자세한 내용은 암시적 모듈 종속성을 참조하십시오.

사전 요구 사항
  1. 모듈 종속성을 추가할 작업 중인 소프트웨어 프로젝트입니다.
  2. 종속성으로 추가되는 모듈의 이름을 알아야 합니다. JBoss EAP 에 포함된 정적 모듈 목록은 포함된 모듈 목록을 참조하십시오. 모듈이 다른 배포인 경우 JBoss EAP 구성 가이드에서 동적 모듈 명명 을 참조하여 모듈 이름을 확인합니다.

종속성은 다음 두 가지 방법을 사용하여 구성할 수 있습니다.

  • 배포의 MANIFEST.MF 파일에 항목 추가.
  • jboss-deployment-structure.xml 배포 설명자에 항목 추가.
MANIFEST.MF에 종속성 설정 추가

MANIFEST.MF 파일에 필요한 종속성 항목을 생성하도록 Maven 프로젝트를 구성할 수 있습니다.

  1. 프로젝트에 없는 경우 MANIFEST.MF 라는 파일을 생성합니다. 웹 애플리케이션(WAR)의 경우 이 파일을 META-INF/ 디렉터리에 추가합니다. Jakarta Enterprise Beans 아카이브(JAR)의 경우 META-INF/ 디렉터리에 추가합니다.
  2. 종속성 모듈 이름의 쉼표로 구분된 목록을 사용하여 MANIFEST.MF 파일에 dependencies 항목을 추가합니다.

    Dependencies: org.javassist, org.apache.velocity, org.antlr
    Copy to Clipboard Toggle word wrap
    • 종속성을 선택으로 만들려면 종속성 항목의 모듈 이름에 optional 를 추가합니다.

      Dependencies: org.javassist optional, org.apache.velocity
      Copy to Clipboard Toggle word wrap
    • 종속성은 종속성 항목에서 모듈 이름에 내보내기를 추가하여 내보낼 수 있습니다.

      Dependencies: org.javassist, org.apache.velocity export
      Copy to Clipboard Toggle word wrap
    • 주석 플래그는 모듈 종속성에 Jakarta Enterprise Beans 인터셉터를 선언하는 경우와 같이 주석 스캔 중에 처리해야 하는 주석이 포함된 경우 필요합니다. 이 기능이 없으면 모듈에 선언된 Jakarta Enterprise Beans 인터셉터는 배포에 사용할 수 없습니다. 이 작업도 필요할 때 주석 검사와 관련된 다른 상황이 있습니다.

      Dependencies: org.javassist, test.module annotations
      Copy to Clipboard Toggle word wrap
    • 종속성의 META-INF 에 있는 기본 항목은 액세스할 수 없습니다. 서비스 종속성을 사용하면 META-INF/서비스의 항목에 액세스하여 모듈의 서비스를 로드할 수 있습니다.

      Dependencies: org.javassist, org.hibernate services
      Copy to Clipboard Toggle word wrap
    • beans.xml 파일을 스캔하고 결과 빈을 애플리케이션에서 사용할 수 있도록 하려면 meta-inf 종속성을 사용할 수 있습니다.

      Dependencies: org.javassist, test.module meta-inf
      Copy to Clipboard Toggle word wrap
jboss-deployment-structure.xml에 종속성 구성 추가
  1. 애플리케이션에 없는 경우 jboss-deployment-structure.xml 이라는 새 파일을 생성하여 프로젝트에 추가합니다. 이 파일은 <jboss-deployment-structure>의 루트 요소가 있는 XML 파일입니다.

    <jboss-deployment-structure>
    
    </jboss-deployment-structure>
    Copy to Clipboard Toggle word wrap

    웹 애플리케이션(WAR)의 경우 이 파일을 WEB-INF/ 디렉토리에 추가합니다. Jakarta Enterprise Beans 아카이브(JAR)의 경우 META-INF/ 디렉터리에 추가합니다.

  2. 문서 루트 및 < dependencies> 요소 내에 <deployment > 요소를 만듭니다.
  3. <dependencies> 노드 내에 각 모듈 종속성에 대한 모듈 요소를 추가합니다. name 속성을 모듈의 이름으로 설정합니다.

    <module name="org.javassist" />
    Copy to Clipboard Toggle word wrap
    • true 를 사용하여 모듈 항목에 선택적 속성을 추가하여 종속성을 선택 사항으로 만들 수 있습니다. 이 속성의 기본값은 false 입니다.

      <module name="org.javassist" optional="true" />
      Copy to Clipboard Toggle word wrap
    • 종속 항목은 값이 true 인 모듈 항목에 export 특성을 추가하여 내보낼 수 있습니다. 이 속성의 기본값은 false 입니다.

      <module name="org.javassist" export="true" />
      Copy to Clipboard Toggle word wrap
    • 모듈 종속성에 주석 스캔 중에 처리해야 하는 주석이 포함된 경우 주석 플래그가 사용됩니다.

      <module name="test.module" annotations="true" />
      Copy to Clipboard Toggle word wrap
    • services 종속성은 이 종속성에서 발견되는 서비스가 사용되는지 여부와 방법을 지정합니다. 기본값은 none 입니다. 이 속성에 대한 가져오기 값을 지정하는 것은 dependency 모듈의 META-INF/services 경로를 포함하는 가져오기 필터 목록의 끝에 필터를 추가하는 것과 동일합니다. 이 속성에 대한 export 값을 설정하는 것은 내보내기 필터 목록에서 동일한 작업과 동일합니다.

      <module name="org.hibernate" services="import" />
      Copy to Clipboard Toggle word wrap
    • META-INF 종속성은 이 종속성의 META-INF 항목이 사용되는지 여부와 방법을 지정합니다. 기본값은 none 입니다. 이 속성에 대한 가져오기 값을 지정하는 것은 종속성 모듈의 META-INF/** 경로를 포함하는 가져오기 필터 목록의 끝에 필터를 추가하는 것과 동일합니다. 이 속성에 대한 export 값을 설정하는 것은 내보내기 필터 목록에서 동일한 작업과 동일합니다.

      <module name="test.module" meta-inf="import" />
      Copy to Clipboard Toggle word wrap

예: 두 개의 종속성이 있는 jboss-deployment-structure.xml 파일

<jboss-deployment-structure>
   <deployment>
      <dependencies>
         <module name="org.javassist" />
         <module name="org.apache.velocity" export="true" />
      </dependencies>
   </deployment>
</jboss-deployment-structure>
Copy to Clipboard Toggle word wrap

JBoss EAP는 지정된 모듈의 클래스를 배포할 때 애플리케이션의 클래스 경로에 추가합니다.

Jandex 인덱스 생성

annotations 플래그를 사용하려면 모듈에 Jandex 인덱스가 포함되어야 합니다. JBoss EAP 7.4에서는 자동으로 생성됩니다. 그러나 자동 검사는 CPU를 사용하고 배포 시간을 늘리는 긴 프로세스일 수 있으므로 성능상의 이유로 인덱스를 수동으로 추가하는 것이 좋습니다.

인덱스를 수동으로 추가하려면 새 "index JAR"을 생성하여 모듈에 추가합니다. Jandex JAR을 사용하여 인덱스를 빌드한 다음 새 JAR 파일에 삽입합니다. 현재 구현에서는 모듈 내의 JAR 파일에 인덱스가 추가되면 검사가 실행되지 않습니다.

Jandex 인덱스 생성::

  1. 인덱스를 생성합니다.

    java -jar modules/system/layers/base/org/jboss/jandex/main/jandex-jandex-2.0.0.Final-redhat-1.jar $JAR_FILE
    Copy to Clipboard Toggle word wrap
  2. 임시 작업 공간을 생성합니다.

    mkdir /tmp/META-INF
    Copy to Clipboard Toggle word wrap
  3. 인덱스 파일을 작업 디렉터리로 이동합니다.

    mv $JAR_FILE.ifx /tmp/META-INF/jandex.idx
    Copy to Clipboard Toggle word wrap
    1. 옵션 1: 새 JAR 파일에 인덱스 포함

      jar cf index.jar -C /tmp META-INF/jandex.idx
      Copy to Clipboard Toggle word wrap

      그런 다음 모듈 디렉터리에 JAR을 배치하고 module.xml 을 편집하여 리소스 루트에 추가합니다.

    2. 옵션 2: 기존 JAR에 인덱스 추가

      java -jar /modules/org/jboss/jandex/main/jandex-1.0.3.Final-redhat-1.jar -m $JAR_FILE
      Copy to Clipboard Toggle word wrap
  4. 주석 스캔에서 주석을 찾을 수 있도록 모듈 가져오기에 주석 색인을 활용하도록 지시합니다.

    1. 옵션 1: MANIFEST.MF 를 사용하여 모듈 종속성을 추가하는 경우 모듈 이름 뒤에 주석을 추가합니다. 예를 들면 다음과 같습니다.

      Dependencies: test.module, other.module
      Copy to Clipboard Toggle word wrap

      다음으로 변경

      Dependencies: test.module annotations, other.module
      Copy to Clipboard Toggle word wrap
    2. 옵션 2: jboss-deployment-structure.xml 을 사용하여 모듈 종속성 을 추가하는 경우 모듈 종속성에 annotations="true" 를 추가합니다.

      참고

      애플리케이션이 정적 모듈 내의 클래스에 정의된 주석이 있는 Jakarta EE 구성 요소를 사용하려는 경우 주석 색인이 필요합니다. JBoss EAP 7.4에서는 정적 모듈의 주석 색인이 자동으로 생성되므로 생성할 필요가 없습니다. 그러나 MANIFEST.MF 또는 jboss-deployment-structure. xml 파일에 종속성을 추가하여 주석을 사용하도록 모듈 가져오기에 지시해야 합니다.

3.3. Maven을 사용하여 MANIFEST.MF 항목 생성

Maven JAR, Jakarta Enterprise Beans 또는 WAR 패키징 플러그인을 사용하는 Maven 프로젝트는 종속성 항목이 있는 MANIFEST.MF 파일을 생성할 수 있습니다. 이는 종속성 목록을 자동으로 생성하지 않고 pom .xml에 지정된 세부 정보를 사용하여 MANIFEST. MF 파일만 생성합니다.

Maven을 사용하여 MANIFEST.MF 항목을 생성하기 전에 다음을 수행해야 합니다.

  • JAR, Jakarta Enterprise Beans 또는 WAR 플러그인(maven-jar-plugin, maven-ejb-plugin 또는 maven- war-plugin ) 중 하나를 사용하는 작동하는 Maven 프로젝트.
  • 프로젝트의 모듈 종속성의 이름을 알아야 합니다. JBoss EAP 에 포함된 정적 모듈 목록은 포함된 모듈을 참조하십시오. 모듈이 또 다른 배포인 경우 JBoss EAP 구성 가이드에서 동적 모듈 명명 을 참조하여 모듈 이름을 확인합니다.
모듈 종속성을 포함하는 MANIFEST.MF 파일 생성
  1. 프로젝트의 pom.xml 파일에서 패키징 플러그인 구성에 다음 구성을 추가합니다.

    <configuration>
       <archive>
          <manifestEntries>
             <Dependencies></Dependencies>
          </manifestEntries>
       </archive>
    </configuration>
    Copy to Clipboard Toggle word wrap
  2. 모듈 종속성 목록을 <Dependencies> 요소에 추가합니다. MANIFEST.MF 파일에 종속성을 추가할 때 사용되는 것과 동일한 형식을 사용합니다.

    <Dependencies>org.javassist, org.apache.velocity</Dependencies>
    Copy to Clipboard Toggle word wrap

    선택 사항내보내기 속성도 여기에 사용할 수 있습니다.

    <Dependencies>org.javassist optional, org.apache.velocity export</Dependencies>
    Copy to Clipboard Toggle word wrap
  3. Maven 어셈블리 목표를 사용하여 프로젝트를 빌드합니다.

    [Localhost ]$ mvn assembly:single
    Copy to Clipboard Toggle word wrap

    어셈블리 목표를 사용하여 프로젝트를 빌드하면 최종 아카이브에 지정된 모듈 종속성이 있는 MANIFEST.MF 파일이 포함되어 있습니다.

    예제: pom.xml에서 구성된 모듈 종속성

    참고

    예제는 WAR 플러그인을 나타내지만 JAR 및 Jakarta Enterprise Beans 플러그인(maven-jar-plugin 및 maven-ejb-plugin)에서도 작동합니다.

    <plugins>
       <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-war-plugin</artifactId>
          <configuration>
             <archive>
                <manifestEntries>
                   <Dependencies>org.javassist, org.apache.velocity</Dependencies>
                </manifestEntries>
             </archive>
          </configuration>
       </plugin>
    </plugins>
    Copy to Clipboard Toggle word wrap

3.4. 암시적으로 로드되는 모듈 방지

암시적 종속성이 로드되지 않도록 배포 가능한 애플리케이션을 구성할 수 있습니다. 이는 애플리케이션에 암시적 종속성으로 애플리케이션 서버에서 제공하는 라이브러리 또는 프레임워크와 다른 버전의 라이브러리 또는 프레임워크를 포함하는 경우 유용할 수 있습니다.

사전 요구 사항

jboss-deployment-structure.xml에 종속성 제외 구성 추가

  1. 애플리케이션에 없는 경우 jboss-deployment-structure.xml 이라는 새 파일을 생성하여 프로젝트에 추가합니다. <jboss-deployment-structure> 의 루트 요소가 있는 XML 파일입니다.

    <jboss-deployment-structure>
    
    </jboss-deployment-structure>
    Copy to Clipboard Toggle word wrap

    웹 애플리케이션(WAR)의 경우 이 파일을 WEB-INF/ 디렉토리에 추가합니다. Jakarta Enterprise Beans 아카이브(JAR)의 경우 META-INF/ 디렉터리에 추가합니다.

  2. 문서 루트에 <deployment> 요소와 그 안에 <exclusions> 요소를 만듭니다.

    <deployment>
       <exclusions>
    
       </exclusions>
    </deployment>
    Copy to Clipboard Toggle word wrap
  3. 제외 요소 내에 제외할 각 모듈에 대해 <module> 요소를 추가합니다. name 속성을 모듈의 이름으로 설정합니다.

    <module name="org.javassist" />
    Copy to Clipboard Toggle word wrap

    예제: 두 개의 모듈 제외

    <jboss-deployment-structure>
       <deployment>
          <exclusions>
             <module name="org.javassist" />
             <module name="org.dom4j" />
          </exclusions>
       </deployment>
    </jboss-deployment-structure>
    Copy to Clipboard Toggle word wrap

3.5. 배포에서 하위 시스템 제외

하위 시스템을 제외하면 하위 시스템을 제거하는 것과 동일한 효과가 있지만 단일 배포에만 적용됩니다. jboss-deployment-structure.xml 구성 파일을 편집하여 배포에서 하위 시스템을 제외할 수 있습니다.

하위 시스템 제외

  1. jboss-deployment-structure.xml 파일을 편집합니다.
  2. <deployment> 태그 내에 다음 XML을 추가합니다.

    <exclude-subsystems>
      <subsystem name="SUBSYSTEM_NAME" />
    </exclude-subsystems>
    Copy to Clipboard Toggle word wrap
  3. jboss-deployment-structure.xml 파일을 저장합니다.

하위 시스템의 배포 장치 프로세서는 더 이상 배포에 실행되지 않습니다.

예: jboss-deployment-structure.xml 파일

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
  <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
  <deployment>
    <exclude-subsystems>
      <subsystem name="jaxrs" />
    </exclude-subsystems>
    <exclusions>
      <module name="org.javassist" />
    </exclusions>
    <dependencies>
      <module name="deployment.javassist.proxy" />
      <module name="deployment.myjavassist" />
      <module name="myservicemodule" services="import"/>
    </dependencies>
    <resources>
      <resource-root path="my-library.jar" />
    </resources>
  </deployment>
  <sub-deployment name="myapp.war">
    <dependencies>
      <module name="deployment.myear.ear.myejbjar.jar" />
    </dependencies>
    <local-last value="true" />
  </sub-deployment>
  <module name="deployment.myjavassist" >
    <resources>
     <resource-root path="javassist.jar" >
       <filter>
         <exclude path="javassist/util/proxy" />
       </filter>
     </resource-root>
    </resources>
  </module>
  <module name="deployment.javassist.proxy" >
    <dependencies>
      <module name="org.javassist" >
        <imports>
          <include path="javassist/util/proxy" />
          <exclude path="/**" />
        </imports>
      </module>
    </dependencies>
  </module>
</jboss-deployment-structure>
Copy to Clipboard Toggle word wrap

3.6. 배포에서 프로그래밍 방식으로 Class Loader 사용

3.6.1. 배포에서 클래스 및 리소스 프로그래밍 방식으로 로드

애플리케이션 코드에서 클래스와 리소스를 프로그래밍 방식으로 찾거나 로드할 수 있습니다. 선택하는 방법은 여러 요인에 따라 다릅니다. 이 섹션에서는 사용 가능한 방법을 설명하고 사용 시기를 위한 지침을 제공합니다.

Class.forName() 메서드를 사용하여 클래스 로드

Class.forName() 메서드를 사용하여 클래스를 프로그래밍 방식으로 로드하고 초기화할 수 있습니다. 이 방법에는 두 개의 서명이 있습니다.

  • class.forName(String className):

    이 서명에는 로드에 필요한 클래스의 이름인 하나의 매개변수만 사용됩니다. 이 메서드 서명을 사용하면 현재 클래스의 클래스 로더에 의해 클래스가 로드되고 기본적으로 새로 로드된 클래스를 초기화합니다.

  • class .forName(String className, 부울 초기화, ClassLoader 로더):

    이 서명에는 클래스 이름, 클래스를 초기화할지 여부를 지정하는 부울 값, 클래스를 로드해야 하는 ClassLoader 의 세 가지 매개 변수가 필요합니다.

3가지 인수 서명은 클래스를 프로그래밍 방식으로 로드하는 데 권장되는 방법입니다. 이 서명을 사용하면 로드 시 대상 클래스를 초기화할지 여부를 제어할 수 있습니다. JVM이 호출 스택을 검사하여 사용할 클래스 로더를 결정할 필요가 없으므로 클래스 로더를 가져오고 제공하는 것이 더 효율적입니다. 코드가 포함된 클래스 이름이 CurrentClass라고 가정하면 CurrentClass .class.getClassLoader() 메서드를 사용하여 클래스의 클래스 로더를 얻을 수 있습니다.

다음 예제에서는 TargetClass 클래스를 로드하고 초기화할 클래스 로더를 제공합니다.

Class<?> targetClass = Class.forName("com.myorg.util.TargetClass", true, CurrentClass.class.getClassLoader());
Copy to Clipboard Toggle word wrap

지정된 이름으로 모든 리소스 찾기

리소스의 이름과 경로를 알고 있는 경우 직접 로드하는 가장 좋은 방법은 표준 JDK(Java Development Kit) Class 또는 Class Loader API를 사용하는 것입니다.

  • 단일 리소스 로드.

    배포에서 클래스 또는 다른 클래스와 동일한 디렉터리에 있는 단일 리소스를 로드하려면 Class.getResourceAsStream() 메서드를 사용할 수 있습니다.

    InputStream inputStream = CurrentClass.class.getResourceAsStream("targetResourceName");
    Copy to Clipboard Toggle word wrap
  • 단일 리소스의 모든 인스턴스를 로드합니다.

    배포의 클래스 로더에 표시되는 단일 리소스의 모든 인스턴스를 로드하려면 Class.getClassLoader().getResources(String resourceName) 메서드를 사용합니다. 여기서 resourceName 은 리소스의 정규화된 경로입니다. 이 메서드는 지정된 이름으로 클래스 로더에서 액세스할 수 있는 리소스에 대한 모든 URL 오브젝트의 Enumeration을 반환합니다. 그런 다음, openStream() 메서드를 사용하여 각 스트림을 열도록 URL 배열을 반복할 수 있습니다.

    다음 예제에서는 리소스의 모든 인스턴스를 로드하고 결과를 반복합니다.

    Enumeration<URL> urls = CurrentClass.class.getClassLoader().getResources("full/path/to/resource");
    while (urls.hasMoreElements()) {
        URL url = urls.nextElement();
        InputStream inputStream = null;
        try {
            inputStream = url.openStream();
            // Process the inputStream
            ...
        } catch(IOException ioException) {
            // Handle the error
        } finally {
            if (inputStream != null) {
                try {
                    inputStream.close();
                } catch (Exception e) {
                    // ignore
                }
            }
        }
    }
    Copy to Clipboard Toggle word wrap
    참고

    URL 인스턴스는 로컬 스토리지에서 로드되므로 openConnection() 또는 기타 관련 방법을 사용할 필요가 없습니다. 스트림은 코드의 복잡성을 최소화하고 훨씬 더 간단하게 사용할 수 있습니다.

  • 클래스 로더에서 클래스 파일을 로드합니다.

    클래스가 이미 로드된 경우 다음 구문을 사용하여 해당 클래스에 해당하는 클래스 파일을 로드할 수 있습니다.

    InputStream inputStream = CurrentClass.class.getResourceAsStream(TargetClass.class.getSimpleName() + ".class");
    Copy to Clipboard Toggle word wrap

    클래스가 아직 로드되지 않은 경우 클래스 로더를 사용하고 경로를 변환해야 합니다.

    String className = "com.myorg.util.TargetClass"
    InputStream inputStream = CurrentClass.class.getClassLoader().getResourceAsStream(className.replace('.', '/') + ".class");
    Copy to Clipboard Toggle word wrap

3.6.2. 배포에서 프로그래밍 방식으로 리소스 반복

JBoss 모듈 라이브러리는 모든 배포 리소스를 반복하기 위한 여러 API를 제공합니다. JBoss Modules API용 JavaDoc은 http://docs.jboss.org/jbossmodules/1.3.0.Final/api/ 에 있습니다. 이러한 API를 사용하려면 MANIFEST.MF 에 다음 종속성을 추가해야합니다 :

Dependencies: org.jboss.modules
Copy to Clipboard Toggle word wrap

이러한 API는 유연성을 향상하지만 직접 경로 조회보다 훨씬 느리게 실행됩니다.

이 섹션에서는 애플리케이션 코드의 리소스를 프로그래밍 방식으로 반복할 수 있는 몇 가지 방법에 대해 설명합니다.

  • 배포 내 및 모든 가져오기 내에서 리소스를 나열합니다.

    리소스를 정확한 경로로 검색할 수 없는 경우가 있습니다. 예를 들어 정확한 경로는 알 수 없거나 지정된 경로에서 둘 이상의 파일을 검사해야 할 수 있습니다. 이 경우 JBoss 모듈 라이브러리는 모든 배포 리소스를 반복하기 위한 여러 API를 제공합니다. 두 가지 방법 중 하나를 사용하여 배포의 리소스를 반복할 수 있습니다.

    • 단일 모듈에 있는 모든 리소스를 반복합니다.

      ModuleClassLoader.iterateResources() 메서드는 이 모듈 클래스 로더 내의 모든 리소스를 반복합니다. 이 메서드에는 검색할 시작 디렉토리 이름과 부울이 있습니다. 이 인수는 하위 디렉토리로 재귀해야 하는지 여부를 지정합니다.

      다음 예제에서는 ModuleClassLoader를 가져와 bin/ 디렉토리의 리소스에 대한 반복자를 가져와 하위 디렉터리로 재귀하는 방법을 보여줍니다.

      ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader();
      Iterator<Resource> mclResources = moduleClassLoader.iterateResources("bin",true);
      Copy to Clipboard Toggle word wrap

      결과 반복자를 사용하여 일치하는 각 리소스를 검사하고 이름 및 크기(사용 가능한 경우)를 쿼리하거나 읽을 수 있는 스트림을 열거나 리소스의 URL을 획득할 수 있습니다.

    • 단일 모듈과 가져온 리소스에 있는 모든 리소스를 반복합니다.

      Module.iterateResources() 메서드는 모듈로 가져온 리소스를 포함하여 이 모듈 클래스 로더 내의 모든 리소스를 반복합니다. 이 메서드는 이전 메서드보다 훨씬 큰 집합을 반환합니다. 이 메서드에는 결과를 특정 패턴으로 좁히는 필터인 인수가 필요합니다. 또는 전체 세트를 반환하도록 PathFilters.acceptAll()을 제공할 수 있습니다.

      다음 예제에서는 가져오기를 포함하여 이 모듈에서 전체 리소스 세트를 찾는 방법을 보여줍니다.

      ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader();
      Module module = moduleClassLoader.getModule();
      Iterator<Resource> moduleResources = module.iterateResources(PathFilters.acceptAll());
      Copy to Clipboard Toggle word wrap
  • 패턴과 일치하는 모든 리소스를 찾습니다.

    배포 내에서 또는 배포의 전체 가져오기 세트 내에서 특정 리소스만 찾아야 하는 경우 리소스 반복을 필터링해야 합니다. API를 필터링하는 JBoss 모듈은 이 작업을 수행할 수 있는 몇 가지 툴을 제공합니다.

    • 전체 종속성 세트를 검사합니다.

      전체 종속성 세트를 검사해야 하는 경우 Module.iterateResources() 메서드의 PathFilter 매개변수를 사용하여 일치하는 각 리소스의 이름을 확인할 수 있습니다.

    • 배포 종속성 검사.

      배포 내에서만 확인해야 하는 경우 ModuleClassLoader.iterateResources() 메서드를 사용합니다. 그러나 추가 방법을 사용하여 결과 반복자를 필터링해야 합니다. PathFilters.filtered() 메서드는 이 경우 리소스 반복자의 필터링된 보기를 제공할 수 있습니다. PathFilters 클래스에는 하위 경로 검색 또는 정확한 일치 또는 Ant 스타일 "glob" 패턴 일치를 포함하여 다양한 기능을 수행하는 필터를 생성하고 구성하는 많은 정적 방법이 포함되어 있습니다.

  • 리소스를 필터링하기 위한 추가 코드 예제.

    다음 예제에서는 다양한 기준에 따라 리소스를 필터링하는 방법을 보여줍니다.

    예제: 배치에서 이름이 지정된 모든 파일 찾기.properties

    ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader();
    Iterator<Resource> mclResources = PathFilters.filtered(PathFilters.match("**/messages.properties"), moduleClassLoader.iterateResources("", true));
    Copy to Clipboard Toggle word wrap

    예제: 배치 및 가져오기에서 이름이 지정된 모든 파일 찾기 .properties

    ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader();
    Module module = moduleClassLoader.getModule();
    Iterator<Resource> moduleResources = module.iterateResources(PathFilters.match("**/message.properties"));
    Copy to Clipboard Toggle word wrap

    예제: 배포의 my-resources 라는 모든 디렉토리 내에서 모든 파일 찾기

    ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader();
    Iterator<Resource> mclResources = PathFilters.filtered(PathFilters.match("**/my-resources/**"), moduleClassLoader.iterateResources("", true));
    Copy to Clipboard Toggle word wrap

    예제: 배치 및 가져오기에서 이름이 지정된 모든 파일 검색 또는 오류

    ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader();
    Module module = moduleClassLoader.getModule();
    Iterator<Resource> moduleResources = module.iterateResources(PathFilters.any(PathFilters.match("**/messages"), PathFilters.match("**/errors"));
    Copy to Clipboard Toggle word wrap

    예제: 배포의 특정 패키지에서 모든 파일 찾기

    ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader();
    Iterator<Resource> mclResources = moduleClassLoader.iterateResources("path/form/of/packagename", false);
    Copy to Clipboard Toggle word wrap

3.7. 클래스 로드 및 하위 배포

3.7.1. 엔터프라이즈 아카이브의 모듈 및 클래스 로드

EAR(Enterprise Archives)는 JAR 또는 WAR 배포와 같은 단일 모듈로 로드되지 않습니다. 여러 고유한 모듈로 로드됩니다.

다음 규칙은 EAR에 있는 모듈을 결정합니다.

  • EAR 아카이브의 루트에 있는 lib/ 디렉터리의 내용은 모듈입니다. 이것을 parent 모듈이라고 합니다.
  • 각 WAR 및 Jakarta Enterprise Beans JAR 하위 배포는 모듈입니다. 이러한 모듈에는 다른 모듈과 동일한 동작과 상위 모듈에 대한 암시적 종속성이 있습니다.
  • 하위 배포는 parent 모듈 및 기타 비WAR 하위 배포에 대한 암시적 종속성을 갖습니다.

JBoss EAP에 하위 배포 클래스 로더 격리가 기본적으로 비활성화되어 있기 때문에 비 WAR 하위 배포의 하위 종속성이 발생합니다. 상위 모듈에 대한 종속성은 하위 배포 클래스 로더 격리와 관계없이 유지됩니다.

중요

하위 배포가 WAR 하위 배포에 대한 암시적 종속성을 얻지 못합니다. 모든 하위 배포는 다른 모듈에서 수행되는 것처럼 다른 하위 배포에 대한 명시적 종속성을 사용하여 구성할 수 있습니다.

엄격한 호환성이 필요한 경우 하위 배포 클래스 로더 격리를 활성화할 수 있습니다. 단일 EAR 배포 또는 모든 EAR 배포에 대해 활성화할 수 있습니다. 자카르타 EE 사양에서는 각 하위 배포의 MANIFEST.MF 파일에서 종속성을 Class-Path 항목으로 명시적으로 선언하지 않는 한 이식 가능한 애플리케이션이 서로 액세스 가능한 하위 배포를 사용하지 않도록 권장합니다.

3.7.2. 하위 배포 클래스 로더 격리

EAR(Enterprise Archive)의 각 하위 배포는 자체 클래스 로더가 있는 동적 모듈입니다. 기본적으로 하위 배포는 다른 하위 배포의 리소스에 액세스할 수 있습니다.

하위 배포가 다른 하위 배포의 리소스에 액세스할 수 없는 경우 엄격한 하위 배포 격리를 활성화할 수 있습니다.

3.7.3. EAR에서 하위 배포 클래스 로더 격리 활성화

이 작업은 EAR의 특수 배포 설명자를 사용하여 EAR 배포에서 하위 배포 클래스 로더 격리를 활성화하는 방법을 보여줍니다. 애플리케이션 서버를 변경할 필요가 없으며 다른 배포에 영향을 주지 않습니다.

중요

하위 배포 클래스 로더 격리가 비활성화된 경우에도 WAR 배포를 종속성으로 추가할 수 없습니다.

  1. 배포 설명자 파일을 추가합니다.

    jboss-deployment-structure.xml 배포 설명자 파일을 EAR의 META-INF 디렉토리에 추가하고 다음 내용을 추가합니다.

    <jboss-deployment-structure>
    
    </jboss-deployment-structure>
    Copy to Clipboard Toggle word wrap
  2. <ear-subdeployments-isolated> 요소를 추가합니다.

    true 내용과 함께 아직 없는 경우 <ear-sub deployments-isolated> 요소를 jboss-deployment-structure.xml 파일에 추가합니다.

    <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
    Copy to Clipboard Toggle word wrap

이 EAR 배포에 대해 하위 배포 클래스 로더 격리가 활성화되었습니다. 즉, EAR의 하위 배포에는 WAR이 아닌 각 하위 배포에 대한 자동 종속성이 없습니다.

3.7.4. 엔터프라이즈 아카이브에서 하위 배포 간 세션 공유 구성

JBoss EAP는 EAR에 포함된 WAR 모듈 하위 배포 간 세션을 공유하도록 EAR(Enterprise Archives)를 구성할 수 있는 기능을 제공합니다. 이 기능은 기본적으로 비활성화되어 있으며 EAR의 META-INF/jboss-all.xml 파일에서 명시적으로 활성화해야 합니다.

중요

이 기능은 표준 서블릿 기능이 아니므로 이 기능을 활성화하면 애플리케이션이 이식되지 않을 수 있습니다.

EAR 내에서 WAR 간 세션 공유를 활성화하려면 EAR의 META -INF/jboss-all.xml에서 shared-session-config 요소를 선언해야 합니다.

예제: META-INF/jboss-all.xml

<jboss xmlns="urn:jboss:1.0">
  ...
  <shared-session-config xmlns="urn:jboss:shared-session-config:2.0">
  </shared-session-config>
  ...
</jboss>
Copy to Clipboard Toggle word wrap

shared-session-config 요소는 EAR 내의 모든 WAR에 대해 공유 세션 관리자를 구성하는 데 사용됩니다. shared-session-config 요소가 있으면 EAR 내의 모든 WAR가 동일한 세션 관리자를 공유합니다. 여기에서 변경한 내용은 EAR에 포함된 모든 WAR에 영향을 미칩니다.

3.7.4.1. 공유 세션 구성 옵션 참조

예제: META-INF/jboss-all.xml

<jboss xmlns="urn:jboss:1.0">
    <shared-session-config xmlns="urn:jboss:shared-session-config:2.0">
    	<distributable/>
        <max-active-sessions>10</max-active-sessions>
        <session-config>
            <session-timeout>0</session-timeout>
            <cookie-config>
                <name>JSESSIONID</name>
                <domain>domainName</domain>
                <path>/cookiePath</path>
                <comment>cookie comment</comment>
                <http-only>true</http-only>
                <secure>true</secure>
                <max-age>-1</max-age>
            </cookie-config>
            <tracking-mode>COOKIE</tracking-mode>
        </session-config>
        <replication-config>
            <cache-name>web</cache-name>
            <replication-granularity>SESSION</replication-granularity>
        </replication-config>
    </shared-session-config>
</jboss>
Copy to Clipboard Toggle word wrap

Expand
요소설명

shared-session-config

공유 세션 구성의 루트 요소입니다. META-INF/jboss-all.xml 에 있는 경우 EAR에 포함된 배포된 모든 WAR는 단일 세션 관리자를 공유합니다.

배포 가능

배포 가능한 세션 관리자를 사용해야 함을 지정합니다. 스키마 버전 2.0부터 배포 불가능한 세션 관리자가 기본적으로 사용됩니다. 버전 1.0의 경우 배포 가능한 세션 관리자는 계속 기본 세션 관리자입니다.

max-active-sessions

허용된 최대 세션 수.

session-config

EAR에 포함된 모든 배포된 WAR에 대한 세션 구성 매개 변수를 포함합니다.

session-timeout

EAR에 포함된 배포된 WAR에 생성된 모든 세션의 기본 세션 시간 제한 간격을 정의합니다. 지정된 시간 초과는 정수(분)로 표시되어야 합니다. 시간 제한이 0 이하이면 컨테이너에서 세션의 기본 동작이 시간 초과되지 않도록 합니다. 이 요소를 지정하지 않으면 컨테이너에서 기본 시간 초과 기간을 설정해야 합니다.

aws-config

EAR에 포함된 배포된 WAR에 의해 생성된 세션 추적 쿠키의 구성이 포함되어 있습니다.

name

EAR에 배포된 WAR로 생성된 모든 세션 추적 쿠키에 할당되는 이름입니다. 기본값은 JSESSIONID 입니다.

domain

EAR에 배포된 WAR에 의해 생성된 모든 세션 추적 쿠키에 할당되는 도메인 이름입니다.

경로

EAR에 배포된 WAR에 의해 생성된 모든 세션 추적 쿠키에 할당되는 경로입니다.

설명

EAR에 배포된 WAR에 의해 생성된 모든 세션 추적 쿠키에 할당되는 주석입니다.

http-only

EAR에 포함된 배포된 WAR에서 생성한 세션 추적 쿠키를 HttpOnly 로 표시할지 여부를 지정합니다.

보안

해당 세션을 시작한 요청이 HTTPS 대신 일반 HTTP를 사용하는 경우에도 EAR에 포함된 배포된 WAR에서 생성한 세션 추적 쿠키가 안전한 것으로 표시되는지 여부를 지정합니다.

최대 크기

EAR에 배포된 WAR에서 생성한 모든 세션 추적 쿠키에 할당되는 수명(초)입니다. 기본값은 -1 입니다.

tracking-mode

EAR에 포함된 배포된 WAR에서 생성한 세션의 추적 모드를 정의합니다.

replication-config

HTTP 세션 클러스터링 구성을 포함합니다.

cache-name

이 옵션은 클러스터링에만 사용됩니다. 세션 데이터를 저장할 Infinispan 컨테이너의 이름과 캐시를 지정합니다. 명시적으로 설정하지 않은 경우 기본값은 애플리케이션 서버에 의해 결정됩니다. 캐시 컨테이너 내에서 특정 캐시를 사용하려면 container.cache 양식(예: web. dist )을 사용합니다. name이 정규화되지 않은 경우 지정된 컨테이너의 기본 캐시가 사용됩니다.

replication-granularity

이 옵션은 클러스터링에만 사용됩니다. 이는 세션 복제 세분화 수준을 결정합니다. 가능한 값은 SESSIONATTRIBUTE 이며 기본값은 SESSION 입니다.

SESSION 세분화가 사용되는 경우 요청 범위 내에서 수정된 경우 모든 세션 특성이 복제됩니다. 이 정책은 여러 세션 특성에서 오브젝트 참조를 공유하는 경우 필요합니다. 그러나 세션 속성이 충분히 크거나 수정되지 않는지 여부와 관계없이 모든 속성을 복제해야 하므로 이는 세션 속성이 충분히 크거나 수정되지 않는 경우 비효율적일 수 있습니다.

ATTRIBUTE 세분화가 사용되는 경우 요청 범위 내에서 수정된 특성만 복제됩니다. 오브젝트 참조를 여러 세션 특성으로 공유하는 경우에는 이 정책이 적합하지 않습니다. 세션 속성이 충분히 크거나/또는 자주 수정되지 않는 경우 SESSION granularity보다 더 효율적일 수 있습니다.

3.8. 사용자 정의 모듈에 태그 라이브러리 설명자 (TLD) 배포

TLD(Common Tag Library Descriptors)를 사용하는 여러 애플리케이션이 있는 경우 애플리케이션이 하나의 중앙 위치에 있고 고유한 위치에 있도록 애플리케이션에서 TLD를 구분하는 것이 유용할 수 있습니다. 이를 통해 사용하는 개별 애플리케이션을 업데이트할 필요 없이 TLD에 쉽게 추가하고 업데이트할 수 있습니다.

이는 TLD JAR을 포함하는 사용자 지정 JBoss EAP 모듈을 생성하고 애플리케이션에서 해당 모듈에 대한 종속성을 선언하여 수행할 수 있습니다. 자세한 내용은 모듈 및 종속성을 참조하십시오.

참고

하나 이상의 JAR에 TLD가 포함되어 있고 TLD가 META-INF 에 설정되어 있는지 확인합니다.

사용자 지정 모듈에 TLD 배포
  1. 관리 CLI를 사용하여 JBoss EAP 인스턴스에 연결하고 다음 명령을 실행하여 TLD JAR을 포함하는 사용자 지정 모듈을 생성합니다.

    module add --name=MyTagLibs --resources=/path/to/TLDarchive.jar
    Copy to Clipboard Toggle word wrap
    중요

    모듈 관리 CLI 명령을 사용하여 모듈 추가 및 제거는 기술 프리뷰로만 제공됩니다. 이 명령은 관리형 도메인에서 사용하거나 관리 CLI에 원격으로 연결하는 데 적합하지 않습니다. 모듈은 프로덕션 환경에서 수동으로 추가 및 제거해야 합니다. 자세한 내용은 Create a Custom Module Manually and Remove a Custom Module Manually 섹션을 참조하십시오.

    기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

    기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.

    TLD가 종속성이 필요한 클래스로 패키징된 경우 --dependencies 옵션을 사용하여 사용자 정의 모듈을 생성할 때 해당 종속성을 지정할 수 있는지 확인합니다.

    모듈을 생성할 때 각 JAR 리소스를 시스템의 파일 시스템별 구분 기호로 분리하여 여러 JAR 리소스를 지정할 수 있습니다.

    • linux의 경우 - :. 예: --resources=<path-to-jar>:<path-to-another-jar>
    • Windows의 경우 - ;. 예: --resources=<path-to-jar>;<path-to-another-jar>

      참고
      --resources
      --module-xml 을 사용하지 않는 한 필수입니다. 파일 시스템별 경로(예: java.io.File.pathSeparatorChar )로 구분된 파일 시스템 경로(일반적으로 JAR 파일)를 나열합니다. 지정된 파일은 생성된 모듈의 디렉터리에 복사됩니다.
      --resource-delimiter
      리소스 인수의 선택적 사용자 정의 경로 구분자입니다. 이 인수가 있으면 명령 구문 분석기에서 파일 시스템별 경로 구분 기호 대신 값을 사용합니다. 이를 통해 크로스 플랫폼 스크립트에서 module 명령을 사용할 수 있습니다.
  2. 애플리케이션에서 배포에 명시적 모듈 종속성 추가에 설명된 방법 중 하나를 사용하여 새로운 MyTagLibs 사용자 지정 모듈에 대한 종속성을 선언합니다.
중요

종속성을 선언할 때 META-INF 도 가져와야 합니다. 예를 들어 MANIFEST.MF 의 경우 :

Dependencies: com.MyTagLibs meta-inf
Copy to Clipboard Toggle word wrap

또는 jboss-deployment-structure.xml 의 경우 meta-inf 특성을 사용합니다.

3.9. 배포로 모듈 표시

배포로 모듈 표시

list-modules 관리 작업을 사용하여 각 배포에 따라 모듈 목록을 표시할 수 있습니다.

:list-modules
Copy to Clipboard Toggle word wrap

예제: 독립 실행형 서버에 대한 배포로 모듈 표시

/deployment=ejb-in-ear.ear:list-modules
Copy to Clipboard Toggle word wrap

/deployment=ejb-in-ear.ear/subdeployment=ejb-in-ear-web.war:list-modules
Copy to Clipboard Toggle word wrap

예제: 관리형 도메인의 배포를 통해 모듈 표시

/host=master/server=server-one/deployment=ejb-in-ear.ear:list-modules
Copy to Clipboard Toggle word wrap

/host=master/server=server-one/deployment=ejb-in-ear.ear/subdeployment=ejb-in-ear-web.war:list-modules
Copy to Clipboard Toggle word wrap

이 작업은 목록이 간결한 보기에 표시됩니다.

예제: 표준 목록 출력

[standalone@localhost:9990 /] /deployment=sample-ear-1.0.ear:list-modules
  {
      "outcome" => "success",
      "result" => {
          "system-dependencies" => [
              {"name" => "com.fasterxml.jackson.datatype.jackson-datatype-jdk8"},
              {"name" => "com.fasterxml.jackson.datatype.jackson-datatype-jsr310"},
              {"name" => "ibm.jdk"},
              {"name" => "io.jaegertracing.jaeger"},
              {"name" => "io.opentracing.contrib.opentracing-tracerresolver"},
              ...
          ],
          "local-dependencies" => [
              {"name" => "deployment.ejb-in-ear.ear.ejb-in-ear-ejb.jar"},
               ...
          ],
          "user-dependencies" => [
              {"name" => "com.fasterxml.jackson.datatype.jackson-datatype-jdk8"},
              {"name" => "org.hibernate:4.1"},
               ...
          ]
      }
  }
Copy to Clipboard Toggle word wrap

verbose=[false*|true] 특성을 사용하면 보다 자세한 목록이 생성됩니다.

예제: 상세 목록 출력

[standalone@localhost:9990 /] /deployment=sample-ear-1.0.ear:list-modules(verbose=true)
  {
      "outcome" => "success",
      "result" => {
          "system-dependencies" => [
              {
                  "name" => "com.fasterxml.jackson.datatype.jackson-datatype-jdk8",
                  "optional" => true,
                  "export" => false,
                  "import-services" => true
              },
              {
                  "name" => "com.fasterxml.jackson.datatype.jackson-datatype-jsr310",
                  "optional" => true,
                  "export" => false,
                  "import-services" => true
              },
              ...
          ],
          "local-dependencies" => [
              {
                "name" => "deployment.ejb-in-ear.ear.ejb-in-ear-ejb.jar",
                "optional" => false,
                "export" => false,
                "import-services" => true
              },
              ...
          ],
          "user-dependencies" => [
              {
                  "name" => "com.fasterxml.jackson.datatype.jackson-datatype-jdk8",
                  "optional" => false,
                  "export" => false,
                  "import-services" => false
              },
              {
                  "name" => "org.hibernate:4.1",
                  "optional" => false,
                  "export" => false,
                  "import-services" => false
              },
              ...
Copy to Clipboard Toggle word wrap

다음 표에서는 출력에 제공된 정보의 범주를 설명합니다.

Expand
표 3.1. list-modules 작업에 대한 표 출력 범주

카테고리

설명

system-dependencies

서버에 의해 암시적으로 추가됨.

로컬 종속성

배포의 다른 부분에 의해 추가됨.

user-dependencies

MANIFEST.MF 또는 deployment-structure. xml 파일을 통해 사용자가 정의합니다.

3.10. 클래스 로드 참조

3.10.1. 암시적 모듈 종속성

다음 표에는 종속성 및 종속성을 트리거하는 조건으로 배포에 자동으로 추가되는 모듈이 나열되어 있습니다.

Expand
표 3.2. 암시적 모듈 종속성
종속성 추가를 위한 하위 시스템 응답항상 추가된 패키지 종속성조건부로 추가된 패키지 종속성종속성 추가를 트리거하는 조건

애플리케이션 클라이언트

  • org.omg.api
  • org.jboss.xnio
  

배치

  • javax.batch.api
  • org.jberet.jberet-core
  • org.wildfly.jberet
  

Jakarta Bean Validation

  • org.hibernate.validator
  • javax.validation.api
  

코어 서버

  • javax.api
  • sun.jdk
  • org.jboss.vfs
  • ibm.jdk
  

DriverDependenciesProcessor

 
  • javax.transaction.api
 

EE

  • org.jboss.invocation(또는 org.jboss.invocation.proxy.classloading 제외)
  • org.jboss.as.ee(또는 org.jboss.as.ee.component.serialization, org.jboss.as.ee.concurrent, org.jboss.as.ee.concurrent.handle)
  • org.wildfly.naming
  • javax.annotation.api
  • javax.enterprise.concurrent.api
  • javax.interceptor.api
  • javax.json.api
  • javax.resource.api
  • javax.rmi.api
  • javax.xml.bind.api
  • javax.api
  • org.glassfish.javax.el
  • org.glassfish.javax.enterprise.concurrent
  

Jakarta Enterprise Beans 3

  • javax.ejb.api
  • javax.xml.rpc.api
  • org.jboss.ejb-client
  • org.jboss.iiop-client
  • org.jboss.as.ejb3
  • org.wildfly.iiop-openjdk
 

IIOP

  • org.omg.api
  • javax.rmi.api
  • javax.orb.api
  

Jakarta RESTful Web Services(RESTEasy)

  • javax.xml.bind.api
  • javax.ws.rs.api
  • javax.json.api
  • org.jboss.resteasy.resteasy-atom-provider
  • org.jboss.resteasy.resteasy-crypto
  • org.jboss.resteasy.resteasy-validator-provider
  • org.jboss.resteasy.resteasy-jaxrs
  • org.jboss.resteasy.resteasy-jaxb-provider
  • org.jboss.resteasy.resteasy-jackson2-provider
  • org.jboss.resteasy.resteasy-jsapi
  • org.jboss.resteasy.resteasy-json-p-provider
  • org.jboss.resteasy.resteasy-multipart-provider
  • org.jboss.resteasy.resteasy-yaml-provider
  • org.codehaus.jackson.jackson-core-asl
  • org.jboss.resteasy.resteasy-cdi

배포에 Jakarta RESTful Web Services 주석이 있습니다.

자카르타 커넥터

  • javax.resource.api
  • javax.jms.api
  • javax.validation.api
  • org.jboss.ironjacamar.api
  • org.jboss.ironjacamar.impl
  • org.hibernate.validator

RR(리소스 어댑터) 아카이브 배포.

Jakarta Persistence (Hibernate)

  • javax.persistence.api
  • org.jboss.as.jpa
  • org.jboss.as.jpa.spi
  • org.javassist

배포 설명자에 @PersistenceUnit 또는 @PersistenceContext 주석 또는 <persistence-unit-ref> 또는 <persistence-context-ref> 요소가 있습니다.

JBoss EAP는 지속성 프로바이더 이름을 모듈 이름에 매핑합니다. persistence.xml 파일에서 특정 공급자의 이름을 지정하면 해당 모듈에 대한 종속성이 추가됩니다. 이 동작이 바람직하지 않은 경우 jboss-deployment-structure.xml 파일을 사용하여 제외할 수 있습니다.

Jakarta Server Faces

 
  • javax.faces.api
  • com.sun.jsf-impl
  • org.jboss.as.jsf
  • org.jboss.as.jsf-injection

EAR 애플리케이션에 추가됨.

web.xml 파일이 true 값을 갖는 org. jbossfaces.WAR_BUNDLES_JSF_IMPL 의 컨텍스트 매개 변수를 지정하지 않는 경우에만 WAR 애플리케이션에 추가됩니다.

JSR-77

  • javax.management.j2ee.api
  

로깅

  • org.jboss.logging
  • org.apache.commons.logging
  • org.apache.logging.log4j.api
  • org.apache.log4j
  • org.slf4j
  • org.jboss.logging.jul-to-slf4j-stub
  

메일

  • javax.mail.api
  • javax.activation.api
  

메시징

  • javax.jms.api
  • org.wildfly.extension.messaging-activemq
 

PicketLink Federation

 
  • org.picketlink
 

POJO

  • org.jboss.as.pojo
  

SAR

 
  • org.jboss.modules
  • org.jboss.as.system-jmx
  • org.jboss.common-beans

jboss-service.xml 이 있는 SAR 아카이브의 배포.

Seam2

 
  • org.jboss.vfs

.

보안

  • org.picketbox
  • org.jboss.as.security
  • javax.security.jacc.api
  • javax.security.auth.message.api
  

ServiceActivator

 
  • org.jboss.msc
 

트랜잭션

  • javax.transaction.api
  • org.jboss.xts
  • org.jboss.jts
  • org.jboss.narayana.compensations
 

Undertow

  • javax.servlet.jstl.api
  • javax.servlet.api
  • javax.servlet.jsp.api
  • javax.websocket.api
  • io.undertow.core
  • io.undertow.servlet
  • io.undertow.jsp
  • io.undertow.websocket
  • io.undertow.js
  • org.wildfly.clustering.web.api
 

웹 서비스

  • javax.jws.api
  • javax.xml.soap.api
  • javax.xml.ws.api
  • org.jboss.ws.api
  • org.jboss.ws.spi

애플리케이션 클라이언트 유형이 아닌 경우 조건부 종속성을 추가합니다.

weld (Jakarta 컨텍스트 및 종속성 주입)

  • javax.enterprise.api
  • javax.inject.api
  • javax.persistence.api
  • org.javassist
  • org.jboss.as.weld
  • org.jboss.weld.core
  • org.jboss.weld.probe
  • org.jboss.weld.api
  • org.jboss.weld.spi
  • org.hibernate.validator.cdi

배포에 bean.xml 파일이 있습니다.

3.10.2. 포함된 모듈

포함된 모듈의 전체 목록 및 지원 여부는 Red Hat 고객 포털에서 Red Hat JBoss Enterprise Application Platform 7에 포함된 모듈을 참조하십시오.

4장. 로깅

4.1. 로깅 정보

로깅은 애플리케이션 활동의 레코드 또는 로그를 제공하는 애플리케이션에서 일련의 메시지를 기록하는 방법입니다.

로그 메시지는 애플리케이션을 디버깅할 때 개발자와 프로덕션에서 애플리케이션을 유지 관리하는 시스템 관리자에게 중요한 정보를 제공합니다.

대부분의 최신 Java 로깅 프레임워크에는 정확한 시간 및 메시지 출처와 같은 세부 정보도 포함되어 있습니다.

4.1.1. 지원되는 애플리케이션 로깅 프레임워크

JBoss LogManager는 다음과 같은 로깅 프레임워크를 지원합니다.

JBoss LogManager는 다음 API를 지원합니다.

  • JBoss Logging
  • commons-logging
  • SLF4J
  • Log4j
  • Log4j2
  • java.util.logging

JBoss LogManager는 다음 SPI도 지원합니다.

  • java.util.logging 핸들러
  • Log4j Appender
참고

Log4j API 및 Log4 J Appender 를 사용하는 경우 전달되기 전에 오브젝트가 문자열로 변환됩니다.

4.2. JBoss Logging Framework로 로깅

4.2.1. JBoss Logging 정보

JBoss Logging은 JBoss EAP에 포함된 애플리케이션 로깅 프레임워크입니다. 애플리케이션에 로깅을 쉽게 추가할 수 있습니다. 프레임워크를 사용하여 정의된 형식으로 로그 메시지를 보내는 코드를 애플리케이션에 추가합니다. 애플리케이션이 애플리케이션 서버에 배포되면 해당 메시지를 서버에서 캡처하고 서버 구성에 따라 파일에 표시하거나 쓸 수 있습니다.

JBoss Logging은 다음과 같은 기능을 제공합니다.

  • 혁신적이고 사용하기 쉬운 입력 로거. 입력된 로거는 org.jboss.logging.annotations.MessageLogger 로 주석이 지정된 로거 인터페이스입니다. 예를 들어 국제화된 로거, 메시지 및 예외 생성을 참조하십시오.
  • 국제화 및 현지화에 대한 완전한 지원. 변환기는 속성 파일에서 메시지 번들을 사용하는 동안 개발자는 인터페이스 및 주석을 사용하여 작업합니다. 자세한 내용은 국제화 및 로컬화를 참조하십시오.
  • 개발을 위해 입력된 로거의 프로덕션 및 런타임 생성을 위한 입력된 로거를 생성하는 빌드 타임 툴입니다.

4.2.2. JBoss Logging을 사용하여 애플리케이션에 로깅 추가

다음 절차에서는 JBoss Logging을 사용하여 애플리케이션에 로깅을 추가하는 방법을 설명합니다.

중요

Maven을 사용하여 프로젝트를 빌드하는 경우 JBoss EAP Maven 리포지토리를 사용하도록 Maven을 구성해야 합니다. 자세한 내용은 Configure the JBoss EAP Maven Repository를 참조하십시오.

  1. JBoss Logging JAR 파일은 애플리케이션의 빌드 경로에 있어야 합니다.

    • Red Hat CodeReady Studio를 사용하여 빌드하는 경우 프로젝트 메뉴에서 Properties 를 선택한 다음 Targeted Runtimes 를 선택하고 JBoss EAP의 런타임이 선택되었는지 확인합니다.

      참고

      Red Hat CodeReady Studio에서 Target 런타임7.4 또는 이후 런타임 버전으로 설정하면 프로젝트가 Jakarta EE 8 사양과 호환됩니다.

    • Maven을 사용하여 프로젝트를 빌드하는 경우 JBoss Logging 프레임워크에 액세스하려면 프로젝트의 pom.xml 파일에 jboss-logging 종속성을 추가해야 합니다.

      <dependency>
      	<groupId>org.jboss.logging</groupId>
      	<artifactId>jboss-logging</artifactId>
      	<version>3.3.0.Final-redhat-1</version>
      	<scope>provided</scope>
      </dependency>
      Copy to Clipboard Toggle word wrap

      jboss-eap-jakartaee8 BOM은 jboss-logging 버전을 관리합니다. 자세한 내용은 프로젝트 종속성 관리를 참조하십시오. 애플리케이션에서 로깅 의 작업 예는 JBoss EAP와 함께 제공되는 로깅 빠른 시작을 참조하십시오.

    JBoss EAP가 배포된 애플리케이션에 JAR을 제공하므로 빌드된 애플리케이션에 JAR을 포함할 필요가 없습니다.

  2. 로깅을 추가할 각 클래스에 대해 다음을 수행합니다.

    1. 사용할 JBoss Logging 클래스 네임스페이스에 대한 import 문을 추가합니다. 최소한 다음 가져오기가 필요합니다.

      import org.jboss.logging.Logger;
      Copy to Clipboard Toggle word wrap
    2. org.jboss.logging.Logger 인스턴스를 생성하고 정적 메서드 Logger.getLogger(Class) 를 호출하여 초기화합니다. 각 클래스에 대해 단일 인스턴스 변수로 생성하는 것이 좋습니다.

      private static final Logger LOGGER = Logger.getLogger(HelloWorld.class);
      Copy to Clipboard Toggle word wrap
  3. 로그 메시지를 보내려는 코드에서 Logger 개체 메서드를 호출합니다.

    Logger 에는 다양한 유형의 메시지에 대해 다양한 매개 변수가 있는 다양한 메서드가 있습니다. 다음 메서드를 사용하여 해당 로그 수준 및 message 매개변수를 문자열로 사용하여 로그 메시지를 전송합니다.

    LOGGER.debug("This is a debugging message.");
    LOGGER.info("This is an informational message.");
    LOGGER.error("Configuration file not found.");
    LOGGER.trace("This is a trace message.");
    LOGGER.fatal("A fatal error occurred.");
    Copy to Clipboard Toggle word wrap

    JBoss Logging 방법의 전체 목록은 Logging API 설명서를 참조하십시오.

다음 예제에서는 속성 파일에서 애플리케이션에 대한 사용자 지정 구성을 로드합니다. 지정된 파일을 찾을 수 없는 경우 ERROR 수준 로그 메시지가 기록됩니다.

예제: JBoss Logging으로 애플리케이션 로깅

import org.jboss.logging.Logger;
public class LocalSystemConfig
{
   private static final Logger LOGGER = Logger.getLogger(LocalSystemConfig.class);

   public Properties openCustomProperties(String configname) throws CustomConfigFileNotFoundException
   {
      Properties props = new Properties();
      try
      {
         LOGGER.info("Loading custom configuration from "+configname);
         props.load(new FileInputStream(configname));
      }
      catch(IOException e) //catch exception in case properties file does not exist
      {
         LOGGER.error("Custom configuration file ("+configname+") not found. Using defaults.");
         throw new CustomConfigFileNotFoundException(configname);
      }

      return props;
   }
}
Copy to Clipboard Toggle word wrap

4.2.3. 애플리케이션에 Apache Log4j2 API 추가

Apache Log4j API 대신 Apache Log4j2 API를 사용하여 애플리케이션 로깅 메시지를 JBoss LogManager 구현으로 보낼 수 있습니다.

중요

JBoss EAP 7.4 릴리스는 Log4J2 API를 지원하지만 Apache Log4j2 Core 구현, org.apache.logging.log4j-core 또는 해당 구성 파일은 지원하지 않습니다.

절차

  1. org.apache.logging.log4j:log4j-api 를 프로젝트 pom.xml 파일에 대한 종속성으로 추가합니다.

    org.apache.logging.log4j:log4j-apipom.xml 파일에 추가하는 예입니다.

    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-api</artifactId>
        <version>${version.org.apache.logging.log4j}</version>
        <scope>provided</scope>
    </dependency>
    Copy to Clipboard Toggle word wrap

    참고

    log4j-api Maven 종속성은 Apache Log4j2 API를 나타냅니다. log4j Maven 종속성은 Apache Log4j API를 나타냅니다.

    애플리케이션 메시지를 기록하면 해당 메시지를 JBoss Log Manager 구현으로 보냅니다.

  2. 선택 사항: org.apache.logging.log4j.api 모듈을 제외하려면 jboss-deployment-structure.xml 파일에서 모듈을 제외하거나 add-logging-api-dependencies 특성을 false 로 설정해야 합니다.

4.2.4. Log4j2 LogManager 구현 생성

프로젝트의 pom.xml 파일에 Log4j2 API를 포함하여 애플리케이션에서 Log4j2 LogManager를 사용할 수 있습니다. 또한 프로젝트의 pom.xml 파일에 해당 Log4j2 LogManager 버전을 포함해야 합니다.

절차

  1. jboss-deployment-structure.xml 파일에서 org.apache.logging.log4j.api 모듈 종속성을 제외하여 Log4j 로깅 종속성을 비활성화합니다.
  2. log4j-api 종속성과 log4j2 종속성을 프로젝트 pom.xml 파일에 추가합니다.

    log4j-api 종속성 및 log4j2 종속성을 pom.xml 파일에 추가하는 예.

    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-api</artifactId>
        <version>${version.org.apache.logging.log4j}</version>
    </dependency>
    
    <dependency>
        <groupId>org.apache.logging.log4j2</groupId>
        <artifactId>log4j2-core</artifactId>
        <version>${version.org.apache.logging.log4j}</version>
    </dependency>
    Copy to Clipboard Toggle word wrap

    참고

    log4j-api Maven 종속성은 Apache Log4j2 API를 나타냅니다. log4j Maven 종속성은 Apache Log4j API를 나타냅니다.

    애플리케이션 메시지를 기록하면 해당 메시지를 Log4j2 LogManager 구현으로 보냅니다.

  3. 선택 사항: org.apache.logging.log4j.api 모듈을 제외하려면 jboss-deployment-structure.xml 파일에서 모듈을 제외하거나 add-logging-api-dependencies 특성을 false 로 설정해야 합니다. 그런 다음 log4j2-apilog4j2-core 를 프로젝트 pom.xml 파일에 추가해야 합니다.

    참고

    jboss-deployment-structure.xml 파일을 변경하는 경우 배포에 변경 사항을 적용합니다. add-logging-api-dependencies 속성을 변경하면 배포된 모든 애플리케이션에 변경 사항을 적용합니다.

4.3. 배포별 로깅

배포별 로깅을 사용하면 개발자가 사전에 애플리케이션의 로깅 구성을 구성할 수 있습니다. 애플리케이션이 배포되면 정의된 구성에 따라 로깅이 시작됩니다. 이 구성을 통해 생성된 로그 파일에는 애플리케이션의 동작만 포함됩니다.

참고

배포별 로깅 구성이 수행되지 않으면 모든 애플리케이션과 서버에 로깅 하위 시스템의 구성이 사용됩니다.

이 방법에는 시스템 전체 로깅 사용에 대한 장단점이 있습니다. JBoss EAP 인스턴스의 관리자가 서버 로깅보다 다른 로깅을 구성할 필요가 없다는 장점이 있습니다. 단점은 배포별 로깅 구성은 서버 시작 시에만 읽기 때문에 런타임 시 변경할 수 없다는 점입니다.

4.3.1. 애플리케이션에 배포별 로깅 추가

애플리케이션의 배포별 로깅을 구성하려면 배포에 logging.properties 구성 파일을 추가합니다. 이 구성 파일은 JBoss Log Manager가 기본 로그 관리자인 모든 로깅 facade와 함께 사용할 수 있으므로 권장됩니다.

구성 파일이 추가되는 디렉터리는 배포 방법에 따라 다릅니다.

  • EAR 배포를 위해 로깅 구성 파일을 META-INF/ 디렉터리에 복사합니다.
  • WAR 또는 JAR 배포의 경우 로깅 구성 파일을 WEB-INF/classes/ 디렉터리에 복사합니다.
참고

SLF 4J(Simple Logging Facade for Java) 또는 Apache log4j 를 사용하는 경우 logging.properties 구성 파일이 적합합니다. Apache log4j appenders를 사용하는 경우 구성 파일 log4j.properties 가 필요합니다. 구성 파일 jboss-logging.properties 는 레거시 배포에 대해서만 지원됩니다.

logging.properties 구성

logging.properties 파일은 로깅 하위 시스템이 시작될 때까지 서버가 부팅될 때 사용됩니다. 로깅 하위 시스템이 구성에 포함되지 않은 경우 서버는 이 파일의 구성을 전체 서버의 로깅 구성으로 사용합니다.

JBoss Log Manager 구성 옵션

로거 옵션

  • loggers=<category>[,<category>,…​] - 구성할 로거 카테고리의 쉼표로 구분된 목록을 지정합니다. 여기에 나열되지 않은 모든 카테고리는 다음 속성에서 구성되지 않습니다.
  • logger.<category>.level=<level> - 카테고리의 수준을 지정합니다. 수준은 유효한 수준 중 하나일 수 있습니다. 지정되지 않은 경우 가장 가까운 상위 수준은 상속됩니다.
  • logger.<category>.handlers=<handler>[,<handler>,…​] - 이 로거에 연결할 처리기 이름 쉼표로 구분된 목록을 지정합니다. 핸들러는 동일한 속성 파일에 구성해야 합니다.
  • logger.<category>.filter=<filter> - 카테고리에 대한 필터를 지정합니다.
  • logger.<category>.usePariteHandlers=(true|false) - 로그 메시지가 상위 핸들러에 캐스드되는지 여부를 지정합니다. 기본값은 true입니다.

핸들러 옵션

  • handler.<name>=<className> - 인스턴스화할 핸들러의 클래스 이름을 지정합니다. 이 옵션은 필수입니다.

    참고
    Expand
    표 4.1. 가능한 클래스 이름 :
    이름관련 클래스

    콘솔

    org.jboss.logmanager.handlers.ConsoleHandler

    파일

    org.jboss.logmanager.handlers.FileHandler

    주기

    org.jboss.logmanager.handlers.PeriodicRotatingFileHandler

    크기

    org.jboss.logmanager.handlers.SizeRotatingFileHandler

    정기적인 크기

    org.jboss.logmanager.handlers.PeriodicSizeRotatingFileHandler

    syslog

    org.jboss.logmanager.handlers.SyslogHandler

    async

    org.jboss.logmanager.handlers.AsyncHandler

    사용자 지정 핸들러에는 연결된 클래스 또는 모듈이 있을 수 있습니다. 사용자가 자체 로그 핸들러를 정의하는 로깅 하위 시스템에서 사용할 수 있습니다.

    자세한 내용은 JBoss EAP 구성 가이드의 로그 핸들러 를 참조하십시오.

  • handler.<name>.level=<level> - 이 핸들러의 수준을 제한합니다. 지정되지 않은 경우 ALL의 기본값이 유지됩니다.
  • handler.<name>.encoding=<encoding> - 이 핸들러 유형에서 지원하는 경우 문자 인코딩을 지정합니다. 지정하지 않으면 핸들러별 기본값이 사용됩니다.
  • handler.<name>.errorManager=<name> - 사용할 오류 관리자의 이름을 지정합니다. 오류 관리자는 동일한 속성 파일에서 구성해야 합니다. 지정되지 않은 경우 오류 관리자가 구성되지 않습니다.
  • handler.<name>.filter=<name> - 카테고리 필터를 지정합니다. 필터 정의에 대한 자세한 내용은 필터 표현식을 참조하십시오.
  • handler.<name>.formatter=<name> - 이 핸들러 유형에서 지원하는 경우 사용할 포맷터의 이름을 지정합니다. 포맷터는 동일한 속성 파일로 구성해야 합니다. 지정하지 않으면 대부분의 핸들러 유형에 대해 메시지가 기록되지 않습니다.
  • handler.<name>.properties=<property>[,<property>,…​] - 추가로 구성할 JavaBean 스타일 속성 목록을 지정합니다. 주어진 속성의 적절한 변환을 확인하기 위해 기본 유형 인트로스펙션이 수행됩니다.

    JBoss Log Manager의 모든 파일 핸들러의 경우 fileName 보다 먼저 첨부 를 설정해야 합니다. 속성이 handler.<name>.properties 에 표시되는 순서는 속성을 설정할 순서입니다.

  • handler.<name>.constructorProperties=<property>[,<property>,…​] - 구성 매개변수로 사용해야 하는 속성 목록을 지정합니다. 주어진 속성의 적절한 변환을 확인하기 위해 기본 유형 인트로스펙션이 수행됩니다.
  • handler.<name>.<property>=<value> - 명명된 속성의 값을 설정합니다.
  • handler.<name>.module=<name> - 핸들러가 상주하는 모듈의 이름을 지정합니다.

자세한 내용은 JBoss EAP 구성 가이드의 Log Handler Attributes 를 참조하십시오.

오류 관리자 옵션

  • errorManager.<name>=<className> - 인스턴스화할 오류 관리자의 클래스 이름을 지정합니다. 이 옵션은 필수입니다.
  • errorManager.<name>.properties=<property>[,<property>,…​] - 추가로 구성할 JavaBean 스타일 속성 목록을 지정합니다. 주어진 속성의 적절한 변환을 확인하기 위해 기본 유형 인트로스펙션이 수행됩니다.
  • errorManager.<name>.<property>=<value> - 명명된 속성의 값을 설정합니다.

포맷터 옵션

  • formatter.<name>=<className> - 인스턴스화할 포맷터의 클래스 이름을 지정합니다. 이 옵션은 필수입니다.
  • formatter.<name>.properties=<property>[,<property>,…​] - 추가로 구성할 JavaBean 스타일 속성 목록을 지정합니다. 주어진 속성의 적절한 변환을 확인하기 위해 기본 유형 인트로스펙션이 수행됩니다.
  • formatter.<name>.constructorProperties=<property>[,<property>,…​] - 구성 매개변수로 사용해야 하는 속성 목록을 지정합니다. 주어진 속성의 적절한 변환을 확인하기 위해 기본 유형 인트로스펙션이 수행됩니다.
  • formatter.<name>.<property>=<value> - 명명된 속성의 값을 설정합니다.

다음 예는 콘솔에 로깅할 logging.properties 파일의 최소 구성을 보여줍니다.

예제: 최소 logging.properties 구성

# Additional logger names to configure (root logger is always configured)
# loggers=

# Root logger level
logger.level=INFO

# Root logger handlers
logger.handlers=CONSOLE

# Console handler configuration
handler.CONSOLE=org.jboss.logmanager.handlers.ConsoleHandler
handler.CONSOLE.properties=autoFlush
handler.CONSOLE.autoFlush=true
handler.CONSOLE.formatter=PATTERN

# Formatter pattern configuration
formatter.PATTERN=org.jboss.logmanager.formatters.PatternFormatter
formatter.PATTERN.properties=pattern
formatter.PATTERN.pattern=%K{level}%d{HH:mm:ss,SSS} %-5p %C.%M(%L) [%c] %s%e%n
Copy to Clipboard Toggle word wrap

4.4. 로깅 프로필

로깅 프로필은 배포된 애플리케이션에 할당할 수 있는 별도의 로깅 구성 세트입니다. 일반 로깅 하위 시스템과 마찬가지로 로깅 프로필은 핸들러, 카테고리 및 루트 로거를 정의할 수 있지만 다른 프로필 또는 기본 로깅 하위 시스템에서 구성을 참조할 수는 없습니다. 로깅 프로필 설계는 구성이 용이하도록 로깅 하위 시스템을 모방합니다.

관리자는 로깅 프로필을 사용하여 다른 로깅 구성에 영향을 주지 않고 하나 이상의 애플리케이션에 해당하는 로깅 구성을 생성할 수 있습니다. 각 프로필은 서버 구성에 정의되므로 영향을 받는 애플리케이션을 재배포할 필요 없이 로깅 구성을 변경할 수 있습니다.

자세한 내용은 JBoss EAP 구성 가이드에서 로깅 프로필 구성을 참조하십시오.

각 로깅 프로파일에는 다음이 포함될 수 있습니다.

  • 고유한 이름입니다. 이 값은 필수입니다.
  • 임의 개수의 로그 핸들러.
  • 원하는 수의 로그 카테고리.
  • 최대 1개의 루트 로거.

애플리케이션은 Logging-Profile 특성을 사용하여 MANIFEST.MF 파일에서 사용할 로깅 프로필을 지정할 수 있습니다.

4.4.1. 애플리케이션에서 로깅 프로파일 지정

애플리케이션은 MANIFEST.MF 파일에서 사용할 로깅 프로필을 지정합니다.

참고

이 애플리케이션이 사용할 서버에 설정된 로깅 프로필의 이름을 알아야 합니다.

애플리케이션에 로깅 프로필 구성을 추가하려면 MANIFEST.MF 파일을 편집합니다.

  • 애플리케이션에 MANIFEST.MF 파일이 없는 경우 다음 내용이 포함된 파일을 생성하여 로깅 프로필 이름을 지정합니다.

    Manifest-Version: 1.0
    Logging-Profile: LOGGING_PROFILE_NAME
    Copy to Clipboard Toggle word wrap
  • 애플리케이션에 이미 MANIFEST.MF 파일이 있는 경우 다음 행을 추가하여 로깅 프로필 이름을 지정합니다.

    Logging-Profile: LOGGING_PROFILE_NAME
    Copy to Clipboard Toggle word wrap
참고

Maven 및 maven-war-plugin 을 사용하는 경우 MANIFEST.MF 파일을 src/main/resources/META-INF/ 에 배치하고 pom.xml 파일에 다음 구성을 추가합니다.

<plugin>
  <artifactId>maven-war-plugin</artifactId>
  <configuration>
    <archive>
      <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
    </archive>
  </configuration>
</plugin>
Copy to Clipboard Toggle word wrap

애플리케이션이 배포되면 지정된 로깅 프로필의 로그 메시지에 구성을 사용합니다.

로깅 프로필 및 애플리케이션을 구성하는 방법의 예는 JBoss EAP 구성 가이드의 로깅 프로필 구성을 참조하십시오.

4.5. 국제화 및 로컬라이제이션

4.5.1. 소개

4.5.1.1. 국제화 정보

국제화는 소프트웨어를 설계하여 엔지니어링의 변화 없이 다양한 언어와 지역에 적응할 수 있도록 하는 과정입니다.

4.5.1.2. 로컬라이제이션 정보

로컬라이제이션은 로케일별 구성 요소와 텍스트의 번역을 추가하여 특정 지역 또는 언어에 대해 국제화된 소프트웨어를 채택하는 프로세스입니다.

4.5.2. JBoss Logging Tools Internationalization 및 Localization

JBoss Logging Tools는 로그 메시지, 예외 메시지 및 일반 문자열의 국제화 및 현지화를 지원하는 Java API입니다. JBoss Logging Tools는 번역 메커니즘을 제공하는 것 외에도 각 로그 메시지에 대한 고유 식별자를 지원합니다.

국제화된 메시지 및 예외는 org.jboss.logging.annotations 주석을 사용하여 주석이 추가된 인터페이스 내부에 메서드 정의로 생성됩니다. 인터페이스를 구현할 필요가 없습니다. JBoss Logging Tools는 컴파일 시 이를 수행합니다. 정의되고 나면 이러한 방법을 사용하여 메시지를 기록하거나 코드에서 예외 개체를 얻을 수 있습니다.

JBoss Logging Tools로 생성된 국제화된 로깅 및 예외 인터페이스는 특정 언어 및 지역에 대한 번역이 포함된 각 번들에 대한 속성 파일을 생성하여 지역화할 수 있습니다. JBoss Logging Tools는 변환기에서 편집할 수 있는 각 번들에 대한 템플릿 속성 파일을 생성할 수 있습니다.

JBoss Logging Tools는 프로젝트에 있는 각 해당 번역 속성 파일에 대한 각 번들을 구현합니다. 번들에 정의된 메서드를 사용하고 JBoss Logging Tools를 사용하면 현재 지역 설정에 대해 올바른 구현이 호출됩니다.

메시지 ID와 프로젝트 코드는 각 로그 메시지 앞에 오는 고유한 식별자입니다. 이러한 고유 식별자를 설명서에서 사용하여 로그 메시지에 대한 정보를 쉽게 찾을 수 있습니다. 적절한 문서를 사용하면 메시지가 작성된 언어와 관계없이 로그 메시지의 의미를 식별자에서 확인할 수 있습니다.

JBoss Logging Tools에는 다음 기능을 지원합니다.

MessageLogger
org.jboss.logging.annotations 패키지의 이 인터페이스는 국제화된 로그 메시지를 정의하는 데 사용됩니다. 메시지 로거 인터페이스는 @MessageLogger로 주석이 추가됩니다.
MessageBundle
이 인터페이스를 사용하여 국제화된 메시지가 있는 일반 번역 가능한 메시지 및 예외 개체를 정의할 수 있습니다. 메시지 번들은 로그 메시지를 생성하는 데 사용되지 않습니다. 메시지 번들 인터페이스에 @MessageBundle 주석이 추가됩니다.
국제화된 로그 메시지

이러한 로그 메시지는 MessageLogger 에서 메서드를 정의하여 생성됩니다. 메서드에는 @LogMessage 및 @Message 주석을 추가해야 하며, @Message 의 value 특성을 사용하여 로그 메시지를 지정해야 합니다. 속성 파일에 번역을 제공하여 국제화된 로그 메시지가 지역화됩니다.

JBoss Logging Tools는 컴파일 시 각 번역에 필요한 로깅 클래스를 생성하고 런타임 시 현재 로케일을 위한 올바른 메서드를 호출합니다.

국제화된 예외
국제화된 예외는 MessageBundle에 정의된 메서드에서 반환된 예외 오브젝트입니다. 이러한 메시지 번들은 기본 예외 메시지를 정의하는 주석을 추가할 수 있습니다. 현재 로케일의 일치하는 속성 파일에 있는 경우 기본 메시지가 번역으로 바뀝니다. 국제화된 예외는 프로젝트 코드와 메시지 ID가 할당되어 있을 수도 있습니다.
국제화된 메시지
국제화된 메시지는 MessageBundle 에 정의된 메서드에서 반환된 문자열입니다. Java String 오브젝트를 반환하는 메시지 번들 메서드는 메시지라고 하는 해당 문자열의 기본 콘텐츠를 정의하도록 주석을 달 수 있습니다. 현재 로케일의 일치하는 속성 파일에 있는 경우 기본 메시지가 번역으로 바뀝니다.
번역 속성 파일
번역 속성 파일은 하나의 로케일, 국가 및 변형에 대한 하나의 인터페이스에서 메시지 변환을 포함하는 Java 속성 파일입니다. 번역 속성 파일은 JBoss Logging Tools에서 메시지를 반환하는 클래스를 생성하기 위해 사용됩니다.
JBoss Logging Tools 프로젝트 코드

프로젝트 코드는 메시지 그룹을 식별하는 문자열입니다. 메시지 ID 앞에 각 로그 메시지 시작 부분에 표시됩니다. 프로젝트 코드는 @MessageLogger 주석의 projectCode 특성으로 정의됩니다.

참고

새 로그 메시지 프로젝트 코드 접두사의 전체 목록은 JBoss EAP 7.4에서 사용된 프로젝트 코드를 참조하십시오.

JBoss Logging Tools 메시지 ID
메시지 ID는 프로젝트 코드와 결합될 때 로그 메시지를 고유하게 식별하는 번호입니다. 메시지 ID는 각 로그 메시지 시작 부분에 표시되며 메시지의 프로젝트 코드에 추가됩니다. 메시지 ID는 @Message 주석의 ID 특성을 사용하여 정의됩니다.

JBoss EAP와 함께 제공되는 logging-tools 빠른 시작은 JBoss Logging Tools의 많은 기능을 보여주는 간단한 Maven 프로젝트입니다. 다음 코드 예제는 logging-tools 빠른 시작에서 가져옵니다.

4.5.3. 국제화된 로거, 메시지 및 예외 생성

4.5.3.1. 국제화된 로그 메시지 만들기

JBoss Logging Tools를 사용하여 MessageLogger 인터페이스를 생성하여 국제화된 로그 메시지를 생성할 수 있습니다.

참고

이 섹션에서는 모든 선택적 기능이나 로그 메시지의 로컬화를 다루지는 않습니다.

  1. 아직 완료하지 않은 경우 JBoss EAP Maven 리포지토리를 사용하도록 Maven 설정을 구성합니다.

    자세한 내용은 Configure the JBoss EAP Maven Repository using the Maven Settings 에서 참조하십시오.

  2. JBoss Logging Tools를 사용하도록 프로젝트의 pom.xml 파일을 구성합니다.

    자세한 내용은 JBoss Logging Tools Maven Configuration을 참조하십시오.

  3. 로그 메시지 정의를 포함하도록 프로젝트에 Java 인터페이스를 추가하여 메시지 로거 인터페이스를 만듭니다.

    정의할 로그 메시지를 설명하도록 인터페이스의 이름을 지정합니다. 로그 메시지 인터페이스에는 다음 요구 사항이 있습니다.

    • @org.jboss.logging.annotations.MessageLogger 에 주석을 달아야 합니다.
    • 선택적으로 org.jboss.logging.BasicLogger 를 확장할 수 있습니다.
    • 인터페이스는 인터페이스와 동일한 유형의 메시지 로거인 필드를 정의해야 합니다. 이를 @org.jboss.logging. Logger의 getMessageLogger () 메서드로 수행합니다.

      예제: 메시지 로거 생성

      package com.company.accounts.loggers;
      
      import org.jboss.logging.BasicLogger;
      import org.jboss.logging.Logger;
      import org.jboss.logging.annotations.MessageLogger;
      
      @MessageLogger(projectCode="")
      interface AccountsLogger extends BasicLogger {
         AccountsLogger LOGGER = Logger.getMessageLogger(
               AccountsLogger.class,
               AccountsLogger.class.getPackage().getName() );
      }
      Copy to Clipboard Toggle word wrap

  4. 각 로그 메시지의 인터페이스에 메서드 정의를 추가합니다.

    각 메서드가 나타내는 로그 메시지에 대해 설명적으로 이름을 지정합니다. 각 방법에는 다음 요구 사항이 있습니다.

    • 메서드는 void 을 반환해야 합니다.
    • @org.jboss.logging.annotation.LogMessage 주석을 사용하여 주석을 달아야 합니다.
    • @org.jboss.logging.annotations.Message 주석을 사용하여 주석을 달아야 합니다.
    • 기본 로그 수준은 INFO(정보) 입니다.
    • @org.jboss.logging.annotations.Message 의 value 속성에는 번역을 사용할 수 없는 경우 사용되는 기본 로그 메시지가 포함되어 있습니다.

      @LogMessage
      @Message(value = "Customer query failed, Database not available.")
      void customerQueryFailDBClosed();
      Copy to Clipboard Toggle word wrap
  5. 메시지가 로깅되어야 하는 코드의 인터페이스 메서드에 호출을 추가하여 메서드를 호출합니다.

    인터페이스 구현을 생성할 필요가 없으며, 프로젝트를 컴파일할 때 주석 프로세서가 이 작업을 수행합니다.

    AccountsLogger.LOGGER.customerQueryFailDBClosed();
    Copy to Clipboard Toggle word wrap

    사용자 지정 로거는 BasicLogger 에서 하위 분류되므로 BasicLogger 의 로깅 방법도 사용할 수 있습니다. 비 국제화 메시지를 기록하기 위해 다른 로거를 생성할 필요는 없습니다.

    AccountsLogger.LOGGER.error("Invalid query syntax.");
    Copy to Clipboard Toggle word wrap
  6. 이 프로젝트는 이제 지역화할 수 있는 하나 이상의 국제화된 로거를 지원합니다.
참고

JBoss EAP와 함께 제공되는 logging-tools 빠른 시작은 JBoss Logging Tools 사용 방법에 대한 작업 예제를 제공하는 간단한 Maven 프로젝트입니다.

4.5.3.2. 국제화된 메시지 생성 및 사용

다음 절차에서는 국제화된 메시지를 만들고 사용하는 방법을 설명합니다.

참고

이 섹션에서는 모든 선택적 기능이나 해당 메시지를 로컬화하는 프로세스에 대해서는 다루지 않습니다.

  1. 아직 완료하지 않은 경우 JBoss EAP Maven 리포지토리를 사용하도록 Maven 설정을 구성합니다. 자세한 내용은 Configure the JBoss EAP Maven Repository using the Maven Settings 에서 참조하십시오.
  2. JBoss Logging Tools를 사용하도록 프로젝트의 pom.xml 파일을 구성합니다. 자세한 내용은 JBoss Logging Tools Maven Configuration을 참조하십시오.
  3. 예외에 대한 인터페이스를 만듭니다. JBoss Logging Tools는 인터페이스에서 국제화된 메시지를 정의합니다. 포함된 메시지에 대해 각 인터페이스를 설명적으로 지정합니다. 인터페이스에는 다음 요구 사항이 있습니다.

    • 공용 으로 선언해야 합니다.
    • @org.jboss.logging.annotations.MessageBundle 으로 주석을 달아야 합니다.
    • 인터페이스는 인터페이스와 동일한 유형의 메시지 번들인 필드를 정의해야 합니다.

      예제: MessageBundle 인터페이스 만들기

      @MessageBundle(projectCode="")
      public interface GreetingMessageBundle {
         GreetingMessageBundle MESSAGES = Messages.getBundle(GreetingMessageBundle.class);
      }
      Copy to Clipboard Toggle word wrap

      참고

      Messages.getBundle(GreetingMessagesBundle.class) 호출은 Messages.getBundle(GreetingMessagesBundle.class, Locale.getDefault()) 을 호출하는 것과 같습니다.

      locale .getDefault() 는 Java 가상 머신의 이 인스턴스에 대한 기본 로케일의 현재 값을 가져옵니다. Java Virtual Machine은 호스트 환경에 따라 시작 중에 기본 로케일을 설정합니다. 로케일이 명시적으로 지정되지 않은 경우 로케일이 중요한 여러 메서드에서 사용됩니다. setDefault 방법을 사용하여 변경할 수 있습니다.

      자세한 내용은 JBoss EAP 구성 가이드에서 서버의 기본 로케일 설정을 참조하십시오.

  4. 각 메시지의 인터페이스에 메서드 정의를 추가합니다. 각 메서드가 나타내는 메시지에 대해 설명적으로 이름을 지정합니다. 각 방법에는 다음 요구 사항이 있습니다.

    • String 유형의 오브젝트를 반환해야 합니다.
    • @org.jboss.logging.annotations.Message 주석을 사용하여 주석을 달아야 합니다.
    • @org.jboss.logging.annotations.Message 의 value 특성은 기본 메시지로 설정해야 합니다. 이 메시지는 번역을 사용할 수 없는 경우 사용됩니다.

      @Message(value = "Hello world.")
      String helloworldString();
      Copy to Clipboard Toggle word wrap
  5. 메시지를 가져와야 하는 애플리케이션에서 인터페이스 메서드를 호출합니다.

    System.out.println(helloworldString());
    Copy to Clipboard Toggle word wrap

이 프로젝트는 이제 지역화할 수 있는 국제화된 메시지 문자열을 지원합니다.

참고

전체 작업 예는 JBoss EAP와 함께 제공되는 logging-tools 빠른 시작을 참조하십시오.

4.5.3.3. 국제화된 예외 만들기

JBoss Logging Tools를 사용하여 국제화된 예외를 생성하고 사용할 수 있습니다.

다음 지침에서는 Red Hat CodeReady Studio 또는 Maven을 사용하여 빌드된 기존 소프트웨어 프로젝트에 국제화된 예외를 추가하려고 한다고 가정합니다.

참고

이 섹션에서는 일부 선택적 기능이나 이러한 예외를 지역화하는 과정을 다루지는 않습니다.

  1. JBoss Logging Tools를 사용하도록 프로젝트의 pom.xml 파일을 구성합니다. 자세한 내용은 JBoss Logging Tools Maven Configuration을 참조하십시오.
  2. 예외에 대한 인터페이스를 만듭니다. JBoss Logging Tools는 인터페이스에서 국제화된 예외를 정의합니다. 정의하는 예외에 대해 각 인터페이스를 설명하여 이름을 지정합니다. 인터페이스에는 다음 요구 사항이 있습니다.

    • 공용 으로 선언해야 합니다.
    • @MessageBundle 으로 주석을 달아야 합니다.
    • 인터페이스는 인터페이스와 동일한 유형의 메시지 번들인 필드를 정의해야 합니다.

      예제: 예외Bundle 인터페이스 만들기

      @MessageBundle(projectCode="")
      public interface ExceptionBundle {
         ExceptionBundle EXCEPTIONS = Messages.getBundle(ExceptionBundle.class);
      }
      Copy to Clipboard Toggle word wrap

  3. 각 예외에 대해 인터페이스에 메서드 정의를 추가합니다. 각 메서드가 나타내는 예외에 대해 설명적으로 이름을 지정합니다. 각 방법에는 다음 요구 사항이 있습니다.

    • Exception 오브젝트 또는 하위 유형인 Exception 을 반환해야 합니다.
    • @org.jboss.logging.annotations.Message 주석을 사용하여 주석을 달아야 합니다.
    • @org.jboss.logging.annotations.Message 의 value 특성은 기본 예외 메시지로 설정해야 합니다. 이 메시지는 번역을 사용할 수 없는 경우 사용됩니다.
    • 반환되는 예외에 메시지 문자열 외에도 매개 변수가 필요한 생성자가 있는 경우 @Param 주석을 사용하여 메서드 정의에 해당 매개 변수를 제공해야 합니다. 매개변수는 예외 생성자에 있는 것과 동일한 유형 및 순서여야 합니다.

      @Message(value = "The config file could not be opened.")
      IOException configFileAccessError();
      
      @Message(id = 13230, value = "Date string '%s' was invalid.")
      ParseException dateWasInvalid(String dateString, @Param int errorOffset);
      Copy to Clipboard Toggle word wrap
  4. 예외 중 하나를 가져와야 하는 코드에서 인터페이스 메서드를 호출합니다. 메서드에서 예외를 발행하지 않고 예외 오브젝트를 반환하여 트리거할 수 있습니다.

    try {
       propsInFile=new File(configname);
       props.load(new FileInputStream(propsInFile));
    }
    catch(IOException ioex) {
      //in case props file does not exist
       throw ExceptionBundle.EXCEPTIONS.configFileAccessError();
    }
    Copy to Clipboard Toggle word wrap

이 프로젝트는 이제 지역화할 수 있는 국제화된 예외를 지원합니다.

참고

전체 작업 예는 JBoss EAP와 함께 제공되는 logging-tools 빠른 시작을 참조하십시오.

4.5.4. 국제화된 로거, 메시지 및 예외 로컬화

4.5.4.1. Maven으로 새 번역 속성 파일 생성

Maven을 사용하여 빌드된 프로젝트는 포함된 각 MessageLogger 및 Message Bundle 에 대한 빈 번역 속성 파일을 생성할 수 있습니다. 이러한 파일을 새로운 번역 속성 파일로 사용할 수 있습니다.

다음 절차에서는 Maven 프로젝트를 구성하여 새 번역 속성 파일을 생성하는 방법을 보여줍니다.

사전 요구 사항

  • 이미 작동 중인 Maven 프로젝트가 있어야 합니다.
  • 프로젝트는 JBoss Logging Tools용으로 이미 구성되어 있어야 합니다.
  • 프로젝트에는 국제화된 로그 메시지 또는 예외를 정의하는 하나 이상의 인터페이스가 포함되어야 합니다.

번역 속성 파일 생성

  1. Maven 컴파일러 플러그인 구성에 -AgenereatedTranslationFilePath 컴파일러 인수를 추가하여 Maven 구성을 추가하고 새 파일이 생성될 경로를 할당합니다.

    이 구성은 Maven 프로젝트의 target/generated-translation-files 디렉터리에 새 파일을 생성합니다.

    예제: 변환 파일 경로 정의

    <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-compiler-plugin</artifactId>
       <version>2.3.2</version>
       <configuration>
          <source>1.6</source>
          <target>1.6</target>
          <compilerArgument>
          -AgeneratedTranslationFilesPath=${project.basedir}/target/generated-translation-files
          </compilerArgument>
          <showDeprecation>true</showDeprecation>
       </configuration>
    </plugin>
    Copy to Clipboard Toggle word wrap

  2. Maven을 사용하여 프로젝트를 빌드합니다.

    $ mvn compile
    Copy to Clipboard Toggle word wrap

    @MessageBundle 또는 @Message Logger 로 주석이 추가된 각 인터페이스에 대해 하나의 속성 파일이 생성됩니다.

    • 새 파일은 각 인터페이스가 선언되는 Java 패키지에 해당하는 하위 디렉터리에 생성됩니다.
    • 각 새 파일은 파일을 생성하는 데 사용되는 인터페이스의 이름인 다음 패턴을 사용하여 이름이 지정됩니다.

      INTERFACE_NAME.i18n_locale_COUNTRY_VARIANT.properties
      Copy to Clipboard Toggle word wrap

이제 결과 파일을 새로운 번역의 기반으로 프로젝트에 복사할 수 있습니다.

참고

전체 작업 예는 JBoss EAP와 함께 제공되는 logging-tools 빠른 시작을 참조하십시오.

4.5.4.2. 국제화된 로거, 예외 또는 메시지 변환

속성 파일은 JBoss Logging Tools를 사용하여 인터페이스에 정의된 로깅 및 예외 메시지를 변환하는 데 사용할 수 있습니다.

다음 절차에서는 번역 속성 파일을 생성 및 사용하는 방법을 보여주며 국제화된 예외 또는 로그 메시지에 대해 정의된 하나 이상의 인터페이스가 있는 프로젝트가 이미 있다고 가정합니다.

사전 요구 사항

  • 이미 작동 중인 Maven 프로젝트가 있어야 합니다.
  • 프로젝트는 JBoss Logging Tools용으로 이미 구성되어 있어야 합니다.
  • 프로젝트에는 국제화된 로그 메시지 또는 예외를 정의하는 하나 이상의 인터페이스가 포함되어야 합니다.
  • 템플릿 번역 속성 파일을 생성하도록 프로젝트를 구성해야 합니다.

국제화된 로거, 예외 또는 메시지 변환

  1. 다음 명령을 실행하여 템플릿 변환 속성 파일을 생성합니다.

    $ mvn compile
    Copy to Clipboard Toggle word wrap
  2. 생성된 디렉터리에서 프로젝트의 src/main/resources 디렉터리로 변환하려는 인터페이스의 템플릿을 복사합니다. 속성 파일은 변환 중인 인터페이스와 동일한 패키지에 있어야 합니다.
  3. 복사한 템플릿 파일의 이름을 변경하여 포함할 언어를 나타냅니다. 예를 들면 다음과 같습니다. GreeterLogger.i18n_fr_FR.properties.
  4. 적절한 번역을 포함하도록 새로운 번역 속성 파일의 내용을 편집합니다.

    # Level: Logger.Level.INFO
    # Message: Hello message sent.
    logHelloMessageSent=Bonjour message envoyé.
    Copy to Clipboard Toggle word wrap
  5. 템플릿을 복사하고 번들의 각 변환에 대해 수정하는 과정을 반복합니다.

이제 프로젝트에는 하나 이상의 메시지 또는 로거 번들에 대한 변환이 포함됩니다. 프로젝트를 구축하면 제공된 번역이 포함된 메시지를 로깅하는 적절한 클래스가 생성됩니다. 특정 언어의 메서드 또는 매개 변수를 명시적으로 호출할 필요는 없으며, JBoss Logging Tools는 애플리케이션 서버의 현재 로케일에 대해 올바른 클래스를 자동으로 사용합니다.

생성된 클래스의 소스 코드는 target/generated-sources/annotations/ 에서 볼 수 있습니다.

4.5.5. 국제화된 로그 메시지 사용자 정의

4.5.5.1. 로그 메시지에 메시지 ID 및 프로젝트 코드 추가

다음 절차에서는 JBoss Logging Tools를 사용하여 생성된 국제화된 로그 메시지에 메시지 ID 및 프로젝트 코드를 추가하는 방법을 설명합니다. 로그 메시지에는 로그에 표시할 프로젝트 코드와 메시지 ID가 모두 있어야 합니다. 메시지에 프로젝트 코드와 메시지 ID가 모두 없는 경우 둘 다 표시되지 않습니다.

사전 요구 사항

  1. 국제화된 로그 메시지가 있는 프로젝트가 이미 있어야 합니다. 자세한 내용은 국제화된 로그 메시지 생성을 참조하십시오.
  2. 사용할 프로젝트 코드를 알아야 합니다. 단일 프로젝트 코드를 사용하거나 각 인터페이스에 대해 다른 코드를 정의할 수 있습니다.

로그 메시지에 메시지 ID 및 프로젝트 코드 추가

  1. 사용자 지정 로거 인터페이스에 연결된 @MessageLogger 주석의 projectCode 특성을 사용하여 인터페이스에 대한 프로젝트 코드를 지정합니다. 인터페이스에서 정의된 모든 메시지는 해당 프로젝트 코드를 사용합니다.

    @MessageLogger(projectCode="ACCNTS")
    interface AccountsLogger extends BasicLogger {
    
    }
    Copy to Clipboard Toggle word wrap
  2. 메시지를 정의하는 메서드에 연결된 @Message 주석의 id 특성을 사용하여 각 메시지의 메시지 ID를 지정합니다.

    @LogMessage
    @Message(id=43, value = "Customer query failed, Database not available.")  void customerQueryFailDBClosed();
    Copy to Clipboard Toggle word wrap
  3. 메시지 ID와 프로젝트 코드가 연결된 로그 메시지 앞에는 로그 메시지가 기록된 메시지 앞에 추가됩니다.

    10:55:50,638 INFO  [com.company.accounts.ejb] (MSC service thread 1-4) ACCNTS000043: Customer query failed, Database not available.
    Copy to Clipboard Toggle word wrap
4.5.5.2. 메시지의 로그 수준을 지정합니다

JBoss Logging Tools의 인터페이스에서 정의한 메시지의 기본 로그 수준은 INFO(정보) 입니다. 로깅 메서드에 연결된 @LogMessage 주석의 level 특성을 사용하여 다른 로그 수준을 지정할 수 있습니다. 다음 절차에 따라 다른 로그 수준을 지정합니다.

  1. 로그 메시지 메서드 정의의 @LogMessage 주석에 level 속성을 추가합니다.
  2. level 특성을 사용하여 이 메시지의 로그 수준을 할당합니다. 수준에 유효한 값은 org.jboss.logging.Logger.Level에 정의된 6개의 열거된 상수입니다. DEBUG,ERROR,FATAL,INFO,TRACE, WARN.

    import org.jboss.logging.Logger.Level;
    
    @LogMessage(level=Level.ERROR)
    @Message(value = "Customer query failed, Database not available.")
    void customerQueryFailDBClosed();
    Copy to Clipboard Toggle word wrap

위 예제에서 로깅 메서드를 호출하면 ERROR (오류) 수준에서 로그 메시지가 생성됩니다.

10:55:50,638 ERROR  [com.company.app.Main] (MSC service thread 1-4)
 Customer query failed, Database not available.
Copy to Clipboard Toggle word wrap
4.5.5.3. 매개 변수를 사용하여 로그 메시지 사용자 지정

사용자 지정 로깅 방법은 매개 변수를 정의할 수 있습니다. 이러한 매개 변수는 로그 메시지에 표시할 추가 정보를 전달하는 데 사용됩니다. 로그 메시지에 매개 변수가 표시되는 위치는 명시적 또는 일반 인덱싱을 사용하여 메시지 자체에 지정됩니다.

매개 변수를 사용하여 로그 메시지 사용자 지정

  1. 모든 유형의 매개 변수를 메서드 정의에 추가합니다. 유형에 관계없이 매개 변수의 String 표시는 메시지에 표시됩니다.
  2. 로그 메시지에 매개 변수 참조를 추가합니다. 참조는 명시적 또는 일반 인덱스를 사용할 수 있습니다.

    • 일반 인덱스를 사용하려면 각 매개 변수를 표시하려는 메시지 문자열에 %s 문자를 삽입합니다. %s 의 첫 번째 인스턴스는 첫 번째 매개 변수를 삽입하고, 두 번째 인스턴스는 두 번째 매개 변수를 삽입합니다.
    • 명시적 인덱스를 사용하려면 메시지에 %#$s 문자를 삽입합니다. 여기서 #은 표시하려는 매개 변수 수를 나타냅니다.

명시적 인덱스를 사용하면 메시지의 매개 변수 참조가 메서드에 정의된 것과 다른 순서로 표시됩니다. 매개 변수 순서가 다를 수 있는 번역 메시지에는 중요합니다.

중요

매개 변수 수는 지정된 메시지의 매개 변수에 대한 참조 수와 일치해야 합니다. 그렇지 않으면 코드가 컴파일되지 않습니다. @ cause 주석 으로 표시된 매개 변수는 매개변수 수에 포함되지 않습니다.

다음은 일반 인덱스를 사용하는 메시지 매개변수의 예입니다.

@LogMessage(level=Logger.Level.DEBUG)
@Message(id=2, value="Customer query failed, customerid:%s, user:%s")
void customerLookupFailed(Long customerid, String username);
Copy to Clipboard Toggle word wrap

다음은 명시적 인덱스를 사용하는 메시지 매개변수의 예입니다.

@LogMessage(level=Logger.Level.DEBUG)
@Message(id=2, value="Customer query failed, user:%2$s, customerid:%1$s")
void customerLookupFailed(Long customerid, String username);
Copy to Clipboard Toggle word wrap
4.5.5.4. 로그 메시지의 원인으로 예외를 지정합니다.

JBoss Logging Tools를 사용하면 메시지의 원인으로 사용자 지정 로깅 방법 매개 변수를 하나 정의할 수 있습니다. 이 매개 변수는 Throwable 유형 또는 하위 클래스 중 하나여야 하며 @cause 주석으로 표시됩니다. 이 매개변수는 다른 매개변수와 마찬가지로 로그 메시지에서 참조할 수 없으며 로그 메시지 뒤에 표시됩니다.

다음 절차에서는 @ causes 매개 변수를 사용하여 "causing" 예외를 나타내는 로깅 방법을 업데이트하는 방법을 보여줍니다. 이 기능을 추가하려는 국제화된 로깅 메시지가 이미 생성되었다고 가정합니다.

로그 메시지의 원인으로 예외를 지정합니다.

  1. Throwable 또는 하위 클래스 유형의 매개 변수를 메서드에 추가합니다.

    @LogMessage
    @Message(id=404, value="Loading configuration failed. Config file:%s")
    void loadConfigFailed(Exception ex, File file);
    Copy to Clipboard Toggle word wrap
  2. @ causes 주석을 매개 변수에 추가합니다.

    import org.jboss.logging.annotations.Cause
    
    @LogMessage
    @Message(value = "Loading configuration failed. Config file: %s")
    void loadConfigFailed(@Cause Exception ex, File file);
    Copy to Clipboard Toggle word wrap
  3. 메서드를 호출합니다. 코드에서 메서드를 호출하면 올바른 유형의 오브젝트를 전달해야 하며 로그 메시지 뒤에 표시됩니다.

    try
    {
       confFile=new File(filename);
       props.load(new FileInputStream(confFile));
    }
    catch(Exception ex) //in case properties file cannot be read
    {
         ConfigLogger.LOGGER.loadConfigFailed(ex, filename);
    }
    Copy to Clipboard Toggle word wrap

다음은 코드에서 유형 FileNotFoundException 을 제외하고 발생하는 경우 위 코드 예제의 출력입니다.

10:50:14,675 INFO [com.company.app.Main] (MSC service thread 1-3) Loading configuration failed. Config file: customised.properties
java.io.FileNotFoundException: customised.properties (No such file or directory)
   at java.io.FileInputStream.open(Native Method)
   at java.io.FileInputStream.<init>(FileInputStream.java:120)
   at com.company.app.demo.Main.openCustomProperties(Main.java:70)
   at com.company.app.Main.go(Main.java:53)
   at com.company.app.Main.main(Main.java:43)
Copy to Clipboard Toggle word wrap

4.5.6. 국제화된 예외 사용자 정의

4.5.6.1. 예외 메시지에 메시지 ID 및 프로젝트 코드 추가

메시지 ID와 프로젝트 코드는 국제화된 예외에 의해 표시되는 각 메시지 앞에 오는 고유한 식별자입니다. 이러한 식별 코드를 통해 애플리케이션의 모든 예외 메시지에 대한 참조를 생성할 수 있습니다. 이를 통해 사람이 이해할 수 없는 언어로 작성된 예외 메시지의 의미를 조회할 수 있습니다.

다음 절차에서는 JBoss Logging Tools를 사용하여 생성된 국제화된 예외 메시지에 메시지 ID 및 프로젝트 코드를 추가하는 방법을 설명합니다.

사전 요구 사항

  1. 국제화된 예외가 있는 프로젝트가 이미 있어야 합니다. 자세한 내용은 Create Internationalized Exceptions를 참조하십시오.
  2. 사용할 프로젝트 코드를 알아야 합니다. 단일 프로젝트 코드를 사용하거나 각 인터페이스에 대해 다른 코드를 정의할 수 있습니다.

예외 메시지에 메시지 ID 및 프로젝트 코드 추가

  1. 예외 번들 인터페이스에 연결된 @MessageBundle 주석의 projectCode 특성을 사용하여 프로젝트 코드를 지정합니다. 인터페이스에서 정의된 모든 메시지는 해당 프로젝트 코드를 사용합니다.

    @MessageBundle(projectCode="ACCTS")
    interface ExceptionBundle
    {
       ExceptionBundle EXCEPTIONS = Messages.getBundle(ExceptionBundle.class);
    }
    Copy to Clipboard Toggle word wrap
  2. 예외를 정의하는 메서드에 연결된 @Message 주석의 id 특성을 사용하여 각 예외에 대해 메시지 ID를 지정합니다.

    @Message(id=143, value = "The config file could not be opened.")
    IOException configFileAccessError();
    Copy to Clipboard Toggle word wrap
중요

프로젝트 코드와 메시지 ID가 모두 있는 메시지는 메시지 앞에 표시됩니다. 메시지에 프로젝트 코드와 메시지 ID가 모두 없는 경우 둘 다 표시됩니다.

예제: 국제화 예외

이 예외 번들 인터페이스 예제에서는 "ACCTS"의 프로젝트 코드를 사용합니다. ID가 "143"인 단일 예외 메서드가 포함됩니다.

@MessageBundle(projectCode="ACCTS")
interface ExceptionBundle
{
    ExceptionBundle EXCEPTIONS = Messages.getBundle(ExceptionBundle.class);

    @Message(id=143, value = "The config file could not be opened.")
    IOException configFileAccessError();
}
Copy to Clipboard Toggle word wrap

다음 코드를 사용하여 예외 오브젝트를 가져오고 throw할 수 있습니다.

throw ExceptionBundle.EXCEPTIONS.configFileAccessError();
Copy to Clipboard Toggle word wrap

다음과 같은 예외 메시지가 표시됩니다.

Exception in thread "main" java.io.IOException: ACCTS000143: The config file could not be opened.
at com.company.accounts.Main.openCustomProperties(Main.java:78)
at com.company.accounts.Main.go(Main.java:53)
at com.company.accounts.Main.main(Main.java:43)
Copy to Clipboard Toggle word wrap
4.5.6.2. 매개 변수를 사용하여 예외 메시지 사용자 정의

예외 번들 메서드는 예외 메시지에 표시할 추가 정보를 전달하도록 매개 변수를 지정할 수 있습니다. 예외 메시지에서 매개 변수의 정확한 위치는 명시적 또는 일반 색인을 사용하여 메시지 자체에 지정됩니다.

매개 변수를 사용하여 예외 메시지 사용자 정의

  1. 모든 유형의 매개 변수를 메서드 정의에 추가합니다. 유형에 관계없이 매개 변수의 String 표시는 메시지에 표시됩니다.
  2. 매개 변수 참조를 예외 메시지에 추가합니다. 참조는 명시적 또는 일반 인덱스를 사용할 수 있습니다.

    • 일반 인덱스를 사용하려면 각 매개 변수를 표시하려는 메시지 문자열에 %s 문자를 삽입합니다. %s 의 첫 번째 인스턴스는 첫 번째 매개 변수를 삽입하고, 두 번째 인스턴스는 두 번째 매개 변수를 삽입합니다.
    • 명시적 인덱스를 사용하려면 메시지에 %#$s 문자를 삽입합니다. 여기서 #은 표시하려는 매개 변수 수를 나타냅니다.

명시적 인덱스를 사용하면 메시지의 매개 변수 참조가 메서드에 정의된 것과 다른 순서로 표시됩니다. 매개 변수 순서가 다를 수 있는 번역 메시지에는 중요합니다.

중요

매개 변수 수는 지정된 메시지의 매개 변수에 대한 참조 수와 일치해야 합니다. 그렇지 않으면 코드가 컴파일되지 않습니다. @ cause 주석 으로 표시된 매개 변수는 매개변수 수에 포함되지 않습니다.

예제: 일반 인덱스 사용

@Message(id=2, value="Customer query failed, customerid:%s, user:%s")
void customerLookupFailed(Long customerid, String username);
Copy to Clipboard Toggle word wrap

예제: 명시적 색인 사용

@Message(id=2, value="Customer query failed, user:%2$s, customerid:%1$s")
void customerLookupFailed(Long customerid, String username);
Copy to Clipboard Toggle word wrap

4.5.6.3. 다른 예외의 원인으로 One Exception을 지정합니다.

예외 번들 메서드에서 반환된 예외는 기본 원인으로 지정된 또 다른 예외를 가질 수 있습니다. 이 작업은 메서드에 매개 변수를 추가하고 @cause를 사용하여 매개 변수에 주석을 달아 수행됩니다. 이 매개변수는 원인 예외를 전달하는 데 사용되며 예외 메시지에서는 참조할 수 없습니다.

다음 절차에서는 원인인 예외를 나타내도록 @ causes 매개변수를 사용하여 예외 번들에서 메서드를 업데이트하는 방법을 보여줍니다. 이 기능을 추가하려는 예외 번들이 이미 생성되었다고 가정합니다.

  1. Throwable 또는 하위 클래스 유형의 매개 변수를 메서드에 추가합니다.

    @Message(id=328, value = "Error calculating: %s.")
    ArithmeticException calculationError(Throwable cause, String msg);
    Copy to Clipboard Toggle word wrap
  2. @ causes 주석을 매개 변수에 추가합니다.

    import org.jboss.logging.annotations.Cause
    
    @Message(id=328, value = "Error calculating: %s.")
    ArithmeticException calculationError(@Cause Throwable cause, String msg);
    Copy to Clipboard Toggle word wrap
  3. interface 메서드를 호출하여 예외 오브젝트를 가져옵니다. 가장 일반적인 사용 사례는 캡처된 예외를 원인으로 지정하여 캐치 블록에서 새로운 예외를 생성하는 것입니다.

    try
    {
       ...
    }
    catch(Exception ex)
    {
       throw ExceptionBundle.EXCEPTIONS.calculationError(
                                        ex, "calculating payment due per day");
    }
    Copy to Clipboard Toggle word wrap

다음은 다른 예외의 원인으로 예외를 지정하는 예입니다. 이 예외 번들은 typeth meticException 의 예외를 반환하는 단일 메서드를 정의합니다.

@MessageBundle(projectCode = "TPS")
interface CalcExceptionBundle
{
    CalcExceptionBundle EXCEPTIONS = Messages.getBundle(CalcExceptionBundle.class);

    @Message(id=328, value = "Error calculating: %s.")
    ArithmeticException calcError(@Cause Throwable cause, String value);
}
Copy to Clipboard Toggle word wrap

다음 예제에서는 정수를 0으로 분할하려고 하므로 예외가 발생하는 작업을 보여줍니다. 예외가 해결되고 첫 번째 예외를 원인으로 사용하여 새로운 예외가 생성됩니다.

int totalDue = 5;
int daysToPay = 0;
int amountPerDay;

try
{
   amountPerDay = totalDue/daysToPay;
}
catch (Exception ex)
{
   throw CalcExceptionBundle.EXCEPTIONS.calcError(ex, "payments per day");
}
Copy to Clipboard Toggle word wrap

다음은 이전 예제에서 생성된 예외 메시지입니다.

Exception in thread "main" java.lang.ArithmeticException: TPS000328: Error calculating: payments per day.
    at com.company.accounts.Main.go(Main.java:58)
    at com.company.accounts.Main.main(Main.java:43)
Caused by: java.lang.ArithmeticException: / by zero
    at com.company.accounts.Main.go(Main.java:54)
    ... 1 more
Copy to Clipboard Toggle word wrap

4.5.7. JBoss Logging Tools 참조

4.5.7.1. JBoss Logging Tools Maven 구성

다음 절차에서는 국제화를 위해 JBoss Logging 및 JBoss Logging Tools를 사용하도록 Maven 프로젝트를 구성합니다.

  1. 아직 완료하지 않은 경우 JBoss EAP 리포지토리를 사용하도록 Maven 설정을 구성합니다. 자세한 내용은 Configure the JBoss EAP Maven Repository using the Maven Settings 에서 참조하십시오.

    프로젝트의 pom.xml 파일의 <dependencyManagement> 섹션에 jboss-eap-jakartaee8 BOM을 포함합니다.

    <dependencyManagement>
      <dependencies>
        <!-- JBoss distributes a complete set of Jakarta EE APIs including
          a Bill of Materials (BOM). A BOM specifies the versions of a "stack" (or
          a collection) of artifacts. We use this here so that we always get the correct versions of artifacts.
          Here we use the jboss-javaee-7.0 stack (you can
          read this as the JBoss stack of the Jakarta EE APIs). You can actually
          use this stack with any version of JBoss EAP that implements Jakarta EE. -->
        <dependency>
          <groupId>org.jboss.bom</groupId>
           <artifactId>jboss-eap-jakartaee8</artifactId>
           <version>7.4.0.GA</version>
           <type>pom</type>
           <scope>import</scope>
        </dependency>
      <dependencies>
    <dependencyManagement>
    Copy to Clipboard Toggle word wrap
  2. 프로젝트의 pom.xml 파일에 Maven 종속성을 추가합니다.

    1. JBoss Logging 프레임워크에 액세스하려면 jboss-logging 종속성을 추가합니다.
    2. JBoss Logging Tools를 사용하려는 경우 jboss-logging-processor 종속성도 추가합니다.

      이러한 종속성은 이전 단계에서 추가한 JBoss EAP BOM에서 사용 가능하므로 각각의 범위 요소를 표시된 대로 provided 로 설정할 수 있습니다.

      <!-- Add the JBoss Logging Tools dependencies -->
      <!-- The jboss-logging API -->
      <dependency>
         <groupId>org.jboss.logging</groupId>
         <artifactId>jboss-logging</artifactId>
         <scope>provided</scope>
      </dependency>
      <!-- Add the jboss-logging-tools processor if you are using JBoss Tools  -->
      <dependency>
         <groupId>org.jboss.logging</groupId>
         <artifactId>jboss-logging-processor</artifactId>
         <scope>provided</scope>
      </dependency>
      Copy to Clipboard Toggle word wrap
  3. maven-compiler-plugin은 버전 3.1 이상이어야 하며 1.8 의 대상 및 생성된 소스에 맞게 구성해야 합니다.

    <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-compiler-plugin</artifactId>
       <version>3.1</version>
       <configuration>
          <source>1.8</source>
          <target>1.8</target>
       </configuration>
    </plugin>
    Copy to Clipboard Toggle word wrap
참고

JBoss Logging Tools를 사용하도록 구성된 pom.xml 파일의 전체 작업 예는 JBoss EAP와 함께 제공되는 logging-tools 빠른 시작을 참조하십시오.

4.5.7.2. 번역 속성 파일 형식

JBoss Logging Tools의 메시지 변환에 사용되는 속성 파일은 표준 Java 속성 파일입니다. 파일의 형식은 java.util.Properties 클래스 설명서에 설명된 간단한 줄 지향 key=value 쌍 형식입니다.

파일 이름 형식에는 다음 형식이 있습니다.

InterfaceName.i18n_locale_COUNTRY_VARIANT.properties
Copy to Clipboard Toggle word wrap
  • interface name은 변환이 적용되는 인터페이스의 이름입니다.
  • 로케일,COUNTRYVARIANT 는 변환이 적용되는 지역 설정을 식별합니다.
  • 로케일COUNTRY 는 각각 ISO-639 및 ISO-3166 언어 및 국가 코드를 사용하여 언어와 국가를 지정합니다. COUNTRY 는 선택 사항입니다.
  • VARIANT 는 특정 운영 체제 또는 브라우저에만 적용되는 번역을 식별하는 데 사용할 수 있는 선택적 식별자입니다.

번역 파일에 포함된 속성은 번역 중인 인터페이스에서 메서드의 이름입니다. 속성의 할당된 값은 번역입니다. 메서드에 과부하가 걸리면 점과 매개 변수 수를 이름에 추가하여 표시됩니다. 번역 방법은 다른 매개 변수 수를 제공해야만 과부하할 수 있습니다.

예제: 번역 속성 파일

파일 이름: GreeterService.i18n_fr_FR_POSIX.properties.

# Level: Logger.Level.INFO
# Message: Hello message sent.
logHelloMessageSent=Bonjour message envoyé.
Copy to Clipboard Toggle word wrap
4.5.7.3. JBoss Logging Tools 주석 참조

다음 주석은 로그 메시지, 문자열 및 예외의 국제화 및 현지화와 함께 사용할 수 있도록 JBoss Logging에 정의됩니다.

Expand
표 4.2. JBoss 로깅 툴 주석
주석대상설명속성

@MessageBundle

인터페이스

인터페이스를 메시지 번들로 정의합니다.

projectCode

@MessageLogger

인터페이스

인터페이스를 메시지 로거로 정의합니다.

projectCode

@Message

방법

메시지 번들 및 메시지 로거에서 사용할 수 있습니다. 메시지 번들에서 로컬화된 String 또는 Exception 오브젝트를 반환하는 메서드를 정의합니다. 메시지 로거에서는 로컬화된 로거가 되는 메서드를 정의합니다.

값, id

@LogMessage

방법

메시지 로거에서 로깅 메서드로 메서드를 정의합니다.

수준(기본 정보)

@Cause

매개변수

매개 변수를 로그 메시지 또는 다른 Exception의 원인으로 Exception을 전달하는 것으로 정의합니다.

-

@Param

매개변수

매개 변수를 Exception의 생성자에 전달되는 것으로 정의합니다.

-

4.5.7.4. JBoss EAP에 사용된 프로젝트 코드

다음 표에는 JBoss EAP 7.4에 사용된 모든 프로젝트 코드와 해당 코드가 속한 Maven 모듈이 나열되어 있습니다.

Expand
표 4.3. JBoss EAP에 사용된 프로젝트 코드
Maven 모듈프로젝트 코드

AppClient

WFLYAC

batch/extension-jberet

WFLYBATCH

배치/확장

WFLYBATCH-DEPRECATED

batch/jberet

WFLYBAT

bean-validation

WFLYBV

controller-client

WFLYCC

컨트롤러

WFLYCTL

클러스터링/공통

WFLYCLCOM

clustering/ejb/infinispan

WFLYCLEJBINF

클러스터링/infinispan/extension

WFLYCLINF

clustering/jgroups/extension

WFLYCLJG

클러스터링/서버

WFLYCLSV

클러스터링/웹/infinispan

WFLYCLWEBINF

커넥터

WFLYJCA

deployment-repository

WFLYDR

deployment-scanner

WFLYDS

domain-http

WFLYDMHTTP

domain-management

WFLYDM

EE

WFLYEE

ejb3

WFLYEJB

임베디드

WFLYEMB

host-controller

WFLYDC

host-controller

WFLYHC

iiop-openjdk

WFLYIIOP

io/subsystem

WFLYIO

jaxrs

WFLYRS

jdr

WFLYJDR

jmx

WFLYJMX

jpa/hibernate5

JIPI

jpa/spi/src/main/java/org/jipijapa/JipiLogger.java

JIPI

jpa/subsystem

WFLYJPA

jsf/subsystem

WFLYJSF

jsr77

WFLYEEMGMT

시작 도구

WFLYLNCHR

레거시/jacorb

WFLYORB

레거시/메시징

WFLYMSG

legacy/web

WFLYWEB

로깅

WFLYLOG

메일

WFLYMAIL

management-client-content

WFLYCNT

messaging-activemq

WFLYMSGAMQ

mod_cluster/extension

WFLYMODCLS

이름 지정

WFLYNAM

network

WFLYNET

패치 중

WFLYPAT

Picketlink

WFLYPL

platform-mbean

WFLYPMB

POJO

WFLYPOJO

process-controller

WFLYPC

프로토콜

WFLYPRT

Remoting

WFLYRMT

request-controller

WFLYREQCON

RTS

WFLYRTS

SAR

WFLYSAR

security-manager

WFLYSM

보안

FFLYSEC

server

WFLYSRV

system-jmx

WFLYSYSJMX

스레드

WFLYTHR

트랜잭션

WFLYTX

Undertow

WFLYUT

webservices/server-integration

WFLYWS

와일드

WFLYWELD

XTS

WFLYXTS

5장. 원격 JNDI 조회

5.1. Java Naming 및 Directory Interface에 오브젝트 등록

Java 네이밍 및 디렉터리 인터페이스는 Java 소프트웨어 클라이언트가 이름을 사용하여 개체를 검색하고 조회할 수 있는 디렉터리 서비스의 Java API입니다.

Java Naming 및 Directory Interface에 등록된 오브젝트를 원격 Java Naming 및 Directory Interface 클라이언트(예: 별도의 JVM에서 실행되는 클라이언트)에서 조회해야 하는 경우 java:jboss/exported 컨텍스트에서 등록해야 합니다.

예를 들어 원격 Java 네이밍 및 디렉터리 인터페이스 클라이언트에 messaging-activemq 하위 시스템의 자카르타 메시징 큐가 노출되어야 하는 경우 java:jboss/exported/jms/queue/myTestQueue 를 사용하여 Java 네이밍 및 디렉터리 인터페이스에 등록해야 합니다. 그런 다음 원격 Java 네이밍 및 디렉터리 인터페이스 클라이언트는 이름 jms/queue/myTestQueue 로 검색할 수 있습니다.

예제: standalone-full(-ha).xml에서 큐 구성

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <jms-queue name="myTestQueue" entries="java:jboss/exported/jms/queue/myTestQueue"/>
    ...
  </server>
</subsystem>
Copy to Clipboard Toggle word wrap

5.2. 원격 JNDI 구성

원격 JNDI 클라이언트는 JNDI에서 이름으로 개체를 연결하고 조회할 수 있습니다. 원격 JNDI 클라이언트를 사용하여 개체를 찾으려면 클래스 경로에 jboss-client.jar 가 있어야 합니다. jboss-client.jarEAP_HOME/bin/client/jboss-client.jar 에서 사용할 수 있습니다.

다음 예제에서는 원격 JNDI 클라이언트의 JNDI에서 myTestQueue 큐를 조회하는 방법을 보여줍니다.

예제: MDB 리소스 어댑터 구성

Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
properties.put(Context.PROVIDER_URL, "remote+http://HOST_NAME:8080");
context = new InitialContext(properties);
Queue myTestQueue = (Queue) context.lookup("jms/queue/myTestQueue");
Copy to Clipboard Toggle word wrap

5.3. HTTP를 통한 JNDI 호출

HTTP를 통한 JNDI 호출에는 클라이언트 측 및 서버 측 구현의 두 가지 부분이 포함됩니다.

5.3.1. 클라이언트 측 구현

클라이언트 측 구현은 원격 이름 지정 구현과 유사하지만 Undertow HTTP 클라이언트를 사용하는 HTTP를 기반으로 합니다.

연결 관리는 기존 원격 이름 지정 구현에 사용된 것과 유사한 캐싱 접근 방식을 사용하는 직접 대신 암시적입니다. 연결 풀은 연결 매개 변수를 기반으로 캐시됩니다. 지정된 시간제한 기간에 사용하지 않으면 삭제됩니다.

HTTP 전송을 사용하도록 원격 JNDI 클라이언트 애플리케이션을 구성하려면 HTTP 전송 구현에 다음 종속성을 추가해야 합니다.

<dependency>
    <groupId>org.wildfly.wildfly-http-client</groupId>
    <artifactId>wildfly-http-naming-client</artifactId>
</dependency>
Copy to Clipboard Toggle word wrap

HTTP 호출을 수행하려면 http URL 스키마를 사용하고 HTTP 호출자( wildfly-services )의 컨텍스트 이름을 포함해야 합니다. 예를 들어 remote+http://localhost:8080 을 대상 URL로 사용하는 경우 HTTP 전송을 사용하려면 이를 http://localhost:8080/wildfly-services 로 업데이트해야 합니다.

5.3.2. 서버 측 구현

서버 측 구현은 기존의 원격 이름 지정 구현과 유사하지만 HTTP 전송을 사용하는 것입니다.

서버를 구성하려면 undertow 하위 시스템에서 사용하려는 각 가상 호스트에서 http-invoker 를 활성화해야 합니다. 이는 표준 구성에서 기본적으로 활성화되어 있습니다. 비활성화된 경우 다음 관리 CLI 명령을 사용하여 다시 활성화할 수 있습니다.

/subsystem=undertow/server=default-server/host=default-host/setting=http-invoker:add(http-authentication-factory=myfactory, path="/wildfly-services")
Copy to Clipboard Toggle word wrap

http-invoker 속성에는 두 매개 변수, 기본적으로 /wildfly-services 및 Elytron http-authentication-factory 에 대한 참조여야 하는 http-authentication-factory 가 사용됩니다.

참고

http-authentication-factory 를 사용하려는 모든 배포에서는 지정된 HTTP 인증 팩토리에 해당하는 동일한 보안 도메인과 함께 Elytron 보안을 사용해야 합니다.

6장. 웹 애플리케이션에서 클러스터링

6.1. 세션 복제

6.1.1. HTTP 세션 복제 정보

세션 복제를 사용하면 클러스터에서 노드 페일오버로 인해 배포 가능한 애플리케이션의 클라이언트 세션이 중단되지 않습니다. 클러스터의 각 노드는 진행 중인 세션에 대한 정보를 공유하며 노드가 사라진 경우 세션을 인계받을 수 있습니다.

세션 복제는 mod_cluster, mod_jk, mod_proxy, ISAPI 및 NSAPI 클러스터가 고가용성을 제공하는 메커니즘입니다.

6.1.2. 애플리케이션에서 세션 복제 활성화

JBoss EAP HA(고가용성) 기능을 활용하고 웹 애플리케이션의 클러스터링을 활성화하려면 애플리케이션을 배포 가능하도록 구성해야 합니다. 애플리케이션이 배포 가능으로 표시되지 않으면 해당 세션은 배포되지 않습니다.

애플리케이션 배포 가능
  1. 애플리케이션 web.xml 설명자 파일의 < web-app> 태그 내에 < distributable/ > 요소를 추가합니다.

    예제: 배포 가능한 애플리케이션의 최소 구성

    <?xml version="1.0"?>
    <web-app  xmlns="http://java.sun.com/xml/ns/j2ee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
                                  http://java.sun.com/xml/ns/j2ee/web-app_3_0.xsd"
              version="3.0">
    
          <distributable/>
    
    </web-app>
    Copy to Clipboard Toggle word wrap

  2. 다음으로 필요한 경우 기본 복제 동작을 수정합니다. 세션 복제에 영향을 미치는 값을 변경하려면 애플리케이션의 WEB-INF/jboss-web.xml 파일에서 < jboss-web> 요소 내의 <replication- config > 요소 내에서 이를 재정의할 수 있습니다. 지정된 요소에 대해 기본값을 재정의하려는 경우에만 포함합니다.

    예: <replication-config>

    <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd">
       <replication-config>
          <replication-granularity>SESSION</replication-granularity>
        </replication-config>
    </jboss-web>
    Copy to Clipboard Toggle word wrap

<replication-granularity> 매개변수는 복제된 데이터의 세분성을 결정합니다. 기본적으로 SESSION 이지만 대부분의 속성이 변경되지 않은 세션에서 성능을 높이기 위해 ATTRIBUTE 로 설정할 수 있습니다.

<replication-granularity> 에 유효한 값은 다음과 같습니다.

  • 세션: 기본값입니다. 속성이 더티인 경우 전체 세션 오브젝트가 복제됩니다. 이 정책은 여러 세션 특성에서 오브젝트 참조를 공유하는 경우 필요합니다. 전체 세션이 하나의 단위로 직렬화되므로 공유 오브젝트 참조는 원격 노드에서 유지됩니다.
  • 속성: 이는 세션의 더티 속성 및 마지막 액세스 타임스탬프와 같은 일부 세션 데이터의 경우에만 해당합니다.
변경할 수 없는 세션 속성

JBoss EAP 7의 경우 세션이 변경되거나 세션의 변경 속성에 액세스할 때 세션 복제가 트리거됩니다. 다음 중 하나가 충족되지 않는 한 세션 속성은 변경 가능으로 간주됩니다.

  • 값은 다음과 같은 알려진 불변 값입니다.

    • null
    • java.util.Collections.EMPTY_LIST, EMPTY_MAP, EMPTY_SET
  • 값 유형은 알려진 불변 유형을 사용하거나 구현합니다.

    • java.lang.Boolean,문자,바이트,쇼트,정수,,Float
    • java.lang.Class, Enum, StackTraceElement, String
    • java.io.File, java.nio.file.Path
    • java.math.BigDecimal, BigInteger, MathContext
    • java.net.Inet4Address, Inet6Address, InetSocketAddress, URI, URL
    • java.security.Permission
    • java.util.Currency, Locale, TimeZone, UUID
    • java.time.Clock,기간,인스턴트,LocalDate Time,LocalDateTime , monthsDay, period, Year,YearMonth,ZoneId,ZoneOffset,ZonedDateTime
    • java.time.chrono.ChronoLocalDate, Chronology, Era
    • java.time.format.DateTimeFormatter, DecimalStyle
    • java.time.temporal.TemporalField, TemporalUnit, ValueRange, WeekFields
    • java.time.zone.ZoneOffsetTransition, ZoneOffsetTransitionRule, ZoneRules
  • 값 유형에는 다음과 같이 주석이 추가됩니다.

    • @org.wildfly.clustering.web.annotation.Immutable
    • @net.jcip.annotations.Immutable

6.1.3. 세션 특성 마샬링

개별 세션 속성에 대한 복제 또는 지속성 페이로드를 최소화하면 네트워크를 통해 전송되거나 스토리지에 유지되는 바이트 수를 줄임으로써 성능을 직접 개선할 수 있습니다. 웹 애플리케이션을 사용하면 다음과 같은 방법으로 세션 속성의 마샬링을 최적화할 수 있습니다.

  • JDK(Java Development Kit) 직렬화 논리를 사용자 지정할 수 있습니다.
  • 사용자 지정 externalizer를 구현할 수 있습니다.

externalizer는 클래스의 마샬링을 지정하는 org.wildfly.clustering.marshalling.Externalizer 인터페이스를 구현합니다. externalizer는 개체의 상태를 직접 읽거나 입력/출력 스트림에 쓸 뿐만 아니라 다음 작업을 수행합니다.

  • 애플리케이션에서 java.io.Serializable를 구현하지 않는 세션에 오브젝트를 저장할 수 있도록 합니다.
  • 해당 상태와 함께 오브젝트의 클래스 설명자를 직렬화할 필요가 없습니다.

    예제

    public class MyObjectExternalizer implements org.wildfly.clustering.marshalling.Externalizer<MyObject> {
    
        @Override
        public Class<MyObject> getTargetClass() {
            return MyObject.class;
        }
    
        @Override
        public void writeObject(ObjectOutput output, MyObject object) throws IOException {
            // Write object state to stream
        }
    
        @Override
        public MyObject readObject(ObjectInput input) throws IOException, ClassNotFoundException {
            // Construct and read object state from stream
            return ...;
        }
    }
    Copy to Clipboard Toggle word wrap

참고

서비스 로더 메커니즘은 배포 중에 외부라이저를 동적으로 로드합니다. 구현 작업은 /META-INF/services/org.wildfly.clustering.marshalling.Externalizer 파일 내에서 열거해야 합니다.

6.2. HTTP 세션 비활성화 및 활성화

6.2.1. HTTP 세션 활성화 및 활성화 정보

패시베이션 은 영구 스토리지에 저장하는 동안 메모리에서 비교적 사용하지 않는 세션을 제거하여 메모리 사용량을 제어하는 프로세스입니다.

활성화 는 패시베이션된 데이터가 지속되는 스토리지에서 검색되어 메모리에 다시 배치될 때입니다.

비활성화는 HTTP 세션의 수명 동안 서로 다른 시간에 발생합니다.

  • 컨테이너가 새 세션의 생성을 요청하면 현재 활성 세션 수가 구성 가능한 제한을 초과하는 경우 서버에서 일부 세션을 비활성화하여 새 세션의 공간을 만들려고 합니다.
  • 웹 애플리케이션이 배포되고 다른 서버에서 활성화된 세션의 백업 사본이 새로 배포되는 웹 애플리케이션의 세션 관리자가 획득하면 세션이 비활성화될 수 있습니다.

활성 세션 수가 구성 가능한 최대값을 초과하면 세션이 비활성화됩니다.

세션은 Least Recently Used(LRU) 알고리즘을 사용하여 항상 비활성화됩니다.

6.2.2. 애플리케이션에서 HTTP 세션 비활성화 구성

HTTP 세션 비활성화는 애플리케이션의 WEB-INF/jboss-web.xmlMETA-INF/jboss-web.xml 파일에 구성됩니다.

예: jboss-web.xml 파일

<jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd">

   <max-active-sessions>20</max-active-sessions>
</jboss-web>
Copy to Clipboard Toggle word wrap

<max-active-sessions> 요소는 허용되는 최대 활성 세션 수를 지정하며 세션 비활성화를 활성화하는 데 사용됩니다. 세션 생성으로 인해 활성 세션 수가 <max-active-sessions> 를 초과하면 세션 관리자로 알려진 가장 오래된 세션이 비활성화되어 새 세션의 공간을 만듭니다.

참고

메모리의 총 세션 수에는 이 노드에서 액세스하지 않는 다른 클러스터 노드에서 복제된 세션이 포함됩니다. <max-active-sessions> 를 설정할 때 이 문제를 고려합니다. 다른 노드에서 복제된 세션 수는 REPL 또는 DIST 캐시 모드가 활성화되어 있는지에 따라 달라집니다. REPL 캐시 모드에서는 각 세션이 각 노드에 복제됩니다. DIST 캐시 모드에서 각 세션은 owner 매개변수 에서 지정한 노드 수에만 복제됩니다. 세션 캐시 모드 구성에 대한 자세한 내용은 JBoss EAP 구성 가이드 의 캐시 모드 구성을 참조하십시오. 예를 들어 각 노드가 100명의 사용자의 요청을 처리하는 8개의 노드 클러스터를 고려해 보십시오. REPL 캐시 모드를 사용하면 각 노드는 800 세션을 메모리에 저장합니다. DIST 캐시 모드를 활성화하고 기본 소유자 2 설정을 사용하면 각 노드는 200 세션을 메모리에 저장합니다.

6.3. 클러스터링 서비스를 위한 공용 API

JBoss EAP 7은 애플리케이션에서 사용할 수 있는 구체화된 공용 클러스터링 API를 도입했습니다. 새 서비스는 외부 종속성 없이 가볍고 쉽게 주입할 수 있도록 설계되었습니다.

org.wildfly.clustering.group.Group

그룹 서비스는 JGroups 채널의 클러스터 토폴로지를 보고 토폴로지가 변경될 때 알림을 받는 메커니즘을 제공합니다.

@Resource(lookup = "java:jboss/clustering/group/channel-name")
private Group channelGroup;
Copy to Clipboard Toggle word wrap
org.wildfly.clustering.dispatcher.CommandDispatcher

command DispatcherFactory 서비스는 클러스터의 노드에서 명령을 실행하기 위한 디스패처를 생성하는 메커니즘을 제공합니다. 결과 CommandDispatcher 는 이전 JBoss EAP 릴리스의 그림 기반 GroupRpcDispatcher 에 대한 명령-패턴 아날로그입니다.

@Resource(lookup = "java:jboss/clustering/dispatcher/channel-name")
private CommandDispatcherFactory factory;

public void foo() {
    String context = "Hello world!";
    // Exclude node1 and node3 from the executeOnCluster
    try (CommandDispatcher<String> dispatcher = this.factory.createCommandDispatcher(context)) {
        dispatcher.executeOnGroup(new StdOutCommand(), node1, node3);

    }
}

public static class StdOutCommand implements Command<Void, String> {
    @Override
    public Void execute(String context) {
        System.out.println(context);
        return null;
    }
}
Copy to Clipboard Toggle word wrap

6.4. HA Singleton 서비스

클러스터형 Singleton 서비스(고가용성(HA) Singleton이라고도 함)는 클러스터의 여러 노드에 배포된 서비스입니다. 서비스는 노드 중 하나에서만 제공됩니다. Singleton 서비스를 실행 중인 노드를 일반적으로 마스터 노드라고 합니다.

마스터 노드가 실패하거나 종료되면 나머지 노드에서 다른 마스터가 선택되고 새 마스터에서 서비스가 다시 시작됩니다. 하나의 마스터가 중지되고 다른 마스터가 아직 인계되지 않은 경우의 간략한 간격 이외의 서비스는 하나와 하나의 노드에서만 제공됩니다.

HA Singleton ServiceBuilder API

JBoss EAP 7은 프로세스를 크게 단순화하는 Singleton 서비스 구축을 위한 새로운 공용 API를 도입했습니다.

SingletonServiceConfigurator 구현은 서비스를 설치하므로 비동기적으로 시작하여 MSC(Modular Service Container)의 교착 상태가 발생하지 않습니다.

HA Singleton 서비스 선택 정책

HA Singleton을 시작해야 하는 노드가 선호하는 경우 ServiceActivator 클래스에서 선택 정책을 설정할 수 있습니다.

JBoss EAP는 다음 두 가지 선택 정책을 제공합니다.

  • 단순 선택 정책

    간단한 선택 정책은 상대 기간에 따라 마스터 노드를 선택합니다. 필요한 기간은 사용 가능한 노드 목록의 인덱스인 position 속성에 구성됩니다. 여기서 다음과 같습니다.

    • position = 0 - 가장 오래된 노드를 나타냅니다. 이는 기본값입니다.
    • position = 1 - 가장 오래된 2번째 등을 나타냅니다.

    위치는 가장 오래된 노드를 나타내기 위해 음수일 수도 있습니다.

    • position = -1 - 가장 오래된 노드를 나타냅니다.
    • position = -2 - 두 번째 가장 오래된 노드 등을 나타냅니다.
  • 임의 선택 정책

    임의 선택 정책은 Singleton 서비스 공급자로 임의 구성원을 선택합니다.

HA Singleton 서비스 환경 설정

HA Singleton 서비스 선택 정책은 선택적으로 하나 이상의 기본 서버를 지정할 수 있습니다. 이 선호하는 서버는 해당 정책에 따라 모든 Singleton 애플리케이션에 대한 마스터가 됩니다.

노드 이름 또는 아웃바운드 소켓 바인딩 이름을 통해 기본 설정을 정의할 수 있습니다.

참고

노드 기본 설정은 항상 선택 정책의 결과보다 우선합니다.

기본적으로 JBoss EAP 고가용성 구성에서는 default 라는 간단한 선택 정책에 기본 서버가 없는 간단한 선택 정책을 제공합니다. 사용자 지정 정책을 생성하고 기본 서버를 정의하여 기본 설정을 설정할 수 있습니다.

쿼럼

Singleton 서비스에 대한 잠재적인 문제는 네트워크 파티션이 있는 경우 발생합니다. 이 경우 split-brain 시나리오라고도 하며 노드의 하위 집합은 서로 통신할 수 없습니다. 각 서버 집합은 다른 세트의 모든 서버가 실패한 것으로 간주하고 생존 클러스터로 계속 작동합니다. 이로 인해 데이터 일관성 문제가 발생할 수 있습니다.

JBoss EAP를 사용하면 선택 정책에 쿼럼을 지정하여 split-brain 시나리오를 방지할 수 있습니다. 쿼럼은 Singleton 공급자 선택을 수행하기 전에 존재할 최소 노드 수를 지정합니다.

일반적인 배포 시나리오에서는 N/2 + 1의 쿼럼을 사용합니다. 여기서 N은 예상되는 클러스터 크기입니다. 이 값은 런타임 시 업데이트할 수 있으며 활성 Singleton 서비스에 즉시 영향을 미칩니다.

HA Singleton 서비스 선택 리스너

새로운 기본 Singleton 서비스 공급자를 선택하고 나면 등록된 SingletonElectionListener 가 트리거되고 클러스터의 모든 멤버에게 새 기본 공급자에 대해 알립니다. 다음 예는 SingletonElectionListener 의 사용법을 보여줍니다.

public class MySingletonElectionListener implements SingletonElectionListener {
    @Override
    public void elected(List<Node> candidates, Node primary) {
        // ...
    }
}

public class MyServiceActivator implements ServiceActivator {
    @Override
    public void activate(ServiceActivatorContext context) {
        String containerName = "foo";
        SingletonElectionPolicy policy = new MySingletonElectionPolicy();
        SingletonElectionListener listener = new MySingletonElectionListener();
        int quorum = 3;
        ServiceName name = ServiceName.parse("my.service.name");
        // Use a SingletonServiceConfiguratorFactory backed by default cache of "foo" container
        Supplier<SingletonServiceConfiguratorFactory> factory = new ActiveServiceSupplier<SingletonServiceConfiguratorFactory>(context.getServiceRegistry(), ServiceName.parse(SingletonDefaultCacheRequirement.SINGLETON_SERVICE_CONFIGURATOR_FACTORY.resolve(containerName)));
        ServiceBuilder<?> builder = factory.get().createSingletonServiceConfigurator(name)
            .electionListener(listener)
            .electionPolicy(policy)
            .requireQuorum(quorum)
            .build(context.getServiceTarget());
        Service service = new MyService();
        builder.setInstance(service).install();
    }
}
Copy to Clipboard Toggle word wrap
HA Singleton 서비스 애플리케이션 생성

다음은 애플리케이션을 클러스터 전체 Singleton 서비스로 생성하고 배포하는 데 필요한 단계의 축약된 예입니다. 이 예제에서는 Singleton 서비스를 정기적으로 쿼리하여 실행 중인 노드의 이름을 가져오는 쿼리 서비스를 보여줍니다.

Singleton 동작을 보려면 애플리케이션을 두 개 이상의 서버에 배포해야 합니다. Singleton 서비스가 동일한 노드에서 실행 중인지 또는 값을 원격으로 가져올지 여부는 명확합니다.

  1. SingletonService 클래스를 만듭니다. 쿼리 서비스에서 호출하는 getValue() 메서드는 실행 중인 노드에 대한 정보를 제공합니다.

    class SingletonService implements Service {
        private Logger LOG = Logger.getLogger(this.getClass());
        private Node node;
    
        private Supplier<Group> groupSupplier;
        private Consumer<Node> nodeConsumer;
    
        SingletonService(Supplier<Group> groupSupplier, Consumer<Node> nodeConsumer) {
           this.groupSupplier = groupSupplier;
           this.nodeConsumer = nodeConsumer;
        }
    
        @Override
        public void start(StartContext context) {
            this.node = this.groupSupplier.get().getLocalMember();
    
            this.nodeConsumer.accept(this.node);
    
            LOG.infof("Singleton service is started on node '%s'.", this.node);
        }
    
        @Override
        public void stop(StopContext context) {
            LOG.infof("Singleton service is stopping on node '%s'.", this.node);
    
            this.node = null;
        }
    }
    Copy to Clipboard Toggle word wrap
  2. 쿼리 서비스를 생성합니다. Singleton 서비스의 getValue() 메서드를 호출하여 실행 중인 노드의 이름을 가져온 다음 결과를 서버 로그에 씁니다.

    class QueryingService implements Service {
        private Logger LOG = Logger.getLogger(this.getClass());
        private ScheduledExecutorService executor;
    
        @Override
        public void start(StartContext context) throws {
            LOG.info("Querying service is starting.");
    
            executor = Executors.newSingleThreadScheduledExecutor();
            executor.scheduleAtFixedRate(() -> {
    
            Supplier<Node> node = new PassiveServiceSupplier<>(context.getController().getServiceContainer(), SingletonServiceActivator.SINGLETON_SERVICE_NAME);
             if (node.get() != null) {
                 LOG.infof("Singleton service is running on this (%s) node.", node.get());
             } else {
                 LOG.infof("Singleton service is not running on this node.");
             }
    
            }, 5, 5, TimeUnit.SECONDS);
        }
    
        @Override
        public void stop(StopContext context) {
            LOG.info("Querying service is stopping.");
    
            executor.shutdown();
        }
    }
    Copy to Clipboard Toggle word wrap
  3. SingletonServiceActivator 클래스를 구현하여 Singleton 서비스와 쿼리 서비스를 모두 빌드하고 설치합니다.

    public class SingletonServiceActivator implements ServiceActivator {
    
        private final Logger LOG = Logger.getLogger(SingletonServiceActivator.class);
    
        static final ServiceName SINGLETON_SERVICE_NAME =
                ServiceName.parse("org.jboss.as.quickstarts.ha.singleton.service");
        private static final ServiceName QUERYING_SERVICE_NAME =
                ServiceName.parse("org.jboss.as.quickstarts.ha.singleton.service.querying");
    
        @Override
        public void activate(ServiceActivatorContext serviceActivatorContext) {
            SingletonPolicy policy = new ActiveServiceSupplier<SingletonPolicy>(
                    serviceActivatorContext.getServiceRegistry(),
                    ServiceName.parse(SingletonDefaultRequirement.POLICY.getName())).get();
    
            ServiceTarget target = serviceActivatorContext.getServiceTarget();
            ServiceBuilder<?> builder = policy.createSingletonServiceConfigurator(SINGLETON_SERVICE_NAME).build(target);
            Consumer<Node> member = builder.provides(SINGLETON_SERVICE_NAME);
            Supplier<Group> group = builder.requires(ServiceName.parse("org.wildfly.clustering.default-group"));
            builder.setInstance(new SingletonService(group, member)).install();
    
            serviceActivatorContext.getServiceTarget()
                    .addService(QUERYING_SERVICE_NAME, new QueryingService())
                    .setInitialMode(ServiceController.Mode.ACTIVE)
                    .install();
    
            serviceActivatorContext.getServiceTarget().addService(QUERYING_SERVICE_NAME).setInstance(new QueryingService()).install();
    
            LOG.info("Singleton and querying services activated.");
        }
    }
    Copy to Clipboard Toggle word wrap
  4. ServiceActivator 클래스 의 이름이 포함된 org.jboss.msc.service.ServiceActivator 라는 META-INF/services/ 디렉터리에 파일을 만듭니다(예: org.jboss.as.quickstarts.ha.singleton.service.SingletonServiceActivator ).

전체 작업 예는 JBoss EAP와 함께 제공되는 ha-singleton-service 빠른 시작을 참조하십시오. 이 빠른 시작에서는 백업 서비스를 사용하여 설치된 Singleton 서비스를 보여주는 두 번째 예제도 제공합니다. 백업 서비스는 Singleton 서비스를 실행 중이 아닌 모든 노드에서 실행 중입니다. 마지막으로 이 빠른 시작에서는 몇 가지 다른 선택 정책을 구성하는 방법도 보여줍니다.

6.5. HA Singleton 배포

애플리케이션을 Singleton 배포로 배포할 수 있습니다. 클러스터된 서버 그룹에 배포하면 Singleton 배포는 지정된 시간에 단일 노드에만 배포됩니다. 배포가 활성 상태인 노드가 중지되거나 실패하면 다른 노드에서 배포가 자동으로 시작됩니다.

다음과 같은 상황에서 Singleton 배포를 여러 노드에 배포할 수 있습니다.

  • 지정된 노드의 클러스터된 서버 그룹은 구성 문제나 네트워크 문제로 인해 연결을 설정할 수 없습니다.
  • 다음 구성 파일과 같이 HA가 아닌 구성이 사용됩니다.

    • Jakarta EE 8 Web Profile 또는 standalone -full.xml 구성을 지원하는 standalone.xml 구성으로 Jakarta EE 8 Full Platform 프로파일을 지원합니다.
    • domain.xml 구성 - 기본 도메인 프로필 또는 전체 도메인 프로필로 구성됩니다.
중요

비 HA 구성에는 기본적으로 Singleton 하위 시스템이 활성화되어 있지 않습니다. 이 기본 구성을 사용하는 경우 애플리케이션의 성공적인 배포를 촉진하기 위해 Singleton-deployment.xml 파일이 무시됩니다.

그러나 비HA 구성을 사용하면 jboss-all.xml 설명자 파일에 오류가 발생할 수 있습니다. 이러한 오류를 방지하려면 Singleton-deployment.xml 설명자에 단일 배포를 추가합니다. 그런 다음 모든 프로필 유형을 사용하여 애플리케이션을 배포할 수 있습니다.

HA Singleton 동작 제어 정책은 새 Singleton 하위 시스템에서 관리합니다. 배포는 특정 Singleton 정책을 지정하거나 기본 하위 시스템 정책을 사용할 수 있습니다.

배포는 기존 배포에 배포 오버레이로 적용되는 META-INF/singleton-deployment.xml 배포 설명자를 사용하여 Singleton 배포로 식별합니다. 또는 기존의 jboss-all.xml 파일에 필요한 Singleton 구성을 포함할 수 있습니다.

Singleton 배포 정의 또는 선택

배포를 Singleton 배포로 정의하려면 애플리케이션 아카이브에 META-INF/singleton-deployment.xml 설명자를 포함합니다.

Maven WAR 플러그인이 이미 있는 경우 플러그인을 META-INF 디렉토리: **/src/main/webapp/META- INF 로 마이그레이션할 수 있습니다.

절차

  • 애플리케이션이 EAR 파일에 배포된 경우 jboss -all.xml 파일에 있는 singleton-deployment.xml 설명자 또는 singleton- deployment 요소를 META-INF 디렉터리의 최상위 레벨로 이동합니다.

    예제: Singleton 배포 설명자

    <?xml version="1.0" encoding="UTF-8"?>
    <singleton-deployment xmlns="urn:jboss:singleton-deployment:1.0"/>
    Copy to Clipboard Toggle word wrap

  • 애플리케이션 배포를 WAR 파일 또는 JAR 파일로 추가하려면 singleton-deployment.xml 설명자를 애플리케이션 아카이브의 /META-INF 디렉터리의 최상위 레벨로 이동합니다.

    예제: 특정 Singleton 정책이 있는 Singleton 배포 설명자

    <?xml version="1.0" encoding="UTF-8"?>
    <singleton-deployment policy="my-new-policy" xmlns="urn:jboss:singleton-deployment:1.0"/>
    Copy to Clipboard Toggle word wrap

  • 선택 사항: jboss -all.xml 파일에서 singleton- deployment 을 정의하려면 jboss-all.xml 설명자를 애플리케이션 아카이브의 /META-INF 디렉터리의 최상위 레벨로 이동합니다.

    예제: jboss -all.xml에서 singleton- deployment정의

    <?xml version="1.0" encoding="UTF-8"?>
    <jboss xmlns="urn:jboss:1.0">
        <singleton-deployment xmlns="urn:jboss:singleton-deployment:1.0"/>
    </jboss>
    Copy to Clipboard Toggle word wrap

  • 선택 사항: singleton 정책을 사용하여 jboss -all.xml 파일에서 singleton- deployment 을 정의합니다. jboss-all.xml 설명자를 애플리케이션 아카이브의 /META-INF 디렉터리의 최상위 레벨로 이동합니다.

    예제: 특정 Singleton 정책을 사용하여 jboss-all.xml 에 Singleton-deployment 정의

    <?xml version="1.0" encoding="UTF-8"?>
    <jboss xmlns="urn:jboss:1.0">
        <singleton-deployment policy="my-new-policy" xmlns="urn:jboss:singleton-deployment:1.0"/>
    </jboss>
    Copy to Clipboard Toggle word wrap

Singleton 배포 생성

JBoss EAP는 다음 두 가지 선택 정책을 제공합니다.

  • 단순 선택 정책

    simple-election-policy 는 지정된 애플리케이션이 배포될 position 특성으로 표시된 특정 멤버를 선택합니다. position 속성은 사용 기간이 내림차순으로 정렬된 후보 목록에서 선택할 노드의 인덱스를 결정합니다. 여기서 0 은 가장 오래된 노드를 나타내고, -1 은 가장 오래된 노드를 나타내고, -2 는 가장 오래된 노드를 나타냅니다. 지정된 위치가 후보 수를 초과하는 경우 모듈러스 작업이 적용됩니다.

    예제: 관리 CLI를 사용하여 간단한election-policy 및 위치가 -1 로 설정된 새 Singleton 정책 생성

    batch
    /subsystem=singleton/singleton-policy=my-new-policy:add(cache-container=server)
    /subsystem=singleton/singleton-policy=my-new-policy/election-
    policy=simple:add(position=-1)
    run-batch
    Copy to Clipboard Toggle word wrap

    참고

    새로 생성된 정책 my-new-policy 를 기본값으로 설정하려면 다음 명령을 실행합니다.

    /subsystem=singleton:write-attribute(name=default, value=my-new-policy)
    Copy to Clipboard Toggle word wrap

    예제: standalone -ha.xml을 사용하여 위치가 -1 로 설정된 simple-election- policy구성

    <subsystem xmlns="urn:jboss:domain:singleton:1.0">
       <singleton-policies default="my-new-policy">
          <singleton-policy name="my-new-policy" cache-container="server">
             <simple-election-policy position="-1"/>
          </singleton-policy>
       </singleton-policies>
    </subsystem>
    Copy to Clipboard Toggle word wrap

  • 임의 선택 정책

    random-election-policy 는 지정된 애플리케이션이 배포될 임의 멤버를 선택합니다.

    예제: random-election-policy 를 사용하여 새 Singleton 정책 생성, 관리 CLI 사용

    batch
    /subsystem=singleton/singleton-policy=my-other-new-policy:add(cache-container=server)
    /subsystem=singleton/singleton-policy=my-other-new-policy/election-policy=random:add()
    run-batch
    Copy to Clipboard Toggle word wrap

    예제: standalone -ha.xml을 사용하여 random-election- policy구성

    <subsystem xmlns="urn:jboss:domain:singleton:1.0">
       <singleton-policies default="my-other-new-policy">
          <singleton-policy name="my-other-new-policy" cache-container="server">
             <random-election-policy/>
          </singleton-policy>
       </singleton-policies>
    </subsystem>
    Copy to Clipboard Toggle word wrap

    참고

    cache -container의 default- cache 특성은 정책을 추가하기 전에 정의해야 합니다. 이렇게 하지 않으면 사용자 정의 캐시 컨테이너를 사용하는 경우 오류 메시지가 표시될 수 있습니다.

환경 설정

또한 Singleton 선택 정책은 클러스터의 하나 이상의 구성원에 대한 기본 설정을 나타낼 수 있습니다. 기본 설정은 노드 이름을 사용하거나 아웃바운드 소켓 바인딩 이름을 사용하여 정의할 수 있습니다. 노드 기본 설정은 항상 선택 정책 결과에 우선합니다.

예제: 관리 CLI를 사용하여 기존 Singleton 정책의 기본 설정 표시

/subsystem=singleton/singleton-policy=foo/election-policy=simple:list-add(name=name-preferences, value=nodeA)

/subsystem=singleton/singleton-policy=bar/election-policy=random:list-add(name=socket-binding-preferences, value=binding1)
Copy to Clipboard Toggle word wrap

예제: 관리 CLI를 사용하여 단순election-policy 및 name- preferences 를 사용하여 새 Singleton 정책 생성

batch
/subsystem=singleton/singleton-policy=my-new-policy:add(cache-container=server)
/subsystem=singleton/singleton-policy=my-new-policy/election-policy=simple:add(name-preferences=[node1, node2, node3, node4])
run-batch
Copy to Clipboard Toggle word wrap

참고

새로 생성된 정책 my-new-policy 를 기본값으로 설정하려면 다음 명령을 실행합니다.

/subsystem=singleton:write-attribute(name=default, value=my-new-policy)
Copy to Clipboard Toggle word wrap

예제: standalone -ha.xml을 사용하여 socket-binding-preferences 를 사용하여 random- election-policy구성

<subsystem xmlns="urn:jboss:domain:singleton:1.0">
   <singleton-policies default="my-other-new-policy">
      <singleton-policy name="my-other-new-policy" cache-container="server">
         <random-election-policy>
            <socket-binding-preferences>binding1 binding2 binding3 binding4</socket-binding-preferences>
         </random-election-policy>
      </singleton-policy>
   </singleton-policies>
</subsystem>
Copy to Clipboard Toggle word wrap

쿼럼 정의

네트워크 파티션은 동일한 배포에 대해 여러 Singleton 프로바이더를 트리거하여 동시에 실행될 수 있으므로 Singleton 배포에 특히 문제가 있습니다. 이 시나리오에 대해 보호하기 위해 Singleton 정책은 Singleton 공급자 선택을 수행하기 전에 최소 노드 수가 있어야 하는 쿼럼을 정의할 수 있습니다. 일반적인 배포 시나리오에서는 N/2 + 1의 쿼럼을 사용합니다. 여기서 N은 예상되는 클러스터 크기입니다. 이 값은 런타임 시 업데이트할 수 있으며 해당 Singleton 정책을 사용하여 Singleton 배포에 즉시 영향을 미칩니다.

예제: standalone-ha.xml 파일의 쿼럼 선언

<subsystem xmlns="urn:jboss:domain:singleton:1.0">
   <singleton-policies default="default">
      <singleton-policy name="default" cache-container="server" quorum="4">
         <simple-election-policy/>
      </singleton-policy>
   </singleton-policies>
</subsystem>
Copy to Clipboard Toggle word wrap

예제: 관리 CLI를 사용한 쿼럼 선언

/subsystem=singleton/singleton-policy=foo:write-attribute(name=quorum, value=3)
Copy to Clipboard Toggle word wrap

Singleton 배포를 사용하여 애플리케이션에 패키지된 서비스의 전체 작업 예는 JBoss EAP와 함께 제공되는 ha-singleton-deployment 빠른 시작을 참조하십시오.

CLI를 사용하여 기본 Singleton 서비스 공급자 결정

Singleton 하위 시스템은 특정 Singleton 정책에서 생성된 각 Singleton 배포 또는 서비스에 대한 런타임 리소스를 노출합니다. 이렇게 하면 CLI를 사용하여 기본 Singleton 공급자를 확인하는 데 도움이 됩니다.

Singleton 공급자 역할을 하는 클러스터 구성원의 이름을 볼 수 있습니다. 예를 들면 다음과 같습니다.

/subsystem=singleton/singleton-policy=default/deployment=singleton.jar:read-attribute(name=primary-provider)
{
    "outcome" => "success",
    "result" => "node1"
}
Copy to Clipboard Toggle word wrap

Singleton 배포 또는 서비스가 설치된 노드의 이름을 볼 수도 있습니다. 예를 들면 다음과 같습니다.

/subsystem=singleton/singleton-policy=default/deployment=singleton.jar:read-attribute(name=providers)
{
    "outcome" => "success",
    "result" => [
        "node1",
        "node2"
    ]
}
Copy to Clipboard Toggle word wrap

6.6. Apache mod_cluster-manager 애플리케이션

6.6.1. mod_cluster-manager 애플리케이션 정보

mod_cluster-manager 애플리케이션은 Apache HTTP 서버에서 사용할 수 있는 관리 웹 페이지입니다. 연결된 작업자 노드를 모니터링하고 컨텍스트 활성화 또는 비활성화, 클러스터에서 작업자 노드의 로드 밸런싱 속성을 구성하는 등 다양한 관리 작업을 수행하는 데 사용됩니다.

mod_cluster-manager 애플리케이션 탐색

mod_cluster-manager 애플리케이션은 작업자 노드에서 다양한 관리 작업을 수행하는 데 사용할 수 있습니다.

mod_cluster Administration Web Page 그림 - mod_cluster 관리 웹 페이지

  • [1] mod_cluster/1.3.1.Final: mod_cluster 네이티브 라이브러리의 버전.
  • [2] ajp://192.168.122.204:8099: 사용되는 프로토콜(AJP, HTTP 또는 HTTPS), 작업자 노드의 호스트 이름 또는 IP 주소 및 포트.
  • [3] jboss-eap-7.0-2: 작업자 노드의 JVMRoute.
  • [4] 가상 호스트 1: 작업자 노드에 구성된 가상 호스트입니다.
  • [5] 비활성화: 특정 컨텍스트에서 새 세션 생성을 비활성화하는 데 사용할 수 있는 관리 옵션. 그러나 진행 중인 세션은 비활성화되지 않고 그대로 유지됩니다.
  • [6] 중지: 컨텍스트에 대한 세션 요청의 라우팅을 중지하는 데 사용할 수 있는 관리 옵션입니다. Sticky-session-force 속성을 true 로 설정하지 않는 한 나머지 세션은 다른 노드로 페일오버됩니다.
  • [7] 컨텍스트 비활성화 컨텍스트 중지 컨텍스트 사용 : 전체 노드에서 수행할 수 있는 작업입니다. 이러한 옵션 중 하나를 선택하면 모든 가상 호스트에서 노드의 모든 컨텍스트에 영향을 미칩니다.
  • [8] LBGroup(로드 밸런싱 그룹): load-balancing-group 특성은 JBoss EAP 구성의 modcluster 하위 시스템에서 설정되어 모든 작업자 노드를 사용자 지정 로드 밸런싱 그룹으로 그룹화합니다. LBGroup(로드 밸런싱 그룹)은 모든 세트 부하 분산 그룹에 대한 정보를 제공하는 정보 필드입니다. 이 필드를 설정하지 않으면 모든 작업자 노드가 단일 기본 로드 밸런싱 그룹으로 그룹화됩니다.

    참고

    이는 정보 필드이므로 로드 밸런싱-그룹 속성을 설정하는 데 사용할 수 없습니다. 특성은 JBoss EAP 구성의 modcluster 하위 시스템에서 설정해야 합니다.

  • [9] 로드 (value): 작업자 노드의 부하 요인입니다. 로드 요소는 다음과 같이 평가됩니다.

    -load > 0 : A load factor with value 1 indicates that the worker node is overloaded. A load factor of 100 denotes a free and not-loaded node.
    -load = 0 : A load factor of value 0 indicates that the worker node is in standby mode. This means that no session requests will be routed to this node until and unless the other worker nodes are unavailable.
    -load = -1 : A load factor of value -1 indicates that the worker node is in an error state.
    -load = -2 : A load factor of value -2 indicates that the worker node is undergoing CPing/CPong and is in a transition state.
    Copy to Clipboard Toggle word wrap
참고

JBoss EAP 7.4의 경우 Undertow를 로드 밸런서로 사용할 수도 있습니다.

6.7. 배포 가능한 웹 세션 구성의 distributable-web 하위 시스템

D istributable-web 하위 시스템은 유연하고 배포 가능한 웹 세션 구성을 용이하게 합니다. 하위 시스템은 배포 가능한 웹 세션 관리 프로필 집합을 정의합니다. 이러한 프로필 중 하나는 기본 프로필로 지정됩니다. 배포 가능한 웹 애플리케이션의 기본 동작을 정의합니다. 예를 들면 다음과 같습니다.

[standalone@embedded /] /subsystem=distributable-web:read-attribute(name=default-session-management)
{
    "outcome" => "success",
    "result" => "default"
}
Copy to Clipboard Toggle word wrap

기본 세션 관리는 다음 예제와 같이 Infinispan 캐시 내에 웹 세션 데이터를 저장합니다.

[standalone@embedded /] /subsystem=distributable-web/infinispan-session-management=default:read-resource
{
    "outcome" => "success",
    "result" => {
        "cache" => undefined,
        "cache-container" => "web",
        "granularity" => "SESSION",
        "affinity" => {"primary-owner" => undefined}
    }
}
Copy to Clipboard Toggle word wrap

이 예제에서 사용되는 속성과 가능한 값은 다음과 같습니다.

  • 캐시: 연결된 cache-container 내의 캐시. 웹 애플리케이션의 캐시는 이 캐시의 구성을 기반으로 합니다. 정의되지 않은 경우 연결된 캐시 컨테이너의 기본 캐시가 사용됩니다.
  • cache-container: 세션 데이터가 저장되는 Infinispan 하위 시스템에 정의된 cache-container입니다.
  • 세분화: 세션 관리자가 세션을 개별 캐시 항목에 매핑하는 방법을 정의합니다. 가능한 값은 다음과 같습니다.

    • 세션: 모든 세션 속성을 단일 캐시 항목 내에 저장합니다. ATTRIBUTE 단위보다 비용이 높지만 모든 교차 기여 개체 참조를 유지합니다.
    • 속성: 각 세션 속성을 별도의 캐시 항목 내에 저장합니다. SESSION 단위보다 효율적이지만 교차 기여 개체 참조는 유지하지 않습니다.
  • 유사성: 서버에 대해 웹 요청에 있어야 하는 선호도를 정의합니다. 관련 웹 세션의 선호도는 세션 ID에 추가할 경로를 생성하는 알고리즘을 결정합니다. 가능한 값은 다음과 같습니다.

    • affinity=none: 웹 요청에는 노드에 대한 선호도가 없습니다. 웹 세션 상태가 애플리케이션 서버 내에서 유지 관리되지 않는 경우 이 기능을 사용합니다.
    • affinity=local: 웹 요청에는 세션 요청을 마지막으로 처리한 서버와의 선호도가 있습니다. 이 옵션은 고정 세션 동작에 해당합니다.
    • affinity=primary-owner: 웹 요청에는 세션의 기본 소유자에 대한 선호도가 있습니다. 이는 이 분산 세션 관리자의 기본 선호도입니다. 백업 캐시가 분산되거나 복제되지 않은 경우 affinity=local 과 동일하게 작동합니다.
    • affinity=ranked: 웹 요청에는 기본 및 백업 소유자가 포함된 목록에서 사용 가능한 첫 번째 멤버와 마지막으로 세션을 처리하는 멤버에 대한 선호도가 있습니다.
    • affinity=ranked delimiter: 인코딩된 세션 식별자 내에서 개별 경로를 구분하는 데 사용되는 구분 기호입니다.
    • affinity=ranked max routes: 세션 식별자로 인코딩할 최대 경로 수입니다.

여러 순서로 정렬된 경로와 세션 선호도가 있으려면 로드 밸런서에서 순위 세션 선호도를 활성화해야 합니다. 자세한 내용은 JBoss EAP 구성 가이드에서 부하 분산에서 순위가 지정된 세션 선호도 활성화 를 참조하십시오.

이름별로 세션 관리 프로필을 참조하거나 배포별 세션 관리 구성을 제공하여 기본 배포 가능한 세션 관리 동작을 재정의할 수 있습니다. 자세한 내용은 Overide Default Distributable Session Management Behavior 를 참조하십시오.

6.7.1. 원격 Red Hat Data Grid에 웹 세션 데이터 저장

D istributable-web 하위 시스템은 HotRod 프로토콜을 사용하여 원격 Red Hat Data Grid 클러스터에 웹 세션 데이터를 저장하도록 구성할 수 있습니다. 원격 클러스터에 웹 세션 데이터를 저장하면 캐시 계층이 애플리케이션 서버와 독립적으로 확장할 수 있습니다.

설정 예:

[standalone@embedded /]/subsystem=distributable-web/hotrod-session-management=ExampleRemoteSessionStore:add(remote-cache-container=datagrid, cache-configuration=__REMOTE_CACHE_CONFIG_NAME__, granularity=ATTRIBUTE)
{
    "outcome" => "success"
}
Copy to Clipboard Toggle word wrap

이 예제에서 사용되는 속성과 가능한 값은 다음과 같습니다.

  • remote-cache-container: 웹 세션 데이터를 저장하기 위해 Infinispan 하위 시스템에 정의된 원격 캐시 컨테이너입니다.
  • cache-configuration: Red Hat Data Grid 클러스터의 캐시 구성 이름입니다. 새로 생성된 배포별 캐시는 이 구성을 기반으로 합니다.

    이름과 일치하는 원격 캐시 구성이 없으면 원격 컨테이너에 새 캐시 구성이 생성됩니다.

  • 세분화: 세션 관리자가 세션을 개별 캐시 항목에 매핑하는 방법을 정의합니다. 가능한 값은 다음과 같습니다.

    • 세션: 모든 세션 속성을 단일 캐시 항목 내에 저장합니다. ATTRIBUTE 단위보다 비용이 높지만 모든 교차 기여 개체 참조를 유지합니다.
    • 속성: 각 세션 속성을 별도의 캐시 항목 내에 저장합니다. SESSION 단위보다 효율적이지만 교차 기여 개체 참조는 유지하지 않습니다.

7장. 자카르타 컨텍스트 및 종속성 주입

7.1. 자카르타 컨텍스트 및 종속성 주입 소개

7.1.1. 자카르타 컨텍스트 및 종속성 주입 정보

Jakarta Contexts and Dependency Injection 2.0은 Jakarta Enterprise Beans 3 구성 요소를 Jakarta Server Faces 관리 빈으로 사용할 수 있도록 설계된 사양입니다. 자카르타 컨텍스트 및 종속성 주입은 두 가지 구성 요소 모델을 통합하고 Java의 웹 기반 애플리케이션에 대한 프로그래밍 모델을 상당히 단순화할 수 있도록 합니다. Jakarta Contexts and Dependency Injection 2.0에 대한 자세한 내용은 Jakarta Contexts and Dependency Injection 2.0 사양에서 확인할 수 있습니다.

JBoss EAP에는 자카르타 컨텍스트 및 종속성 주입 2.0 호환 사양인 Weld가 포함되어 있습니다.

참고

weld 는 자카르타 EE 플랫폼에 대한 자카르타 컨텍스트 및 종속성 주입의 호환 구현입니다. Jakarta Contexts and Dependency Injection은 종속성 주입 및 컨텍스트 라이프사이클 관리를 위한 자카르타 EE 표준입니다. 또한 Jakarta Contexts and Dependency Injection은 Jakarta EE에서 가장 중요한 부분 중 하나입니다.

자카르타 컨텍스트 및 종속성 주입의 이점

Jakarta Contexts and Dependency Injection의 이점은 다음과 같습니다.

  • 큰 코드 청크를 주석으로 교체하여 코드 기반 단순화 및 축소.
  • 유연성을 통해 주입 및 이벤트를 비활성화 및 활성화하고 대체 빈을 사용하며 비컨텍스트 및 종속성 주입 오브젝트를 쉽게 주입할 수 있습니다.
  • 선택적으로, 기본값과 다르게 구성을 사용자 지정해야 하는 경우 META-INF/ 또는 WEB-INF/ 디렉터리에 bean.xml 파일을 포함할 수 있습니다. 파일은 비워 둘 수 있습니다.
  • 패키징 및 배포를 단순화하고 배포에 추가해야 하는 XML의 양을 줄입니다.
  • 컨텍스트를 통해 라이프사이클 관리 제공. 요청, 세션, 대화 또는 사용자 지정 컨텍스트에 삽입을 연결할 수 있습니다.
  • 안전한 타입 종속성 주입을 제공하여 문자열 기반 주입보다 더 안전하고 디버깅하기 쉽습니다.
  • 빈에서 인터셉터 분리.
  • 복잡한 이벤트 알림 제공.

Jakarta Contexts and Dependency Injection을 사용하면 애플리케이션 개발, 코드 재사용, 배포 또는 런타임 시 코드 조정, 장치 테스트 등의 상당한 유연성을 확보할 수 있습니다.

애플리케이션 개발을 위한 특수 모드가 함께 제공됩니다. 활성화된 경우 Jakarta Contexts 및 Dependency Injection 애플리케이션의 개발을 용이하게 하는 특정 기본 제공 툴을 사용할 수 있습니다.

참고

개발 모드는 애플리케이션 성능에 부정적인 영향을 줄 수 있으므로 프로덕션에서 사용해서는 안 됩니다. 프로덕션에 배포하기 전에 개발 모드를 비활성화해야 합니다.

웹 애플리케이션의 개발 모드 활성화:

웹 애플리케이션의 경우 서블릿 초기화 매개 변수 org.jboss.firmd.developmenttrue로 설정합니다.

<web-app>
    <context-param>
        <param-name>org.jboss.weld.development</param-name>
        <param-value>true</param-value>
    </context-param>
</web-app>
Copy to Clipboard Toggle word wrap

관리 CLI를 사용하여 JBoss EAP에 대한 개발 모드 활성화:

development -mode 특성을 true 로 설정하여 배포된 모든 애플리케이션에 대해 Weld 개발 모드를 전역적으로 활성화할 수 있습니다.

/subsystem=weld:write-attribute(name=development-mode,value=true)
Copy to Clipboard Toggle word wrap

7.2.1. 기본 빈 검색 모드

빈 아카이브의 기본 빈 검색 모드는 주석이 추가됩니다. 이러한 빈 아카이브는 암시적 빈 아카이브 라고 합니다.

빈 검색 모드에 주석이 추가되면 다음을 수행합니다.

  • 주석 정의가 없고 세션 빈 의 빈 클래스가 아닌 빈 클래스는 검색되지 않습니다.
  • 세션 빈에 없고 빈 클래스에 빈 정의 주석이 없는 생산자 메서드는 검색되지 않습니다.
  • 세션 빈에 없고 빈 클래스에 빈 정의 주석이 없는 생산자 필드가 검색되지 않습니다.
  • 세션 빈에 없고 빈 클래스에 빈 정의 주석이 없는 Disposer 메서드는 검색되지 않습니다.
  • 세션 빈에 없고 빈 클래스에 빈 정의 주석이 없는 관찰자 메서드는 검색되지 않습니다.
중요

Contexts 및 Dependency Injection 섹션의 모든 예제는 검색 모드가 all 으로 설정된 경우에만 유효합니다.

주석 정의 빈

빈 클래스에는 빈을 정의하여 빈 아카이브에 정의된 대로 애플리케이션의 모든 위치에 배치할 수 있습니다. 주석을 정의하는 빈 클래스는 암시적 빈 빈이라고 합니다.

주석을 정의하는 빈 세트에는 다음이 포함됩니다.

  • @ApplicationScoped,@SessionScoped,@ConversationScoped@RequestScoped 주석.
  • 기타 모든 일반 범위 유형.
  • @interceptor@Decorator 주석.
  • 모든 주석, 즉 @Stereotype으로 주석이 달립니다.
  • @Dependent 범위 주석입니다.

이러한 주석 중 하나가 빈 클래스에 선언되면 빈 클래스에 빈이 주석이 있다고 합니다.

예제: 빈에서 주석 정의

@Dependent
public class BookShop
        extends Business
        implements Shop<Book> {
    ...
}
Copy to Clipboard Toggle word wrap

참고

다른 JSR-330 구현 및 Jakarta Contexts 및 Dependency Injection 사양과의 호환성을 보장하기 위해 @Dependent 를 제외한 모든 의사 범위 주석은 주석을 정의하는 빈이 아닙니다. 그러나 pseudo-scope 주석을 포함한 parenttype 주석은 주석을 정의하는 빈입니다.

7.2.2. 검사 프로세스에서 빈 제외

제외 필터는 bean 아카이브의 <exclude> 요소에서 <scan> 요소의 하위 항목으로 정의합니다. 기본적으로 제외 필터는 활성 상태입니다. 제외 필터는 해당 정의에 다음이 포함된 경우 비활성 상태가 됩니다.

  • name 속성이 있는 <if-class-available> 이라는 하위 요소와 빈 아카이브의 클래스 로더는 해당 이름의 클래스를 로드할 수 없습니다.
  • name 속성이 있는 <if-class-not-available> 이라는 하위 요소와 빈 아카이브의 클래스 로더는 해당 이름의 클래스를 로드할 수 있습니다.
  • name 속성이 있는 <if-system-property> 라는 하위 요소와 해당 이름에 대해 정의된 시스템 속성이 없습니다.
  • name 특성과 value 속성이 있는 <if-system-property> 라는 하위 요소와 해당 값이 있는 해당 이름에 대해 정의된 시스템 속성이 없습니다.

유형은 검색에서 제외되고 필터가 활성 상태인 경우 다음을 제외합니다.

  • 검색 중인 유형의 정규화된 이름은 exclude 필터의 name 속성 값과 일치합니다.
  • 검색 중인 유형의 패키지 이름은 exclude 필터의 접미사 ".*"가 포함된 name 속성의 값과 일치합니다.
  • 검색 중인 유형의 패키지 이름은 exclude 필터의 접미사 ".**"가 있는 name 속성의 값으로 시작합니다.

예 7.1. 예: beans.xml 파일

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee">

    <scan>
        <exclude name="com.acme.rest.*" /> 
1


        <exclude name="com.acme.faces.**"> 
2

            <if-class-not-available name="javax.faces.context.FacesContext"/>
        </exclude>

        <exclude name="com.acme.verbose.*"> 
3

            <if-system-property name="verbosity" value="low"/>
        </exclude>

        <exclude name="com.acme.ejb.**"> 
4

            <if-class-available name="javax.enterprise.inject.Model"/>
            <if-system-property name="exclude-ejbs"/>
        </exclude>
    </scan>

</beans>
Copy to Clipboard Toggle word wrap
1
첫 번째 제외 필터는 com.acme.rest 패키지의 모든 클래스를 제외합니다.
2
두 번째 제외 필터는 com.acme.faces 패키지의 모든 클래스와 하위 패키지를 제외하지만 Jakarta Server Faces를 사용할 수 없는 경우에만 가능합니다.
3
세 번째 제외 필터는 시스템 속성 세부 정보 표시 값이 으면 com.acme.verbose 패키지의 모든 클래스를 제외합니다.
4
네 번째 제외 필터는 com.acme.ejb 패키지의 모든 클래스를 제외하며, 시스템 속성 exclude-ejbs 가 임의의 값으로 설정되어 있고 동시에 javax.enterprise.inject.Model 클래스를 classloader에서 사용할 수 있는 경우 모든 하위 패키지가 제외됩니다.
참고

Jakarta EE 구성 요소에 @Vetoed 를 추가하여 빈으로 간주되는 것을 방지하는 것이 안전합니다. @Vetoed로 주석이 추가된 모든 유형 또는 @Vetoed 로 주석이 추가된 패키지에 대해 이벤트가 실행되지 않습니다 . 자세한 내용은 @Vetoed를 참조하십시오.

7.2.3. 삽입을 사용하여 구현 확장

삽입을 사용하여 기존 코드의 기능을 추가하거나 변경할 수 있습니다.

다음 예제에서는 기존 클래스에 변환 기능을 추가하고 이미 startup 클래스가 있다고 가정합니다. 이 클래스에buildPhrase 메서드가 있습니다. buildPhrase 메서드는 도시 이름을 인수로 사용하여 "Welcome to Boston!"과 같은 구문을 출력합니다.

이 예제에서는 가상 개체를 Welcome 클래스에 주입합니다. 자카르타 엔터프라이즈 빈 상태 비저장 빈 또는 다른 유형의 빈이 될 있으며 한 언어에서 다른 언어로 문장을 변환할 수 있습니다. 이 경우 원래 Welcome 클래스를 수정하지 않고 전체 인사말을 변환하는 데 사용됩니다. building buildPhrase 메서드를 호출하기 전에 주입됩니다.

예제: Welcome 클래스에 정상적인 빈을 주입합니다.

public class TranslatingWelcome extends Welcome {

    @Inject Translator translator;

    public String buildPhrase(String city) {
        return translator.translate("Welcome to " + city + "!");
    }
    ...
}
Copy to Clipboard Toggle word wrap

7.3. 모호하거나 불만족스러운 종속성

모호한 종속성은 컨테이너가 정확히 하나의 빈에 주입을 확인할 수 없는 경우 존재합니다.

컨테이너에서 빈에 대한 주입을 확인할 수 없는 경우 불만족한 종속성이 있습니다.

컨테이너는 종속성을 해결하기 위해 다음 단계를 수행합니다.

  1. 주입 지점의 빈 유형을 구현하는 모든 빈의 한정자 주석을 확인합니다.
  2. 비활성화된 빈을 필터링합니다. 비활성화된 빈은 명시적으로 활성화되지 않은 @Alternative 빈입니다.

모호한 종속성 또는 불만족스러운 종속성이 있는 경우 컨테이너는 배포를 중단하고 예외가 발생합니다.

모호한 종속성을 수정하려면 Qualifier를 사용하여 모호한 주입 해결을 참조하십시오.

7.3.1. 한정자

한정자는 컨테이너가 주입 지점에 맞는 여러 빈을 확인할 수 있는 경우 모호한 종속성을 방지하는 데 사용되는 주석입니다. 주입 지점에 선언된 한정자는 동일한 한정자를 선언하는 적격 빈 세트를 제공합니다.

한정자는 아래 예와 같이 보존 및 대상을 사용하여 선언해야 합니다.

예제: @Synchronous 및 @ Asynchronous 한정자를 정의합니다.

@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface Synchronous {}
Copy to Clipboard Toggle word wrap

@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface Asynchronous {}
Copy to Clipboard Toggle word wrap

예제: @Synchronous@Asynchronous 한정자 사용

@Synchronous
public class SynchronousPaymentProcessor implements PaymentProcessor {
   public void process(Payment payment) { ... }
}
Copy to Clipboard Toggle word wrap

@Asynchronous
public class AsynchronousPaymentProcessor implements PaymentProcessor {
   public void process(Payment payment) { ... }
}
Copy to Clipboard Toggle word wrap
'@Any'

빈 또는 주입 지점에서 한정자를 명시적으로 선언하지 않을 때마다 컨테이너에서 한정자 @Default 를 가정합니다. 한정자를 지정하지 않고 주입 지점을 선언해야 하는 경우도 있습니다. 이에 대한 한정자가 있습니다. 모든 빈에는 한정자 @Any 가 있습니다. 따라서 주입 지점에 @Any 를 명시적으로 지정하여 주입할 수 있는 빈을 제한하지 않고 기본 한정자를 억제합니다.

이 기능은 특정 빈 유형의 모든 빈을 반복하려는 경우 특히 유용합니다.

import javax.enterprise.inject.Instance;
...

@Inject

void initServices(@Any Instance<Service> services) {

   for (Service service: services) {

      service.init();

   }

}
Copy to Clipboard Toggle word wrap

모든 빈에는 이 한정자를 명시적으로 선언하지 않더라도 한정자 @Any 가 있습니다.

또한 모든 이벤트에는 이 한정자를 명시적으로 선언하지 않고 제기된 한정자 @Any 가 있습니다.

@Inject @Any Event<User> anyUserEvent;
Copy to Clipboard Toggle word wrap

@Any 한정자를 사용하면 주입 지점에서 모든 빈 또는 특정 빈 유형의 모든 이벤트를 참조할 수 있습니다.

@Inject @Delegate @Any Logger logger;
Copy to Clipboard Toggle word wrap

7.3.2. 한정자를 사용하여 모호한 주입 해결

한정자를 사용하여 모호한 주입을 해결할 수 있습니다. 모호한 또는 불만족스러운 종속성에서 모호한 주입에 대해 자세히 알아보십시오.

다음 예제는 모호한 예이며 두 개의 Welcome 구현이 있습니다. 하나는 변환되고 그렇지 않은 것입니다. Welcome(환영)을 사용하려면 삽입을 지정해야 합니다.

예제: 모호한 주입

public class Greeter {
  private Welcome welcome;

  @Inject
  void init(Welcome welcome) {
    this.welcome = welcome;
  }
  ...
}
Copy to Clipboard Toggle word wrap

한정자를 사용하여 모호한 주입 해결
  1. 모호한 주입을 해결하려면 @Translating:

    @Qualifier
    @Retention(RUNTIME)
    @Target({TYPE,METHOD,FIELD,PARAMETERS})
    public @interface Translating{}
    Copy to Clipboard Toggle word wrap
  2. @Translating 주석을 사용하여 Translation Welcome 에 주석을 답니다.

    @Translating
    public class TranslatingWelcome extends Welcome {
        @Inject Translator translator;
        public String buildPhrase(String city) {
            return translator.translate("Welcome to " + city + "!");
        }
        ...
    }
    Copy to Clipboard Toggle word wrap
  3. 삽입에 환영을 요청하십시오. 팩토리 방법 패턴과 유사하게 정규화된 구현을 명시적으로 요청해야 합니다. 주입 지점에서 모호성이 해결됩니다.

    public class Greeter {
      private Welcome welcome;
      @Inject
      void init(@Translating Welcome welcome) {
        this.welcome = welcome;
      }
      public void welcomeVisitors() {
        System.out.println(welcome.buildPhrase("San Francisco"));
      }
    }
    Copy to Clipboard Toggle word wrap

7.4. 관리 빈

Jakarta EE는 Jakarta Managed Beans 사양에 공통 정의를 설정합니다. Jakarta EE의 경우 관리 빈은 최소한의 프로그래밍 제한으로 컨테이너 관리 개체로 정의됩니다. 그렇지 않으면 약어 POJO(Plain Old Java Object)에서 알 수 있습니다. 리소스 주입, 라이프사이클 콜백 및 인터셉터와 같은 소규모 기본 서비스 세트를 지원합니다. Jakarta Enterprise Beans 및 Jakarta Contexts and Dependency Injection과 같은 병행 사양은 이 기본 모델을 기반으로 합니다.

단, 매개 변수가 없는 생성자가 있는 거의 모든 구체적인 Java 클래스 또는 주석 @Inject 로 지정된 생성자가 빈입니다. 여기에는 모든 JavaBean과 모든 Jakarta Enterprise Beans 세션 빈이 포함됩니다.

7.4.1. 빈인 클래스 유형

관리되는 빈은 Java 클래스입니다. Jakarta EE의 경우 관리되는 빈의 기본 라이프사이클 및 의미 체계는 Jakarta Managed Beans 1.0 사양에 의해 정의됩니다. 빈 클래스 @ManagedBean 에 주석을 달아 관리되는 빈을 명시적으로 선언할 수 있지만, 컨텍스트 및 종속성 주입에서는 필요하지 않습니다. 사양에 따라 Contexts 및 Dependency Injection 컨테이너는 다음 조건을 관리되는 빈으로 충족하는 모든 클래스를 처리합니다.

  • 정적인 내부 클래스가 아닙니다.
  • 구체적인 클래스이거나 @Decorator로 주석이 추가됩니다.
  • Jakarta Enterprise Beans 구성 요소 정의 주석이나 ejb-jar.xml 파일에서 Jakarta Enterprise Beans bean 클래스로 선언되지 않습니다.
  • javax.enterprise.inject.spi.Extension 인터페이스를 구현하지 않습니다.
  • 매개 변수가 없는 생성자 또는 @Inject 로 주석이 있는 생성자가 있습니다.
  • @Vetoed 또는 @Vetoed 로 주석이 추가된 패키지에 주석이 추가되지 않습니다.

관리 빈 유형의 무제한 빈 세트에는 빈 클래스, 모든 슈퍼 클래스 및 직접 또는 간접적으로 구현하는 모든 인터페이스가 포함되어 있습니다.

관리 빈에 공용 필드가 있는 경우 기본 범위 @Dependent 가 있어야 합니다.

@Vetoed

이 클래스에서 정의한 빈 또는 관찰자 방법이 설치되지 않도록 클래스를veto 처리할 수 있습니다.

@Vetoed
public class SimpleGreeting implements Greeting {
    ...
}
Copy to Clipboard Toggle word wrap

이 코드에서 SimpleGreeting 빈은 주입을 위해 고려되지 않습니다.

패키지의 모든 빈은 주입되지 않도록 할 수 있습니다.

@Vetoed
package org.sample.beans;

import javax.enterprise.inject.Vetoed;
Copy to Clipboard Toggle word wrap

org.sample .beans 패키지의 package-info. java 에 있는 이 코드는 이 패키지 내의 모든 빈이 삽입되지 않도록 합니다.

상태 비저장 Jakarta Enterprise Beans 또는 Jakarta RESTful Web Services 리소스 엔드포인트와 같은 자카르타 EE 구성 요소는 @Vetoed 로 표시되어 빈으로 간주되지 않도록 할 수 있습니다. @Vetoed 주석을 모든 영구 엔터티에 추가하면 BeanManager 가 엔터티를 Jakarta Contexts 및 Dependency Injection Bean으로 관리할 수 없습니다. 엔터티에 @Vetoed 주석이 추가되면 주입이 수행되지 않습니다. 이를 뒷받침하는 이유는 BeanManager 가 Jakarta Persistence 공급자가 중단될 수 있는 작업을 수행하지 못하도록 하기 때문입니다.

애플리케이션에서 컨텍스트 및 종속성 주입 구성 요소가 탐지되면 컨텍스트 및 종속성 주입 구성 요소가 자동으로 활성화됩니다. 구성을 기본값과 다르게 사용자 지정하려면 배포 아카이브에 META-INF/beans.xml 파일 또는 WEB-INF/beans.xml 파일을 포함할 수 있습니다.

다른 오브젝트에 오브젝트 삽입
  1. 클래스 인스턴스를 가져오려면 빈 내에서 @Inject 로 필드에 주석을 추가합니다.

    public class TranslateController {
       @Inject TextTranslator textTranslator;
       ...
    Copy to Clipboard Toggle word wrap
  2. 삽입된 오브젝트의 메서드를 직접 사용합니다. TextTranslator변환 방법이 있다고 가정합니다.

    // in TranslateController class
    
    public void translate() {
       translation = textTranslator.translate(inputText);
    }
    Copy to Clipboard Toggle word wrap
  3. 빈 생성자에 주입을 사용합니다. 다음과 같이 팩토리 또는 서비스 검색 도구를 사용하는 대신 빈 생성자에 오브젝트를 삽입하여 생성할 수 있습니다.

    public class TextTranslator {
    
       private SentenceParser sentenceParser;
       private Translator sentenceTranslator;
    
       @Inject
       TextTranslator(SentenceParser sentenceParser, Translator sentenceTranslator) {
          this.sentenceParser = sentenceParser;
          this.sentenceTranslator = sentenceTranslator;
       }
    
       // Methods of the TextTranslator class
       ...
    }
    Copy to Clipboard Toggle word wrap
  4. Instance(<T>) 인터페이스를 사용하여 프로그래밍 방식으로 인스턴스를 가져옵니다. 빈 유형으로 매개 변수를 지정하면 인스턴스 인터페이스에서 TextTranslator 의 인스턴스를 반환할 수 있습니다.

    @Inject Instance<TextTranslator> textTranslatorInstance;
    ...
    public void translate() {
       textTranslatorInstance.get().translate(inputText);
    }
    Copy to Clipboard Toggle word wrap

빈에 오브젝트를 삽입하면 빈에서 모든 오브젝트 메서드 및 속성을 사용할 수 있습니다. 주입이 이미 존재하는 인스턴스를 참조하지 않는 한 빈의 생성자에 주입하는 경우 빈의 생성자를 호출할 때 주입된 오브젝트의 인스턴스가 생성됩니다. 예를 들어 세션 수명 동안 세션 범위 빈을 삽입하면 새 인스턴스가 생성되지 않습니다.

7.5. 컨텍스트 및 범위

컨텍스트(Contexts and Dependency Injection)는 특정 범위와 연결된 빈 인스턴스를 보유하는 스토리지 영역입니다.

범위는 빈과 컨텍스트 간의 링크입니다. 범위/컨텍스트 조합은 특정 라이프사이클을 가질 수 있습니다. 몇 가지 사전 정의된 범위가 존재하며 고유한 범위를 만들 수 있습니다. 미리 정의된 범위의 예로는 @RequestScoped,@SessionScoped, @ConversationScope 가 있습니다.

Expand
표 7.1. 사용 가능한 범위
범위설명

@Depend

빈은 참조를 포함하는 빈의 라이프사이클에 바인딩됩니다. 주입된 빈의 기본 범위는 @Dependent 입니다.

@ApplicationScoped

빈은 애플리케이션의 라이프사이클에 바인딩됩니다.

@RequestScoped

빈은 요청의 라이프사이클에 바인딩됩니다.

@SessionScoped

빈은 세션의 라이프사이클에 바인딩됩니다.

@ConversationScoped

빈은 대화의 라이프사이클에 바인딩됩니다. 대화 범위는 요청과 세션 길이 사이의이며 애플리케이션에 의해 제어됩니다.

사용자 지정 범위

위의 컨텍스트가 요구 사항을 충족하지 않으면 사용자 지정 범위를 정의할 수 있습니다.

7.6. 명명된 빈

@Named 주석을 사용하여 빈의 이름을 지정할 수 있습니다. 빈을 지정하면 Jakarta Server Faces 및 Jakarta Expression Language에서 직접 사용할 수 있습니다.

@Named 주석은 빈 이름인 선택적 매개 변수를 사용합니다. 이 매개 변수가 생략된 경우 빈 이름은 기본적으로 빈의 클래스 이름으로, 첫 번째 문자가 소문자로 변환됩니다.

7.6.1. 이름이 지정된 빈 사용

@Named 주석을 사용하여 빈 이름 구성
  1. @Named 주석을 사용하여 빈에 이름을 할당합니다.

    @Named("greeter")
    public class GreeterBean {
      private Welcome welcome;
    
      @Inject
      void init (Welcome welcome) {
        this.welcome = welcome;
      }
    
      public void welcomeVisitors() {
        System.out.println(welcome.buildPhrase("San Francisco"));
      }
    }
    Copy to Clipboard Toggle word wrap

    위의 예에서 이름이 지정되지 않은 경우 기본 이름은 be greeterBean 입니다.

  2. Jakarta Server Faces 뷰에서 명명된 빈을 사용합니다.

    <h:form>
      <h:commandButton value="Welcome visitors" action="#{greeter.welcomeVisitors}"/>
    </h:form>
    Copy to Clipboard Toggle word wrap

7.7. 빈 라이프 사이클

이 작업은 요청 수명 동안 빈을 저장하는 방법을 보여줍니다.

주입된 빈의 기본 범위는 @Dependent 입니다. 즉, 빈의 라이프사이클은 참조가 포함된 빈의 라이프사이클에 따라 달라집니다. 다른 여러 범위가 존재하며 고유한 범위를 정의할 수 있습니다. 자세한 내용은 컨텍스트 및 범위를 참조하십시오.

빈 라이프사이클 관리
  1. 빈에 원하는 범위를 주석을 답니다.

    @RequestScoped
    @Named("greeter")
    public class GreeterBean {
      private Welcome welcome;
      private String city; // getter & setter not shown
      @Inject   void init(Welcome welcome) {
        this.welcome = welcome;
      }
      public void welcomeVisitors() {
        System.out.println(welcome.buildPhrase(city));
      }
    }
    Copy to Clipboard Toggle word wrap
  2. 이 빈은 Jakarta Server Faces 뷰에서 사용될 때 상태를 유지합니다.

    <h:form>
      <h:inputText value="#{greeter.city}"/>
      <h:commandButton value="Welcome visitors" action="#{greeter.welcomeVisitors}"/>
    </h:form>
    Copy to Clipboard Toggle word wrap

빈은 지정한 범위와 관련된 컨텍스트에 저장되며 범위가 적용되는 한 지속됩니다.

7.7.1. 생산자 방법 사용

생산자 메서드 는 빈 인스턴스의 소스 역할을 하는 메서드입니다. 지정된 컨텍스트에 인스턴스가 없으면 메서드 선언 자체에서 빈을 설명하고 컨테이너에서 메서드를 호출하여 빈의 인스턴스를 가져옵니다. 생산자 메서드를 사용하면 애플리케이션에서 빈 인스턴스화 프로세스를 완전히 제어할 수 있습니다.

이 섹션에서는 생산자 메서드를 사용하여 주입을 위해 빈이 아닌 다양한 오브젝트를 생성하는 방법을 보여줍니다.

예제: 생산자 방법 사용

대체 대신 생산자 방법을 사용하면 배포 후 다형성이 허용됩니다.

예제의 @Preferred 주석은 한정자 주석입니다. 한정자에 대한 자세한 내용은 한정자를 참조하십시오.

@SessionScoped
public class Preferences implements Serializable {
   private PaymentStrategyType paymentStrategy;
   ...
   @Produces @Preferred
   public PaymentStrategy getPaymentStrategy() {
       switch (paymentStrategy) {
           case CREDIT_CARD: return new CreditCardPaymentStrategy();
           case CHECK: return new CheckPaymentStrategy();
           default: return null;
       }
   }
}
Copy to Clipboard Toggle word wrap

다음 주입 지점에는 생산자 메서드와 동일한 유형 및 한정자 주석이 있으므로 일반적인 Contexts 및 Dependency Injection 주입 규칙을 사용하여 생산자 메서드로 확인됩니다. 생산자 메서드는 컨테이너에서 호출하여 이 주입 지점에 서비스를 제공할 인스턴스를 가져옵니다.

@Inject @Preferred PaymentStrategy paymentStrategy;
Copy to Clipboard Toggle word wrap

예제: 생산자 메서드에 범위 할당

생산자 메서드의 기본 범위는 @Dependent 입니다. 빈에 범위를 할당하면 적절한 컨텍스트에 바인딩됩니다. 이 예제의 제작자 메서드는 세션당 한 번만 호출됩니다.

@Produces @Preferred @SessionScoped
public PaymentStrategy getPaymentStrategy() {
   ...
}
Copy to Clipboard Toggle word wrap

예제: 생산자 방법 내에서 주입 사용

애플리케이션에서 직접 인스턴스화된 오브젝트는 종속성 주입을 활용할 수 없으며 인터셉터가 없습니다. 그러나 생산자 메서드에 종속성 주입을 사용하여 빈 인스턴스를 가져올 수 있습니다.

@Produces @Preferred @SessionScoped
public PaymentStrategy getPaymentStrategy(CreditCardPaymentStrategy ccps,
                                          CheckPaymentStrategy cps ) {
   switch (paymentStrategy) {
      case CREDIT_CARD: return ccps;
      case CHEQUE: return cps;
      default: return null;
   }
}
Copy to Clipboard Toggle word wrap

요청 범위 빈을 세션 범위 생산자에 삽입하는 경우 제작자 메서드는 현재 요청 범위 인스턴스를 세션 범위로 승격합니다. 이 방법은 바람직한 동작이 아니므로 이러한 방식으로 생산자 메서드를 사용할 때는 주의해야 합니다.

참고

생산자 메서드의 범위는 제작자 메서드를 선언하는 빈에서 상속되지 않습니다.

생산자 메서드를 사용하면 빈이 아닌 오브젝트를 주입하고 코드를 동적으로 변경할 수 있습니다.

7.8. 대체 빈

대안은 구현이 특정 클라이언트 모듈 또는 배포 시나리오에 고유한 빈입니다.

기본적으로 @Alternative 빈은 비활성화되어 있습니다. bean. xml 파일을 편집하여 특정 빈 아카이브에 대해 활성화됩니다. 그러나 이 활성화는 해당 아카이브의 빈에만 적용됩니다. @Priority 주석을 사용하여 전체 애플리케이션에 대한 대안을 활성화할 수 있습니다.

예제: 대체 옵션 정의

이 대안은 @Synchronous 및 @ Asynchronous 대안을 둘 다 사용하여 PaymentProcessor 클래스 구현을 정의합니다.

@Alternative @Synchronous @Asynchronous

public class MockPaymentProcessor implements PaymentProcessor {

   public void process(Payment payment) { ... }

}
Copy to Clipboard Toggle word wrap

예제: beans.xml을 사용하여 @Alternative 활성화

<beans
   xmlns="http://xmlns.jcp.org/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="
      http://xmlns.jcp.org/xml/ns/javaee
      http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd">
   <alternatives>
         <class>org.mycompany.mock.MockPaymentProcessor</class>
   </alternatives>
</beans>
Copy to Clipboard Toggle word wrap

선택한 대안 선언

@Priority 주석을 사용하면 전체 애플리케이션에 대한 대안을 활성화할 수 있습니다. 대안은 애플리케이션의 우선 순위를 지정할 수 있습니다.

  • 관리 빈 또는 세션 빈의 빈 클래스에 @Priority 주석을 배치하거나
  • 제작자 메서드, 필드 또는 리소스를 선언하는 빈 클래스에 @Priority 주석을 배치합니다.

7.8.1. 삽입을 대체로 덮어쓰기

대체 빈을 사용하여 기존 빈을 재정의할 수 있습니다. 동일한 역할을 채우지만 다른 기능을 채우는 클래스를 연결하는 방법으로 간주할 수 있습니다. 기본적으로 비활성화되어 있습니다.

이 작업은 대안을 지정하고 활성화하는 방법을 보여줍니다.

삽입 덮어쓰기

이 작업에서는 프로젝트에 TranslatingWelcome 클래스가 이미 있다고 가정하지만 "mock" TranslatingWelcome 클래스로 재정의하려고 합니다. 실제 을 사용할 수 없는 테스트 배포의 사례입니다.

  1. 대안을 정의합니다.

    @Alternative
    @Translating
    public class MockTranslatingWelcome extends Welcome {
      public String buildPhrase(string city) {
        return "Bienvenue à " + city + "!");
      }
    }
    Copy to Clipboard Toggle word wrap
  2. META-INF/beans.xml 또는 WEB-INF/beans.xml 파일에 정규화된 클래스 이름을 추가하여 대체 구현을 활성화합니다.

    <beans>
      <alternatives>
        <class>com.acme.MockTranslatingWelcome</class>
      </alternatives>
    </beans>
    Copy to Clipboard Toggle word wrap

이제 원래 구현 대신 대체 구현이 사용됩니다.

7.9. 확대/축소

많은 시스템에서 아키텍처 패턴을 사용하면 반복되는 빈 역할이 생성됩니다. 종료 유형을 사용하면 이러한 역할을 식별하고 중앙 위치에서 해당 역할이 있는 빈의 일반적인 메타데이터를 선언할 수 있습니다.

프로토타이핑 유형은 다음과 같은 조합을 캡슐화합니다.

  • 기본 범위.
  • 인터셉터 바인딩 세트입니다.

매개변수 유형에서는 다음 중 하나를 지정할 수도 있습니다.

  • 백유형이 기본값인 빈 EL 이름이 있는 모든 빈.
  • 대체 유형이 있는 모든 빈.

빈은 0, 1 또는 여러 개의 백유형을 선언할 수 있습니다. trailtype은 다른 여러 주석을 패키징하는 @Stereotype 주석입니다. digtype 주석은 빈 클래스, 생산자 메서드 또는 필드에 적용할 수 있습니다.

사전 유형에서 범위를 상속하는 클래스는 해당 사전 유형을 재정의하고 빈에서 직접 범위를 지정할 수 있습니다.

또한 entitytype에 @Named 주석이 있는 경우 해당 빈에 기본 빈 이름이 있습니다. 빈에 @Named 주석이 직접 지정된 경우 빈이 이 이름을 재정의할 수 있습니다. 명명된 빈에 대한 자세한 내용은 Named Beans 를 참조하십시오.

7.9.1. pvcreotypes 사용

피사유형이 없으면 주석이 복잡해질 수 있습니다. 이 작업에서는 난형을 사용하여 복잡성을 줄이고 코드를 간소화하는 방법을 보여 줍니다.

예제: 주석 복제

@Secure
@Transactional
@RequestScoped
@Named
public class AccountManager {
  public boolean transfer(Account a, Account b) {
    ...
  }
}
Copy to Clipboard Toggle word wrap

osreotypes 정의 및 사용
  1. tooltype을 정의합니다.

    @Secure
    @Transactional
    @RequestScoped
    @Named
    @Stereotype
    @Retention(RUNTIME)
    @Target(TYPE)
    public @interface BusinessComponent {
     ...
    }
    Copy to Clipboard Toggle word wrap
  2. 철자 유형을 사용합니다.

    @BusinessComponent
    public class AccountManager {
      public boolean transfer(Account a, Account b) {
        ...
      }
    }
    Copy to Clipboard Toggle word wrap

7.10. 관찰자 방법

관찰자 메서드는 이벤트가 발생하면 알림을 받습니다.

컨텍스트 및 종속성 주입은 트랜잭션 관찰기 메서드를 제공하여 이벤트가 실행된 트랜잭션의 완료 단계 또는 트랜잭션 완료 단계 이후에 이벤트 알림을 수신합니다.

7.10.1. 이벤트 실행 및 관찰

예제: 이벤트 실행

다음 코드는 메서드에서 주입 및 사용되는 이벤트를 보여줍니다.

public class AccountManager {
  @Inject Event<Withdrawal> event;

  public boolean transfer(Account a, Account b) {
    ...
    event.fire(new Withdrawal(a));
  }
}
Copy to Clipboard Toggle word wrap

예제: 한정자를 사용하여 이벤트 실행

이벤트 삽입에 한정자를 추가하여 보다 구체화할 수 있습니다. 한정자에 대한 자세한 내용은 한정자를 참조하십시오.

public class AccountManager {
  @Inject @Suspicious Event <Withdrawal> event;

  public boolean transfer(Account a, Account b) {
    ...
    event.fire(new Withdrawal(a));
  }
}
Copy to Clipboard Toggle word wrap

예제: 이벤트 관찰

이벤트를 관찰하려면 @Observes 주석을 사용합니다.

public class AccountObserver {
  void checkTran(@Observes Withdrawal w) {
    ...
  }
}
Copy to Clipboard Toggle word wrap

한정자를 사용하여 특정 유형의 이벤트만 관찰할 수 있습니다.

public class AccountObserver {
  void checkTran(@Observes @Suspicious Withdrawal w) {
    ...
  }
}
Copy to Clipboard Toggle word wrap

7.10.2. Transactional Observers

트랜잭션 관찰자는 이벤트가 발생한 트랜잭션의 완료 단계 전후에 이벤트 알림을 받습니다. 상태 저장 개체 모델에서는 종종 상태가 단일 원자 트랜잭션보다 긴 동안 유지되기 때문에 트랜잭션 관찰자가 중요합니다.

트랜잭션 관찰자는 5가지가 있습니다.

  • IN_PROGRESS: 기본적으로 관찰자는 즉시 호출됩니다.
  • AFTER_SUCCESS: 관찰자는 트랜잭션 완료 단계 이후에 호출되지만 트랜잭션이 성공적으로 완료된 경우에만 호출됩니다.
  • AFTER_FAILURE: 트랜잭션 완료 단계 후에 관찰 프로그램이 호출되지만 트랜잭션이 성공적으로 완료되지 않는 경우에만 관찰자가 호출됩니다.
  • AFTER_COMPLETION: 관찰자는 트랜잭션 완료 단계 후에 호출됩니다.
  • BEFORE_COMPLETION: 관찰자는 트랜잭션 완료 단계 전에 호출됩니다.

다음 observer 메서드는 애플리케이션 컨텍스트에 캐시된 쿼리 결과 집합을 새로 고치지만 카테고리 트리를 업데이트하는 트랜잭션 시에만 캐시됩니다.

public void refreshCategoryTree(@Observes(during = AFTER_SUCCESS) CategoryUpdateEvent event) { ... }
Copy to Clipboard Toggle word wrap

다음 예와 같이 애플리케이션 범위에 설정된 Jakarta Persistence 쿼리 결과를 캐시했다고 가정합니다.

import javax.ejb.Singleton;
import javax.enterprise.inject.Produces;

@ApplicationScoped @Singleton

public class Catalog {
   @PersistenceContext EntityManager em;
   List<Product> products;
   @Produces @Catalog
   List<Product> getCatalog() {
      if (products==null) {
         products = em.createQuery("select p from Product p where p.deleted = false")
            .getResultList();
      }
      return products;
   }
}
Copy to Clipboard Toggle word wrap

경우에 따라 제품이 생성 또는 삭제 되는 경우도 있습니다. 이 경우 제품 카탈로그를 새로 고쳐야 합니다. 그러나 이 업데이트를 수행하기 전에 트랜잭션이 성공적으로 완료될 때까지 기다려야 합니다.

다음은 Products triggers 이벤트를 생성하고 삭제하는 빈의 예입니다.

import javax.enterprise.event.Event;

@Stateless

public class ProductManager {
   @PersistenceContext EntityManager em;
   @Inject @Any Event<Product> productEvent;
   public void delete(Product product) {
      em.delete(product);
      productEvent.select(new AnnotationLiteral<Deleted>(){}).fire(product);
   }

   public void persist(Product product) {
      em.persist(product);
      productEvent.select(new AnnotationLiteral<Created>(){}).fire(product);
   }
   ...
}
Copy to Clipboard Toggle word wrap

이제 Catalog 에서 트랜잭션이 완료되면 이벤트를 관찰할 수 있습니다.

import javax.ejb.Singleton;

@ApplicationScoped @Singleton
public class Catalog {
   ...
   void addProduct(@Observes(during = AFTER_SUCCESS) @Created Product product) {
      products.add(product);
   }

   void removeProduct(@Observes(during = AFTER_SUCCESS) @Deleted Product product) {
      products.remove(product);
   }

}
Copy to Clipboard Toggle word wrap

7.11. 인터셉터

인터셉터를 사용하면 빈의 방법을 직접 수정하지 않고도 빈의 비즈니스 메서드에 기능을 추가할 수 있습니다. 인터셉터는 빈의 비즈니스 방법보다 먼저 실행됩니다. 인터셉터는 Jakarta Enterprise Beans 사양의 일부로 정의됩니다.

Jakarta Contexts and Dependency Injection은 주석을 사용하여 인터셉터를 bean에 바인딩할 수 있어 이 기능을 향상시킵니다.

인터셉션 포인트

  • 비즈니스 방법 가로채기: 비즈니스 메서드 인터셉터는 빈의 클라이언트가 빈 메서드 호출에 적용됩니다.
  • 라이프 사이클 콜백 인터셉션: 라이프사이클 콜백 인터셉터는 컨테이너에서 라이프사이클 콜백 호출에 적용됩니다.
  • timeout 메서드 인터셉션: timeout 메서드 인터셉터는 컨테이너에서 Jakarta Enterprise Beans 시간 제한 메서드를 호출하는 데 적용됩니다.
인터셉터 활성화

기본적으로 모든 인터셉터는 비활성화됩니다. 빈 아카이브의 bean.xml 설명자를 사용하여 인터셉터를 활성화할 수 있습니다. 그러나 이 활성화는 해당 아카이브의 빈에만 적용됩니다.

@Priority 주석을 사용하여 전체 애플리케이션에 대한 인터셉터를 활성화할 수 있습니다.

예제: bean.xml에서 인터셉터 활성화

<beans
   xmlns="http://xmlns.jcp.org/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="
      http://xmlns.jcp.org/xml/ns/javaee
      http://xmlns.jcp.org/xml/ns/javaee/beans_2.0.xsd">
   <interceptors>
      <class>org.mycompany.myapp.TransactionInterceptor</class>
   </interceptors>
</beans>
Copy to Clipboard Toggle word wrap

XML 선언을 사용하면 두 가지 문제가 해결됩니다.

  • 이를 통해 시스템의 인터셉터 순서를 지정하여 결정적인 동작을 보장할 수 있습니다.
  • 배포 시 인터셉터 클래스를 활성화하거나 비활성화할 수 있습니다.

@Priority 를 사용하여 활성화된 인터셉터는 beans.xml 파일을 사용하여 인터셉터를 활성화하기 전에 호출됩니다.

참고

인터셉터를 @Priority 에서 활성화하고 동시에 beans.xml 파일에서 호출하면 포팅할 수 없는 동작이 발생합니다. 따라서 다양한 Jakarta Contexts 및 Dependency Injection 구현에서 일관된 동작을 유지하려면 활성화의 조합을 피해야 합니다.

7.11.1. 자카르타 컨텍스트 및 종속성 주입과 인터셉터 사용

Jakarta Contexts and Dependency Injection을 사용하면 인터셉터 코드를 단순화하고 비즈니스 코드에 더 쉽게 적용할 수 있습니다.

자카르타 컨텍스트 및 종속성 주입이 없으면 인터셉터에는 두 가지 문제가 있습니다.

  • 빈은 인터셉터 구현을 직접 지정해야 합니다.
  • 애플리케이션의 모든 빈은 올바른 순서로 전체 인터셉터 세트를 지정해야 합니다. 이로 인해 애플리케이션 전체에서 인터셉터를 추가하거나 제거할 수 있으며 오류가 발생하기 쉽습니다.
자카르타 컨텍스트 및 종속성 주입과 인터셉터 사용
  1. 인터셉터 바인딩 유형을 정의합니다.

    @InterceptorBinding
    @Retention(RUNTIME)
    @Target({TYPE, METHOD})
    public @interface Secure {}
    Copy to Clipboard Toggle word wrap
  2. 인터셉터 구현을 표시합니다.

    @Secure
    @Interceptor
    public class SecurityInterceptor {
      @AroundInvoke
      public Object aroundInvoke(InvocationContext ctx) throws Exception {
        // enforce security ...
        return ctx.proceed();
        }
    }
    Copy to Clipboard Toggle word wrap
  3. 사용자의 개발 환경에서 인터셉터를 사용합니다.

    @Secure
    public class AccountManager {
      public boolean transfer(Account a, Account b) {
        ...
      }
    }
    Copy to Clipboard Toggle word wrap
  4. META-INF/beans.xml 또는 WEB-INF/beans.xml 파일에 추가하여 배포에서 인터셉터를 활성화합니다.

    <beans>
      <interceptors>
        <class>com.acme.SecurityInterceptor</class>
        <class>com.acme.TransactionInterceptor</class>
      </interceptors>
    </beans>
    Copy to Clipboard Toggle word wrap

인터셉터는 나열된 순서대로 적용됩니다.

7.12. 데코레이터

데코레이터는 특정 Java 인터페이스에서 호출을 가로채며 해당 인터페이스에 연결된 모든 의미 체계를 인식합니다. 데코레이터는 일부 유형의 비즈니스 문제를 모델링하는 데 유용하지만 인터셉터는 일반적으로 없습니다. 데코레이터는 빈 또는 추상 클래스로, 패키징하는 유형을 구현하고 @Decorator 로 주석이 추가됩니다. Jakarta Contexts 및 Dependency Injection 애플리케이션에서 데코레이터를 호출하려면 bean.xml 파일에 지정해야 합니다.

예제: bean.xml을 통해 액셀러레이터 호출

<beans
   xmlns="http://xmlns.jcp.org/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="
      http://xmlns.jcp.org/xml/ns/javaee
      http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd">
   <decorators>
         <class>org.mycompany.myapp.LargeTransactionDecorator</class>
   </decorators>
</beans>
Copy to Clipboard Toggle word wrap

이 선언은 다음 두 가지 주요 목적을 제공합니다.

  • 이를 통해 시스템에서 데코레이터의 순서를 지정하여 결정적인 동작을 보장할 수 있습니다.
  • 배포 시 데코레이터 클래스를 활성화하거나 비활성화할 수 있습니다.

데코레이터에 정확히 하나의 @Delegate 주입 지점이 있어야 하므로 이 오브젝트에 대한 참조를 얻을 수 있습니다.

예제: 데코레이터 클래스

@Decorator
public abstract class LargeTransactionDecorator implements Account {

   @Inject @Delegate @Any Account account;
   @PersistenceContext EntityManager em;

   public void withdraw(BigDecimal amount) {
      ...
   }

   public void deposit(BigDecimal amount);
      ...
   }
}
Copy to Clipboard Toggle word wrap

@Priority 주석을 사용하여 전체 애플리케이션에 대해 데코레이터를 활성화할 수 있습니다.

@Priority 를 사용하여 활성화한 데코레이터는 beans.xml 파일을 사용하여 활성화되기 전에 데코레이터를 호출합니다. 더 낮은 우선 순위 값을 먼저라고 합니다.

참고

@Priority 에 의해 데코레이터를 활성화하고 beans.xml 에서 동시에 호출하면 포팅할 수 없는 동작이 발생합니다. 따라서 다양한 컨텍스트 및 종속성 주입 구현에서 일관된 동작을 유지하려면 활성화의 이러한 조합을 피해야 합니다.

7.13. 휴대용 확장

컨텍스트 및 종속성 주입은 프레임워크, 확장 및 기타 기술과의 통합을 위한 기반이 됩니다. 따라서 Contexts and Dependency Injection은 Contexts 및 Dependency Injection에 이식 가능한 확장 기능을 사용하는 데 필요한 SPI 집합을 노출합니다.

확장 기능은 다음과 같은 유형의 기능을 제공할 수 있습니다.

  • 비즈니스 프로세스 관리 엔진과의 통합.
  • Spring, Seam, GWT, Wicket 등의 타사 프레임워크와의 통합.
  • 컨텍스트 및 종속성 주입 프로그래밍 모델에 기반한 새로운 기술.

자카르타 컨텍스트 및 종속성 주입 사양에 따르면 이식 가능한 확장 기능은 다음과 같은 방식으로 컨테이너와 통합할 수 있습니다.

  • 컨테이너에 고유한 빈, 인터셉터 및 데코레이터를 제공합니다.
  • 종속성을 사용하여 자체 오브젝트에 종속성 삽입.
  • 사용자 지정 범위에 대한 컨텍스트 구현 제공.
  • 다른 소스의 메타데이터를 사용하여 주석 기반 메타데이터를 보강하거나 재정의합니다.

자세한 내용은 Weld 문서의 Portable extensions 을 참조하십시오.

7.14. 빈 프록시

주입된 빈의 클라이언트는 일반적으로 빈 인스턴스에 대한 직접 참조를 보유하지 않습니다. 빈이 종속 오브젝트인 @Dependent 범위가 아니면 컨테이너에서 프록시 오브젝트를 사용하여 삽입된 모든 참조를 빈으로 리디렉션해야 합니다.

클라이언트 프록시라고도 하는 빈 프록시는 메서드 호출을 수신하는 빈 인스턴스가 현재 컨텍스트와 연결된 인스턴스인지 확인합니다. 클라이언트 프록시를 사용하면 세션 컨텍스트와 같은 컨텍스트에 바인드된 빈을 재귀적으로 삽입하지 않고 디스크에 직렬화할 수도 있습니다.

Java 제한으로 인해 컨테이너에서 일부 Java 유형을 프록시할 수 없습니다. 이러한 유형 중 하나로 선언된 주입 지점이 @Dependent 이외의 범위를 사용하여 빈으로 확인되면 컨테이너에서 배포를 중단합니다.

특정 Java 유형은 컨테이너에서 프록시할 수 없습니다. 여기에는 다음이 포함됩니다.

  • 매개 변수 없이 비개인 생성자가 없는 클래스입니다.
  • 최종으로 선언되거나 최종 방법이 있는 클래스.
  • 배열 및 기본 유형.

7.15. 삽입에서 프록시 사용

빈의 라이프사이클이 서로 다르면 프록시가 주입에 사용됩니다. 프록시는 런타임 시 생성되는 빈의 하위 클래스이며 빈 클래스의 모든 비개인 메서드를 재정의합니다. 프록시는 호출을 실제 빈 인스턴스로 전달합니다.

이 예에서 PaymentProcessor 인스턴스는 플레이버에 직접 삽입되지 않습니다. 대신 프록시가 삽입되고 processPayment() 메서드가 호출되면 프록시는 현재 PaymentProcessor 빈 인스턴스를 조회하고 해당 서버에서 processPayment() 메서드를 호출합니다.

예제: 프록시 삽입

@ConversationScoped
class PaymentProcessor
{
  public void processPayment(int amount)
  {
    System.out.println("I'm taking $" + amount);
  }
}

@ApplicationScoped
public class Shop
{

  @Inject
  PaymentProcessor paymentProcessor;

  public void buyStuff()
  {
    paymentProcessor.processPayment(100);
  }
}
Copy to Clipboard Toggle word wrap

8장. JBoss EAP MBean 서비스

관리형 빈(즉, 간단히 MBean이라고도 함)은 종속성 주입을 사용하여 생성되는 JavaBean의 유형입니다. MBean 서비스는 JBoss EAP 서버의 핵심 구성 요소입니다.

8.1. JBoss MBean 서비스 작성

JBoss 서비스를 사용하는 사용자 지정 MBean 서비스를 작성하려면 서비스 인터페이스 방법 패턴이 필요합니다. JBoss MBean 서비스 인터페이스 방법 패턴은 자체적으로 생성,시작,중지 및 제거할 수 있는 MBean 서비스에 알리는 라이프사이클 작업 집합으로 구성됩니다.

다음 방법을 사용하여 종속성 상태를 관리할 수 있습니다.

  • MBean에서 특정 메서드를 호출하려면 MBean 인터페이스에서 해당 메서드를 선언합니다. 이 접근 방식을 통해 MBean 구현을 통해 JBoss 특정 클래스에 대한 종속성을 방지할 수 있습니다.
  • JBoss 특정 클래스에 대한 종속성에 대해 걱정할 필요가 없는 경우 MBean 인터페이스에서 ServiceMBean 인터페이스와 ServiceMBean Support 클래스를 확장할 수 있습니다. ServiceMBeanSupport 클래스는 생성, 시작 및 중지와 같은 서비스 라이프사이클 방법을 구현합니다. start() 이벤트와 같은 특정 이벤트를 처리하려면 ServiceMBeanSupport 클래스에서 제공하는 startService() 메서드를 재정의해야 합니다.

8.1.1. 표준 MBean 예

이 섹션에서는 서비스 아카이브(. sar)에 함께 패키지로 제공되는 MBean 서비스 예제를 개발합니다.

ConfigServiceMBean 인터페이스는 JBoss 특정 클래스를 사용하지 않고 MBean을 올바르게 시작,보유중지하는 start,getTimeoutstop 메서드와 같은 특정 메서드를 선언합니다. ConfigService 클래스는 ConfigServiceMBean 인터페이스를 구현하고 그 결과 해당 인터페이스 내에서 사용되는 메서드를 구현합니다.

PlainThread 클래스는 ServiceMBeanSupport 클래스를 확장하고 PlainThreadMBean 인터페이스를 구현합니다. PlainThread 는 스레드를 시작하고 ConfigServiceMBean.getTimeout() 을 사용하여 스레드를 유휴 상태로 설정하는 시간을 결정합니다.

예제: MBean 서비스 클래스

package org.jboss.example.mbean.support;
public interface ConfigServiceMBean {
    int getTimeout();
    void start();
    void stop();
}
package org.jboss.example.mbean.support;
public class ConfigService implements ConfigServiceMBean {
    int timeout;
    @Override
    public int getTimeout() {
        return timeout;
    }
    @Override
    public void start() {
        //Create a random number between 3000 and 6000 milliseconds
        timeout = (int)Math.round(Math.random() * 3000) + 3000;
        System.out.println("Random timeout set to " + timeout + " seconds");
    }
    @Override
    public void stop() {
        timeout = 0;
    }
}

package org.jboss.example.mbean.support;
import org.jboss.system.ServiceMBean;
public interface PlainThreadMBean extends ServiceMBean {
    void setConfigService(ConfigServiceMBean configServiceMBean);
}

package org.jboss.example.mbean.support;
import org.jboss.system.ServiceMBeanSupport;
public class PlainThread extends ServiceMBeanSupport implements PlainThreadMBean {
    private ConfigServiceMBean configService;
    private Thread thread;
    private volatile boolean done;
    @Override
    public void setConfigService(ConfigServiceMBean configService) {
        this.configService = configService;
    }
    @Override
    protected void startService() throws Exception {
        System.out.println("Starting Plain Thread MBean");
        done = false;
        thread = new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    while (!done) {
                        System.out.println("Sleeping....");
                        Thread.sleep(configService.getTimeout());
                        System.out.println("Slept!");
                    }
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }
        });
        thread.start();
    }
    @Override
    protected void stopService() throws Exception {
        System.out.println("Stopping Plain Thread MBean");
        done = true;
    }
}
Copy to Clipboard Toggle word wrap

jboss-service.xml 설명자는 inject 태그를 사용하여 ConfigService 클래스가 PlainThread 클래스에 삽입되는 방법을 보여줍니다. inject 태그는 PlainThreadMBean과 ConfigServiceMBean 사이에 종속성을 설정하므로 PlainThreadMBean이 ConfigServiceMBean 을 쉽게 사용할 수 있습니다.

예: jboss-service.xml 서비스 설명자

<server xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:jboss:service:7.0 jboss-service_7_0.xsd"
        xmlns="urn:jboss:service:7.0">
 <mbean code="org.jboss.example.mbean.support.ConfigService" name="jboss.support:name=ConfigBean"/>
 <mbean code="org.jboss.example.mbean.support.PlainThread" name="jboss.support:name=ThreadBean">
  <attribute name="configService">
   <inject bean="jboss.support:name=ConfigBean"/>
  </attribute>
 </mbean>
</server>
Copy to Clipboard Toggle word wrap

MBeans 예제를 작성한 후에는 서비스 아카이브( . sar)의 META-INF/ 폴더에 클래스 및 jboss- service.xml설명자를 패키징할 수 있습니다.

8.2. JBoss MBean 서비스 배포

예제: 관리형 도메인에서 MBean 배포 및 테스트

다음 명령을 사용하여 관리형 도메인에 MBeans(ServiceMBeanTest.sar) 예제를 배포합니다.

deploy ~/Desktop/ServiceMBeanTest.sar --all-server-groups
Copy to Clipboard Toggle word wrap

예제: 독립 실행형 서버에 MBean 배포 및 테스트

다음 명령을 사용하여 독립 실행형 서버에서 MBean(ServiceMBeanTest.sar) 예제를 빌드하고 배포합니다.

deploy ~/Desktop/ServiceMBeanTest.sar
Copy to Clipboard Toggle word wrap

예제: MBeans 아카이브 배포 취소

다음 명령을 사용하여 MBean 예제 배포를 취소합니다.

undeploy ServiceMBeanTest.sar
Copy to Clipboard Toggle word wrap

9장. 자카르타 동시성

Jakarta Concurrency는 자카르타 EE 애플리케이션 환경 사양에 Java SE 동시성 유틸리티를 수용하는 API입니다. 자카르타 동시성 사양에 정의되어 있습니다. JBoss EAP를 사용하면 자카르타 동시성 인스턴스를 생성, 편집 및 삭제할 수 있으므로 이러한 인스턴스를 애플리케이션에서 사용할 수 있습니다.

Jakarta Concurrency는 기존 컨텍스트의 애플리케이션 스레드를 가져와 자체 스레드에서 이를 사용하여 호출 컨텍스트를 확장하는 데 도움이 됩니다. 호출 컨텍스트 확장에는 기본적으로 클래스 로드, JNDI 및 보안 컨텍스트가 포함됩니다.

자카르타 동시성 유형은 다음과 같습니다.

  • 컨텍스트 서비스
  • 관리 스레드 팩토리
  • 관리형 실행자 서비스
  • 관리된 예약 실행자 서비스

예제: standalone.xml의 자카르타 동시성

<subsystem xmlns="urn:jboss:domain:ee:4.0">
            <spec-descriptor-property-replacement>false</spec-descriptor-property-replacement>
            <concurrent>
                <context-services>
                    <context-service name="default" jndi-name="java:jboss/ee/concurrency/context/default" use-transaction-setup-provider="true"/>
                </context-services>
                <managed-thread-factories>
                    <managed-thread-factory name="default" jndi-name="java:jboss/ee/concurrency/factory/default" context-service="default"/>
                </managed-thread-factories>
                <managed-executor-services>
                    <managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="60000" keepalive-time="5000"/>
                </managed-executor-services>
                <managed-scheduled-executor-services>
                    <managed-scheduled-executor-service name="default" jndi-name="java:jboss/ee/concurrency/scheduler/default" context-service="default" hung-task-threshold="60000" keepalive-time="3000"/>
                </managed-scheduled-executor-services>
            </concurrent>
            <default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/ExampleDS" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/>
</subsystem>
Copy to Clipboard Toggle word wrap

9.1. 컨텍스트 서비스

컨텍스트 서비스(javax.enterprise.concurrent.ContextService)를 사용하면 기존 오브젝트에서 컨텍스트 프록시를 빌드할 수 있습니다. 컨텍스트 프록시는 호출을 원래 오브젝트로 전송하기 전에 컨텍스트를 생성하거나 호출할 때 다른 Jakarta Concurrency 유틸리티에서 사용하는 호출 컨텍스트를 준비합니다.

컨텍스트 서비스 동시성 유틸리티의 특성은 다음과 같습니다.

  • name: 모든 컨텍스트 서비스 내의 고유 이름입니다.
  • jndi-name: 컨텍스트 서비스를 JNDI에 배치해야 하는 위치를 정의합니다.
  • use-transaction-setup-provider: 선택 사항: 프록시 오브젝트를 호출할 때 컨텍스트 서비스에서 빌드한 컨텍스트 프록시가 컨텍스트에서 트랜잭션을 일시 중단해야 하는지를 나타냅니다. 기본값은 false 이지만 기본 컨텍스트 서비스의 값은 true 입니다.

컨텍스트 서비스 동시성 유틸리티를 사용하는 예는 위의 예를 참조하십시오.

예제: 새 컨텍스트 서비스 추가

/subsystem=ee/context-service=newContextService:add(jndi-name=java:jboss/ee/concurrency/contextservice/newContextService)
Copy to Clipboard Toggle word wrap

예제: 컨텍스트 서비스 변경

/subsystem=ee/context-service=newContextService:write-attribute(name=jndi-name, value=java:jboss/ee/concurrency/contextservice/changedContextService)
Copy to Clipboard Toggle word wrap

이 작업을 수행하려면 다시 로드해야 합니다.

예제: 컨텍스트 서비스 제거

/subsystem=ee/context-service=newContextService:remove()
Copy to Clipboard Toggle word wrap

이 작업을 수행하려면 다시 로드해야 합니다.

9.2. 관리 스레드 팩토리

관리형 스레드 팩토리 (javax.enterprise.concurrent.ManagedThreadFactory) 동시성 유틸리티를 사용하면 Jakarta EE 애플리케이션에서 Java 스레드를 생성할 수 있습니다. JBoss EAP는 관리되는 스레드 팩토리 인스턴스를 처리하므로 Jakarta EE 애플리케이션은 라이프사이클 관련 방법을 호출할 수 없습니다.

관리형 스레드 팩토리 동시성 유틸리티의 특성은 다음과 같습니다.

  • context-service: 모든 관리 스레드 팩토리 내의 고유한 이름입니다.
  • jndi-name: JNDI에서 관리 스레드 팩토리를 배치해야 하는 위치를 정의합니다.
  • 우선순위: 선택 사항: 팩토리에서 생성한 새 스레드의 우선 순위를 나타내며 기본값은 5 입니다.

예제: 새 관리 스레드 팩토리 추가

/subsystem=ee/managed-thread-factory=newManagedTF:add(context-service=newContextService, jndi-name=java:jboss/ee/concurrency/threadfactory/newManagedTF, priority=2)
Copy to Clipboard Toggle word wrap

예제: 관리 스레드 팩토리 변경

/subsystem=ee/managed-thread-factory=newManagedTF:write-attribute(name=jndi-name, value=java:jboss/ee/concurrency/threadfactory/changedManagedTF)
Copy to Clipboard Toggle word wrap

이 작업을 수행하려면 다시 로드해야 합니다. 마찬가지로 다른 속성도 변경할 수 있습니다.

예제: 관리 스레드 팩토리 제거

/subsystem=ee/managed-thread-factory=newManagedTF:remove()
Copy to Clipboard Toggle word wrap

이 작업을 수행하려면 다시 로드해야 합니다.

9.3. 관리형 실행자 서비스

관리형 실행기 서비스 (javax.enterprise.concurrent.ManagedExecutorService) 를 통해 자카르타 EE 애플리케이션이 비동기 실행을 위한 작업을 제출할 수 있습니다. JBoss EAP는 관리되는 실행자 서비스 인스턴스를 처리하므로 Jakarta EE 애플리케이션은 라이프사이클 관련 메서드를 호출할 수 없습니다.

관리형 실행자 서비스 동시성 유틸리티의 속성은 다음과 같습니다.

  • context-service: 선택 사항: 기존 컨텍스트 서비스를 이름으로 참조합니다. 지정된 경우 작업을 실행자에 제출할 때 참조된 컨텍스트 서비스가 표시되는 호출 컨텍스트를 캡처합니다. 이 컨텍스트는 작업을 실행할 때 사용됩니다.
  • jndi-name: 관리 스레드 팩토리를 JNDI에 배치할 위치를 정의합니다.
  • max-threads: 실행자가 사용하는 최대 스레드 수를 정의합니다. 정의되지 않은 경우 코어 스레드 의 값이 사용됩니다.
  • thread-factory: 기존 관리 스레드 팩토리를 이름으로 참조하여 내부 스레드 생성을 처리합니다. 지정하지 않으면 기본 구성이 포함된 관리형 스레드 팩토리가 생성되고 내부적으로 사용됩니다.
  • 코어 스레드: 실행자가 사용할 최소 스레드 수를 정의합니다. 이 속성이 정의되지 않은 경우 기본값은 프로세서 수에 따라 계산됩니다. 값이 0 인 것은 권장되지 않습니다. 대기열 전략을 결정하는 데 이 값을 사용하는 방법에 대한 자세한 내용은 queue-length 특성을 참조하십시오.
  • keepalive-time: 내부 스레드가 유휴 상태일 수 있는 시간을 밀리초 단위로 정의합니다. 속성 기본값은 60000 입니다.
  • queue-length: 실행자의 작업 대기열 용량을 나타냅니다. 값 0 은 직접 이관을 의미하며 가능한 거부가 발생합니다. 이 속성이 정의되지 않았거나 Integer.MAX_VALUE 로 설정된 경우 바인딩되지 않은 큐를 사용해야 함을 나타냅니다. 다른 모든 값은 정확한 큐 크기를 지정합니다. 바인딩되지 않은 큐 또는 직접 핸드오프가 사용되는 경우 0 보다 큰 코어 스레드 값이 필요합니다.
  • hung-task-threshold: 관리 실행자 서비스에 의해 중단된 것으로 간주되는 시간(밀리초)을 정의하고 강제로 중단된 시간을 정의합니다. 값이 기본값인 0 이면 작업이 중단되지 않습니다.
  • long-running-tasks: 장기 실행 작업의 실행을 최적화하고 기본값은 false 입니다.
  • reject-policy: 실행자가 작업을 거부할 때 사용할 정책을 정의합니다. 속성 값은 기본 ABORT 일 수 있습니다. 즉 예외를 throw해야 합니다. 즉, RETRY_ABORT 는 예외를 발생하기 전에 한 번 더 제출하려고 합니다.

예제: 새 관리 실행자 서비스 추가

/subsystem=ee/managed-executor-service=newManagedExecutorService:add(jndi-name=java:jboss/ee/concurrency/executor/newManagedExecutorService, core-threads=7, thread-factory=default)
Copy to Clipboard Toggle word wrap

예제: Managed Executor 서비스 변경

/subsystem=ee/managed-executor-service=newManagedExecutorService:write-attribute(name=core-threads,value=10)
Copy to Clipboard Toggle word wrap

이 작업을 수행하려면 다시 로드해야 합니다. 마찬가지로 다른 속성도 변경할 수 있습니다.

예제: Managed Executor 서비스 제거

/subsystem=ee/managed-executor-service=newManagedExecutorService:remove()
Copy to Clipboard Toggle word wrap

이 작업을 수행하려면 다시 로드해야 합니다.

9.4. 관리된 예약 실행자 서비스

관리되는 예약된 executor 서비스 (javax.enterprise.concurrent.ManagedScheduledExecutorService) 를 사용하면 자카르타 EE 애플리케이션이 비동기 실행을 위한 작업을 예약할 수 있습니다. JBoss EAP는 관리형 예약 실행자 서비스 인스턴스를 처리하므로 자카르타 EE 애플리케이션은 라이프사이클 관련 메서드를 호출할 수 없습니다.

관리형 실행자 서비스 동시성 유틸리티의 속성은 다음과 같습니다.

  • context-service: 기존 컨텍스트 서비스를 이름으로 참조합니다. 지정된 경우 작업을 실행자에 제출할 때 참조된 컨텍스트 서비스가 표시되는 호출 컨텍스트를 캡처합니다. 이 컨텍스트는 작업을 실행할 때 사용됩니다.
  • hung-task-threshold: 관리 예약된 executor 서비스에 의해 중단된 것으로 간주되는 시간(밀리초)을 정의하고 강제로 중단된 시간을 정의합니다. 값이 기본값인 0 이면 작업이 중단되지 않습니다.
  • keepalive-time: 내부 스레드가 유휴 상태일 수 있는 시간을 밀리초 단위로 정의합니다. 속성 기본값은 60000 입니다.
  • reject-policy: 실행자가 작업을 거부할 때 사용할 정책을 정의합니다. 특성 값은 기본 ABORT 일 수 있습니다. 즉 예외를 throw해야 함을 의미하며 RETRY_ABORT 는 executor가 예외를 발생하기 전에 한 번 더 제출하려고 합니다.
  • 코어 스레드: 예약된 실행자가 사용할 최소 스레드 수를 정의합니다.
  • jndi-name: 관리 예약된 실행자 서비스를 JNDI에 배치해야 하는 위치를 정의합니다.
  • long-running-tasks: 장기 실행 작업의 실행을 최적화하고 기본값은 false입니다.
  • thread-factory: 기존 관리 스레드 팩토리를 이름으로 참조하여 내부 스레드 생성을 처리합니다. 지정하지 않으면 기본 구성이 포함된 관리형 스레드 팩토리가 생성되고 내부적으로 사용됩니다.

예제: 새 관리 예약 실행자 서비스 추가

/subsystem=ee/managed-scheduled-executor-service=newManagedScheduledExecutorService:add(jndi-name=java:jboss/ee/concurrency/scheduledexecutor/newManagedScheduledExecutorService, core-threads=7, context-service=default)
Copy to Clipboard Toggle word wrap

이 작업을 수행하려면 다시 로드해야 합니다.

예제: 관리형 예약 실행자 서비스 변경

/subsystem=ee/managed-scheduled-executor-service=newManagedScheduledExecutorService:write-attribute(name=core-threads, value=10)
Copy to Clipboard Toggle word wrap

이 작업을 수행하려면 다시 로드해야 합니다. 마찬가지로 다른 특성을 변경할 수 있습니다.

예제: 관리형 예약 실행자 서비스 제거

/subsystem=ee/managed-scheduled-executor-service=newManagedScheduledExecutorService:remove()
Copy to Clipboard Toggle word wrap

이 작업을 수행하려면 다시 로드해야 합니다.

관리 CLI 특성으로 생성된 런타임 통계를 확인하여 관리되는 실행자 서비스의 성능을 모니터링하고 예약된 실행자 서비스의 성능을 모니터링할 수 있습니다. 독립 실행형 서버 또는 호스트에 매핑된 개별 서버에 대한 런타임 통계를 볼 수 있습니다.

중요

domain.xml 구성에는 런타임 통계 관리 CLI 속성에 대한 리소스가 포함되지 않으므로 관리 CLI 속성을 사용하여 관리형 도메인의 런타임 통계를 볼 수 없습니다.

Expand
표 9.1. 관리 실행자 서비스 및 관리되는 예약 실행자 서비스의 성능을 모니터링하기 위한 관리 CLI 속성을 표시합니다.
속성설명

active-thread-count

작업을 실행 중인 대략적인 스레드 수입니다.

completed-task-count

실행을 완료한 대략적인 총 작업 수입니다.

hung-thread-count

중단된 실행자 스레드 수입니다.

max-thread-count

최대 실행자 스레드 수입니다.

current-queue-size

실행자 작업 대기열의 현재 크기입니다.

task-count

실행을 위해 제출된 대략적인 총 작업 수입니다.

thread-count

현재 실행자 스레드 수입니다.

독립 실행형 서버에서 실행 중인 관리 실행자 서비스에 대한 런타임 통계를 보는 예.

[standalone@localhost:9990 /] /subsystem=ee/managed-executor-service=default:read-resource(include-runtime=true,recursive=true)
Copy to Clipboard Toggle word wrap

독립 실행형 서버에서 실행 중인 관리 예약된 executor 서비스에 대한 런타임 통계의 예.

[standalone@localhost:9990 /] /subsystem=ee/managed-scheduled-executor-service=default:read-resource(include-runtime=true,recursive=true)
Copy to Clipboard Toggle word wrap

호스트에 매핑된 서버에서 실행 중인 관리 실행자 서비스에 대한 런타임 통계를 보는 예.

[domain@localhost:9990 /] /host=<host_name>/server=<server_name>/subsystem=ee/managed-executor-service=default:read-resource(include-runtime=true,recursive=true)
Copy to Clipboard Toggle word wrap

호스트에 매핑된 서버에서 실행 중인 관리 예약 실행자 서비스에 대한 런타임 통계의 예.

[domain@localhost:9990 /] /host=<host_name>/server=<server_name>/subsystem=ee/managed-scheduled-executor-service=default:read-resource(include-runtime=true,recursive=true)
Copy to Clipboard Toggle word wrap

10장. Undertow

10.1. Undertow Handler 소개

Undertow는 차단 작업 및 비차단 작업 모두에 사용하도록 설계된 웹 서버입니다. JBoss EAP 7에서 JBoss Web을 대체합니다. 일부 주요 기능은 다음과 같습니다.

  • 고성능
  • 임베딩 가능
  • Servlet 4.0
  • 웹 소켓
  • 역방향 프록시
라이프 사이클 요청

클라이언트가 서버에 연결하면 Undertow에서 a io.undertow.server.HttpServerConnection 을 생성합니다. 클라이언트에서 요청을 보내면 Undertow 구문 분석기에서 구문 분석한 다음 result io.undertow.server.HttpServerExchange 가 root 핸들러에 전달됩니다. root 핸들러가 완료되면 다음 네 가지 중 하나가 발생할 수 있습니다.

  • 교환이 완료됩니다.

    요청 및 응답 채널이 모두 완전히 읽거나 쓴 경우 교환은 완료된 것으로 간주됩니다. GET 및 HEAD와 같은 콘텐츠가 없는 요청의 경우 요청 측은 자동으로 완전히 읽은 것으로 간주됩니다. 핸들러가 전체 응답을 작성하고 응답 채널을 완전히 플러시한 경우 읽기 측면은 완전한 것으로 간주됩니다. 교환이 이미 완료된 경우에는 수행되지 않습니다.

  • 루트 핸들러는 교환을 완료하지 않고 정상적으로 반환됩니다.

    이 경우 HttpServerExchange.endExchange()를 호출하여 교환을 완료합니다.

  • root 핸들러가 Exception으로 반환됩니다.

    이 경우 응답 코드 500 이 설정되어 있으며 교환은 HttpServerExchange.endExchange()를 사용하여 종료됩니다.

  • 루트 핸들러는 HttpServerExchange.dispatch() 가 호출된 후 또는 비동기 IO가 시작된 후에 반환할 수 있습니다.

    이 경우 디스패치된 작업이 디스패치 실행자에 제출되거나 요청 또는 응답 채널에서 비동기 IO가 시작된 경우 이 작업이 시작됩니다. 두 경우 모두 교환이 완료되지 않습니다. 처리를 마칠 때 교환을 완료하는 것은 비동기 작업일 뿐입니다.

HttpServerExchange.dispatch() 를 가장 일반적으로 사용하는 것은 차단이 허용되지 않는 IO 스레드에서 실행을 차단할 수 있는 작업자 스레드로 이동하는 것입니다.

예제: 작업자 스레드로 디스패치

public void handleRequest(final HttpServerExchange exchange) throws Exception {
    if (exchange.isInIoThread()) {
      exchange.dispatch(this);
      return;
    }
    //handler code
}
Copy to Clipboard Toggle word wrap

호출 스택이 반환될 때까지 교환이 실제로 디스패치되지 않으므로 한 번에 둘 이상의 스레드가 교환에서 활성화되지 않도록 할 수 있습니다. 교환은 안전한 스레드가 아닙니다. 그러나 두 스레드가 한 번에 수정하지 않는 한 여러 스레드 간에 전달할 수 있습니다.

교환 종료

교환을 종료하는 방법에는 요청 채널을 완전히 읽고 응답 채널에서 shutdownWrites() 를 호출한 다음 HttpServerExchange.endExchange() 를 호출하여 교환을 종료할 수 있습니다. endExchange() 를 호출하면 Undertow는 콘텐츠가 아직 생성되었는지 확인합니다. 있는 경우 요청 채널을 드레이닝하고 응답 채널을 닫고 플러시합니다. 교환에 등록된 기본 응답 리스너가 없는 경우 Undertow는 각 응답에 기본 응답을 생성할 기회를 제공합니다. 이 메커니즘은 기본 오류 페이지가 생성되는 방법입니다.

Undertow 구성에 대한 자세한 내용은 JBoss EAP 구성 가이드에서 웹 서버 구성을 참조하십시오.

10.2. 배포에 기존 Undertow 핸들러 사용

Undertow는 JBoss EAP에 배포된 모든 애플리케이션과 함께 사용할 수 있는 기본 핸들러 세트를 제공합니다.

배포와 함께 핸들러를 사용하려면 WEB-INF/undertow-handlers.conf 파일을 추가해야 합니다.

예제: WEB-INF/undertow-handlers.conf 파일

allowed-methods(methods='GET')
Copy to Clipboard Toggle word wrap

모든 핸들러는 특정 경우에 해당 핸들러를 적용하기 위해 선택적 서술자를 사용할 수도 있습니다.

예제: 선택적 서술자를 사용한 WEB-INF/undertow-handlers.conf 파일

path('/my-path') -> allowed-methods(methods='GET')
Copy to Clipboard Toggle word wrap

위의 예제에서는 allowed-methods 핸들러만 경로 /my-path 에 적용합니다.

Undertow 핸들러 기본 매개변수

일부 핸들러에는 기본 매개 변수가 있습니다. 이 매개 변수는 이름을 사용하지 않고 핸들러 정의에서 해당 매개 변수의 값을 지정할 수 있습니다.

예제: 기본 매개 변수를 사용하여 WEB-INF/undertow-handlers.conf 파일

path('/a') -> redirect('/b')
Copy to Clipboard Toggle word wrap

하나 이상의 핸들러의 정의를 포함하도록 WEB-INF/jboss-web.xml 파일을 업데이트할 수도 있지만 WEB-INF/undertow-handlers.conf 를 사용하는 것이 좋습니다.

예제: WEB-INF/jboss-web.xml File

<jboss-web>
    <http-handler>
        <class-name>io.undertow.server.handlers.AllowedMethodsHandler</class-name>
        <param>
            <param-name>methods</param-name>
            <param-value>GET</param-value>
        </param>
    </http-handler>
</jboss-web>
Copy to Clipboard Toggle word wrap

제공된 Undertow 핸들러의 전체 목록은 Provided Undertow Handlers 참조에서 확인할 수 있습니다.

10.3. 사용자 정의 핸들러 생성

사용자 지정 핸들러를 정의하는 방법은 다음 두 가지가 있습니다.

WEB-INF/jboss-web.xml 파일을 사용하여 사용자 지정 핸들러 정의

사용자 지정 핸들러는 WEB-INF/jboss-web.xml 파일에 정의할 수 있습니다.

예제: WEB-INF/jboss-web.xml에서 사용자 지정 핸들러 정의

<jboss-web>
    <http-handler>
        <class-name>org.jboss.example.MyHttpHandler</class-name>
    </http-handler>
</jboss-web>
Copy to Clipboard Toggle word wrap

예제: HttpHandler Class

package org.jboss.example;

import io.undertow.server.HttpHandler;
import io.undertow.server.HttpServerExchange;

public class MyHttpHandler implements HttpHandler {
    private HttpHandler next;

    public MyHttpHandler(HttpHandler next) {
        this.next = next;
    }

    public void handleRequest(HttpServerExchange exchange) throws Exception {
        // do something
        next.handleRequest(exchange);
    }
}
Copy to Clipboard Toggle word wrap

WEB-INF/jboss-web.xml 파일을 사용하여 사용자 지정 핸들러에 대한 매개 변수를 설정할 수도 있습니다.

예제: WEB-INF/jboss-web.xml에서 매개 변수 정의

<jboss-web>
    <http-handler>
        <class-name>org.jboss.example.MyHttpHandler</class-name>
        <param>
            <param-name>myParam</param-name>
            <param-value>foobar</param-value>
        </param>
    </http-handler>
</jboss-web>
Copy to Clipboard Toggle word wrap

이러한 매개 변수가 작동하려면 핸들러 클래스에 해당 setter가 있어야 합니다.

예제: 핸들러에서 Setter 방법 정의

package org.jboss.example;

import io.undertow.server.HttpHandler;
import io.undertow.server.HttpServerExchange;

public class MyHttpHandler implements HttpHandler {
    private HttpHandler next;
    private String myParam;

    public MyHttpHandler(HttpHandler next) {
        this.next = next;
    }

    public void setMyParam(String myParam) {
        this.myParam = myParam;
    }

    public void handleRequest(HttpServerExchange exchange) throws Exception {
        // do something, use myParam
        next.handleRequest(exchange);
    }
}
Copy to Clipboard Toggle word wrap

WEB-INF/undertow-handlers.conf 파일에서 사용자 지정 핸들러 정의

핸들러를 정의하는 데 WEB-INF/jboss-web.xml 을 사용하는 대신 WEB-INF/undertow-handlers.conf 파일에 정의할 수도 있습니다.

myHttpHandler(myParam='foobar')
Copy to Clipboard Toggle word wrap

WEB-INF/undertow-handlers.conf 에 정의된 핸들러가 작동하려면 다음 두 가지를 만들어야 합니다.

  1. 해당 구문 비트 for undertow-handlers.conf 를 정의하는 HandlerBuilder 구현으로 HandlerWrapper 로 래핑된 HttpHandler 를 생성합니다.

    예제: HandlerBuilder 클래스

    package org.jboss.example;
    
    import io.undertow.server.HandlerWrapper;
    import io.undertow.server.HttpHandler;
    import io.undertow.server.handlers.builder.HandlerBuilder;
    
    import java.util.Collections;
    import java.util.Map;
    import java.util.Set;
    
    public class MyHandlerBuilder implements HandlerBuilder {
        public String name() {
            return "myHttpHandler";
        }
    
        public Map<String, Class<?>> parameters() {
            return Collections.<String, Class<?>>singletonMap("myParam", String.class);
        }
    
        public Set<String> requiredParameters() {
            return Collections.emptySet();
    
        }
    
        public String defaultParameter() {
            return null;
    
        }
    
        public HandlerWrapper build(final Map<String, Object> config) {
            return new HandlerWrapper() {
                public HttpHandler wrap(HttpHandler handler) {
                    MyHttpHandler result = new MyHttpHandler(handler);
                    result.setMyParam((String) config.get("myParam"));
                    return result;
                }
            };
        }
    }
    Copy to Clipboard Toggle word wrap

  2. 파일의 항목. META-INF/services/io.undertow.server.handlers.builder.HandlerBuilder. 이 파일은 WEB-INF/classes 와 같은 클래스 경로에 있어야 합니다.

    org.jboss.example.MyHandlerBuilder
    Copy to Clipboard Toggle word wrap

10.4. 사용자 정의 HTTP 메커니즘 개발

Elytron을 사용하여 웹 애플리케이션을 보호하는 경우 elytron 하위 시스템을 사용하여 등록할 수 있는 사용자 지정 HTTP 인증 메커니즘을 구현할 수 있습니다. 그러면 배포를 수정할 필요 없이 이 메커니즘을 사용하도록 배포 내의 구성을 재정의할 수도 있습니다.

중요

모든 사용자 지정 HTTP 메커니즘은 HttpServerAuthenticationMechanism 인터페이스를 구현하는 데 필요합니다.

일반적으로 HTTP 메커니즘의 경우 evaluateRequest 메서드는 HTTPServerRequest 오브젝트에서 전달되는 요청을 처리하는 데 호출됩니다. 메커니즘은 요청을 처리하고 요청에 있는 다음 콜백 방법 중 하나를 사용하여 결과를 나타냅니다.

  • authenticationComplete - 메커니즘이 요청을 인증했습니다.
  • authenticationFailed - 인증이 시도되었지만 실패했습니다.
  • Authentication InProgress - 인증이 시작되었지만 추가 왕복이 필요합니다.
  • badRequest - 이 메커니즘에 대한 인증이 요청 검증에 실패했습니다.
  • noAuthenticationInProgress - 메커니즘이 인증 단계를 시도하지 않았습니다.

HttpServerAuthenticationMechanism 인터페이스를 구현하는 사용자 지정 HTTP 메커니즘을 만든 후 다음 단계는 이 메커니즘의 인스턴스를 반환하는 팩토리를 생성하는 것입니다. 팩토리는 HttpAuthenticationFactory 인터페이스를 구현해야 합니다. 팩토리 구현에서 가장 중요한 단계는 요청된 메커니즘의 이름을 다시 확인하는 것입니다. 필요한 메커니즘을 생성할 수 없는 경우 팩토리에서 null을 반환하는 것이 중요합니다. 메커니즘 팩토리는 요청된 메커니즘을 생성할 수 있는지 여부를 결정하기 위해 전달된 맵의 속성을 고려할 수도 있습니다.

메커니즘 팩토리의 가용성을 알리는 데 사용할 수 있는 두 가지 다른 접근법이 있습니다.

  • 첫 번째 방법은 지원하는 각 메커니즘에 대해 사용 가능한 서비스로 등록된 HttpAuthenticationFactory 를 사용하여 java.security.Provider 를 구현하는 것입니다.
  • 두 번째 방법은 java.util.ServiceLoader 를 사용하여 대신 팩토리를 검색하는 것입니다. 이를 위해 META-INF/services 아래에 org.wildfly.security.http.HttpServerAuthenticationMechanismFactory 라는 파일을 추가해야 합니다. 이 파일에 필요한 유일한 콘텐츠는 팩토리 구현의 정규화된 클래스 이름입니다.

그러면 사용할 준비가 된 모듈로 이 메커니즘을 애플리케이션 서버에 설치할 수 있습니다.

module add --name=org.wildfly.security.examples.custom-http --resources=/path/to/custom-http-mechanism.jar --dependencies=org.wildfly.security.elytron,javax.api
Copy to Clipboard Toggle word wrap
사용자 지정 HTTP 메커니즘 사용
  1. 사용자 지정 모듈을 추가합니다.

    /subsystem=elytron/service-loader-http-server-mechanism-factory=custom-factory:add(module=org.wildfly.security.examples.custom-http)
    Copy to Clipboard Toggle word wrap
  2. http-authentication-factory 를 추가하여 메커니즘 팩토리를 인증에 사용할 보안 도메인에 연결합니다.

    /subsystem=elytron/http-authentication-factory=custom-mechanism:add(http-server-mechanism-factory=custom-factory,security-domain=ApplicationDomain,mechanism-configurations=[{mechanism-name=custom-mechanism}])
    Copy to Clipboard Toggle word wrap
  3. http -authentication-factory를 사용하도록 application-security- domain 리소스를 업데이트합니다.

    참고

    애플리케이션이 배포되면 기본적으로 other 보안 도메인을 사용합니다. 따라서 애플리케이션에 매핑을 추가하여 Elytron HTTP 인증 팩토리에 매핑해야 합니다.

    /subsystem=undertow/application-security-domain=other:add(http-authentication-factory=application-http-authentication)
    Copy to Clipboard Toggle word wrap

    이제 새 http -authentication-factory를 사용하도록 application-security- domain 리소스를 업데이트할 수 있습니다.

    /subsystem=undertow/application-security-domain=other:write-attribute(name=http-authentication-factory,value=custom-mechanism)
    
    /subsystem=undertow/application-security-domain=other:write-attribute(name=override-deployment-config,value=true)
    Copy to Clipboard Toggle word wrap

    위의 명령은 배포 구성을 덮어씁니다. 즉, 배포가 다른 메커니즘을 사용하도록 구성된 경우에도 http-authentication-factory 의 메커니즘이 사용됩니다. 따라서 배포 자체를 수정할 필요 없이 사용자 지정 메커니즘을 사용하도록 배포 내의 구성을 재정의할 수 있습니다.

  4. 서버를 다시 로드합니다

    reload
    Copy to Clipboard Toggle word wrap

11장. 자카르타 트랜잭션

11.1. 개요

11.1.1. 자카르타 트랜잭션 개요

소개

이 섹션에서는 자카르타 트랜잭션에 대한 기초적인 이해를 제공합니다.

11.2. 트랜잭션 개념

11.2.1. 트랜잭션 정보

트랜잭션은 두 개 이상의 작업으로 구성되며, 이 작업은 모두 성공하거나 모두 실패해야 합니다. 성공적인 결과는 커밋이며 실패한 결과는 롤백입니다. 롤백에서는 트랜잭션이 커밋을 시도하기 전에 각 멤버의 상태가 해당 상태로 돌아갑니다.

잘 설계된 트랜잭션의 일반적인 표준은 Atomic, Consistent, Isolated, Durable(ACID)입니다.

11.2.2. 트랜잭션의 ACID 속성 정보

ACID는 Atomicity,Consistency,Isolation, Durability를 나타내는 약어입니다 . 이 용어는 일반적으로 데이터베이스 또는 트랜잭션 작업의 맥락에서 사용됩니다.

원자성
트랜잭션이 원자성을 발휘하려면 모든 트랜잭션 구성원이 동일한 결정을 내려야 합니다. 모두 커밋하거나 모두 롤백합니다. 원자성이 손상되면 추론적 결과라고 하는 결과는 무엇입니까.
일관성
일관성은 데이터베이스에 기록된 데이터가 데이터베이스 스키마 측면에서 유효한 데이터로 보장됨을 의미합니다. 데이터베이스 또는 기타 데이터 소스는 항상 일관된 상태여야 합니다. 일관되지 않은 상태의 한 예로는 작업이 중단되기 전에 데이터의 절반이 기록되는 필드가 있습니다. 모든 데이터를 작성하거나 완료할 수 없는 경우 쓰기가 롤백된 경우 일관된 상태가 됩니다.
격리
격리는 트랜잭션에 의해 운영되는 데이터가 수정 전에 잠겨 트랜잭션 범위를 벗어난 프로세스가 데이터를 수정하지 못하도록 차단해야 함을 의미합니다.
지속성
지속성은 트랜잭션 멤버가 커밋하도록 지시한 후 외부 오류가 발생한 경우 모든 구성원이 실패가 해결되면 트랜잭션을 계속 커밋할 수 있음을 의미합니다. 이 오류는 하드웨어, 소프트웨어, 네트워크 또는 기타 관련 시스템과 관련이 있습니다.

11.2.3. 트랜잭션 코디네이터 또는 트랜잭션 관리자 정보

Transaction Coordinator 및 Transaction Manager ™라는 용어는 대부분 JBoss EAP와 트랜잭션 측면에서 교환할 수 있습니다. Transaction Coordinator라는 용어는 일반적으로 분산 JTS 트랜잭션 컨텍스트에서 사용됩니다.

자카르타 트랜잭션에서는 JBoss EAP 내에서 실행되며 2단계 커밋 프로토콜 중에 트랜잭션 참가자와 통신합니다.

집합을 통해 트랜잭션 참가자는 다른 트랜잭션 참가자의 결과에 따라 데이터를 커밋하거나 롤백할지 여부를 트랜잭션 참가자에게 알려줍니다. 이러한 방식으로 트랜잭션이 ACID 표준을 준수하는지 확인합니다.

11.2.4. 트랜잭션 참가자 정보

트랜잭션 참가자는 트랜잭션 내의 모든 리소스로, 커밋하거나 상태를 롤백할 수 있습니다. 일반적으로 데이터베이스 또는 자카르타 메시징 브로커이지만 트랜잭션 인터페이스를 구현하면 애플리케이션 코드가 트랜잭션 참여자 역할을 할 수도 있습니다. 트랜잭션의 각 참가자는 상태를 독립적으로 커밋하거나 롤백할 수 있는지 여부와 모든 참가자가 전체 트랜잭션을 성공적으로 커밋할 수 있는 경우에만 결정합니다. 그렇지 않으면 각 참가자가 해당 상태를 롤백하고 전체 트랜잭션이 실패합니다. more는 커밋 또는 롤백 작업을 조정하고 트랜잭션 결과를 결정합니다.

11.2.5. 자카르타 트랜잭션 정보

Jakarta Transactions는 Jakarta EE Spec의 일부입니다. 자카르타 트랜잭션 1.3 사양에 정의되어 있습니다.

Jakarta Transactions 구현은 JBoss EAP 애플리케이션 서버에 대한 Narayana 프로젝트에서 다룹니다. 그만큼 사용 된 애플리케이션이 단일 글로벌 트랜잭션을 통해 데이터베이스 또는 자카르타 메시징 브로커와 같은 다양한 리소스를 할당할 수 있습니다. 글로벌 트랜잭션을 XA 트랜잭션이라고 합니다. 일반적으로 XA 기능을 사용하는 리소스는 이러한 트랜잭션에 포함되어 있지만 XA 이외의 리소스도 글로벌 트랜잭션의 일부일 수 있습니다. XA가 아닌 리소스가 XA 지원 리소스 역할을 하는 데 도움이 되는 몇 가지 최적화가 있습니다. 자세한 내용은 LRCO Optimization for Single-phase Commit 을 참조하십시오.

이 문서에서 Jakarta Transactions라는 용어는 다음 두 가지를 나타냅니다.

  1. Jakarta Transactions - Jakarta EE 사양에 의해 정의됩니다.
  2. 이 값은 일반적으로 트랜잭션을 처리하는 방식을 나타냅니다.

복습은 자카르타 트랜잭션 모드에서 작동하고, 메모리에서 데이터를 공유하며, 트랜잭션 컨텍스트는 원격 Jakarta Enterprise Beans 호출에 의해 전송됩니다. 관리 트랜잭션 모드에서 CORBA(Common Object Request Broker Architecture) 메시지를 보내 데이터를 공유하고 IIOP 호출을 통해 트랜잭션 컨텍스트를 전송합니다. 두 모드 모두 여러 JBoss EAP 서버에 대한 트랜잭션 배포를 지원합니다.

11.2.6. JTS 정보

JTS는 OCS(Object Transaction Service)와 Jakarta의 매핑입니다. 자카르타 EE 애플리케이션은 자카르타 트랜잭션을 사용하여 트랜잭션을 관리합니다. 그런 다음 트랜잭션 관리자가 JTS 모드로 전환될 때 자카르타 트랜잭션은 오브젝트 트랜잭션 서비스 트랜잭션 구현과 상호 작용합니다. JTS는 IIOP 프로토콜을 통해 작동합니다. JTS를 사용하는 트랜잭션 관리자는 CORBA(Common Object Request Broker Architecture)라는 통신 표준을 사용하여 ORB(Object Request Broker)라는 프로세스를 사용하여 서로 통신합니다. 자세한 내용은 JBoss EAP 구성 가이드의 ORB 구성을 참조하십시오.

애플리케이션 관점에서 자카르타 트랜잭션을 사용하면 JTS 트랜잭션이 자카르타 트랜잭션과 동일한 방식으로 작동합니다.

참고

JBoss EAP에 포함된 JTS 구현은 분산 트랜잭션을 지원합니다. 완벽하게 호환되는 JTS 트랜잭션의 차이점은 외부 타사 ORB와의 상호 운용성입니다. 이 기능은 JBoss EAP에서 지원되지 않습니다. 지원되는 구성은 여러 JBoss EAP 컨테이너에만 트랜잭션을 분산합니다.

11.2.7. XML 트랜잭션 서비스 정보

XTS(XML Transaction Service) 구성 요소는 비즈니스 트랜잭션에서 프라이빗 및 퍼블릭 웹 서비스의 조정을 지원합니다. XTS를 사용하면 복잡한 비즈니스 트랜잭션을 제어 가능하고 안정적인 방식으로 조정할 수 있습니다. XTS API는 WS-Coordination, WS-Atomic Transaction 및 WS-Business Activity 프로토콜을 기반으로 트랜잭션 조정 모델을 지원합니다.

11.2.7.1. XTS에서 사용하는 프로토콜 개요

WS-C(Wss-Coordination) 사양은 클라이언트, 서비스 및 참가자 간의 작업을 조정하기 위해 다양한 조정 프로토콜을 연결하는 프레임워크를 정의합니다.

WS-T(Wss-Transaction) 프로토콜은 WS-C에서 제공하는 조정 프레임워크를 활용하는 트랜잭션 조정 프로토콜, WS-AT(WS-AT) 및 WS-Business Activity(WS-BA)의 쌍으로 구성됩니다. WS-T는 기존의 트랜잭션 처리 시스템을 통합하여 서로 안정적으로 통신할 수 있도록 개발되었습니다.

11.2.7.2. Web Services-Atomic Transaction Process

원자 트랜잭션(AT)은 ACID 의미 체계가 적절한 단기적 상호 작용을 지원하도록 설계되었습니다. AT 범위에서 웹 서비스는 일반적으로 브리징을 사용하여 WS-T의 제어 하에 데이터베이스 및 메시지 큐와 같은 XA 리소스에 액세스합니다. 트랜잭션이 종료되면 참가자는 AT의 결과를 XA 리소스에 전파하고 적절한 커밋 또는 롤백 작업이 각 참가자가 수행합니다.

11.2.7.2.1. 원자적 트랜잭션 프로세스
  1. 클라이언트 애플리케이션은 AT를 시작하기 위해 먼저 WS-T를 지원하는 WS-C Activation Coordinator 웹 서비스를 찾습니다.
  2. 클라이언트는 WS-C CreateCoordinationContext 메시지를 서비스에 전송하여 http://schemas.xmlsoap.org/ws/2004/10/wsat 를 조정 유형으로 지정합니다.
  3. 클라이언트는 활성화 서비스에서 적절한 WS-T 컨텍스트를 받습니다.
  4. CreateCoordinationContext 메시지에 대한 응답인 트랜잭션 컨텍스트의 CoordinationType 요소에는 WS-AT 네임스페이스 http://schemas.xmlsoap.org/ws/2004/10/wsat 설정된 CoordinationType 요소가 있습니다. 또한 참가자를 등록할 수 있는 원자 트랜잭션 코디네이터 엔드포인트인 WS-C Registration Service에 대한 참조가 포함되어 있습니다.
  5. 일반적으로 클라이언트는 웹 서비스를 호출하고 웹 서비스의 모든 변경 사항을 커밋하거나 다시 롤백하여 트랜잭션을 완료합니다. 이 완료를 촉진하기 위해 클라이언트는 조정 컨텍스트에서 엔드포인트가 반환된 등록 서비스에 레지스터 메시지를 전송하여 완료 프로토콜의 참가자로 등록해야 합니다.
  6. 완료를 위해 등록한 다음 클라이언트 애플리케이션은 웹 서비스와 상호 작용하여 비즈니스 수준 작업을 수행합니다. 비즈니스 웹 서비스를 호출할 때마다 클라이언트는 트랜잭션 컨텍스트를 SOAP 헤더 블록에 삽입하여 각 호출의 범위를 암시적으로 트랜잭션으로 지정합니다. WS-AT 인식 웹 서비스를 지원하는 툴킷은 SOAP 헤더 블록에 있는 컨텍스트와 백엔드 작업을 연결하는 기능을 제공합니다. 이렇게 하면 웹 서비스에서 수정한 내용이 클라이언트와 동일한 트랜잭션 범위 내에서 수행되고 트랜잭션 코디네이터가 커밋 또는 롤백할 수 있습니다.
  7. 필요한 모든 애플리케이션 작업이 완료되면 클라이언트는 서비스 상태를 영구적으로 변경하기 위해 트랜잭션을 종료할 수 있습니다. 완료 참가자는 코디네이터에 트랜잭션을 커밋하거나 롤백하도록 지시합니다. 커밋 또는 롤백 작업이 완료되면 상태가 참가자에게 반환되어 트랜잭션 결과를 나타냅니다.

자세한 내용은 Naryana 프로젝트 문서의 WS-Coordination 을 참조하십시오.

11.2.7.2.2. Microsoft .NET 클라이언트와의 WS-AT 상호 운용성

xts 하위 시스템은 WS-AT 사양의 .NET 구현의 차이로 인해 Microsoft .NET 클라이언트와 통신하는 데 문제가 있을 수 있습니다. WS-AT 사양의 .NET 구현은 모든 호출이 비동기식으로 강제 적용됩니다.

.NET 클라이언트와의 상호 운용성을 활성화하기 위해 JBoss EAP xts 하위 시스템에서 비동기 등록 옵션을 사용할 수 있습니다. XTS 비동기 등록은 기본적으로 비활성화되어 있으며 필요한 경우에만 활성화해야 합니다.

.NET 클라이언트와의 WS-AT 상호 운용성에 대해 비동기 등록을 활성화하려면 다음 관리 CLI 명령을 사용하십시오.

/subsystem=xts:write-attribute(name=async-registration, value=true)
Copy to Clipboard Toggle word wrap
11.2.7.3. Web Services-Business Activity Process

WS-BA(Web Services-Business Activity)는 기존의 비즈니스 처리 및 워크플로 시스템을 통해 독점형 메커니즘을 래핑하고 구현 및 비즈니스 경계에 걸쳐 상호 운용할 수 있는 웹 서비스 애플리케이션을 위한 프로토콜을 정의합니다.

참가자가 요청한 경우에만 트랜잭션 코디네이터에게 통보하는 WS-AT 프로토콜 모델과는 달리 WS-BA의 하위 활동은 요청을 기다리지 않고 코디네이터에 직접 결과를 지정할 수 있습니다. 참가자는 어떠한 시점에도 활동을 종료하거나 코디네이터에게 알리도록 선택할 수 있습니다. 이 기능은 트랜잭션이 끝날 때까지 기다리지 않고 알림을 사용하여 목표를 수정하고 처리를 추진할 수 있으므로 작업이 실패할 때 유용합니다.

11.2.7.3.1. WS-BA 프로세스
  1. 작업을 수행하기 위해 서비스가 요청됩니다.
  2. 이러한 서비스에는 작업을 실행 취소할 수 있는 기능이 있는 경우 WS-BA에 나중에 작업 취소를 결정할 경우 WS-BA에 알립니다. WS-BA에 오류가 발생하는 경우 서비스에 실행 취소 동작을 실행하도록 지시할 수 있습니다.

WS-BA 프로토콜은 보상 기반 트랜잭션 모델을 사용합니다. 비즈니스 활동에 참여하여 작업이 완료되면 해당 활동을 종료할 수 있습니다. 이 선택에서는 후속 롤백을 허용하지 않습니다. 또는 참가자가 활동을 완료하여 코디네이터에게 작업을 보완할 수 있다는 신호를 보낼 수 있으며, 나중에는 코디네이터에게 실패했음을 알릴 수 있습니다. 이 경우 코디네이터는 종료되지 않은 각 참가자에게 장애를 보상하도록 요청하여 적절한 보상 조치를 실행할 수 있는 기회를 제공합니다. 모든 참가자가 종료하거나 실패하지 않고 완료하면 코디네이터는 활동이 종료되었음을 통지합니다.

자세한 내용은 Naryana 프로젝트 문서의 WS-Coordination 을 참조하십시오.

11.2.7.4. 트랜잭션 브리징 개요

트랜잭션 브리징은 Jakarta EE 및 WS-T 도메인을 연결하는 프로세스를 설명합니다. 트랜잭션 브리지 구성 요소인 txbridge 는 두 가지 유형의 트랜잭션이 다른 유형과 사용하도록 설계된 비즈니스 로직을 포함할 수 있도록 양방향 연결을 제공합니다. 브리지에서 사용하는 기술은 상호 위치와 프로토콜 매핑의 조합입니다.

트랜잭션 브리지에서 교차 코디네이터는 기존 트랜잭션에 등록되고 프로토콜 매핑의 추가 작업을 수행합니다. 즉, 상위 코디네이터가 해당 상위 코디네이터가 네이티브 트랜잭션 유형의 리소스인 것처럼 보이는 반면 이러한 트랜잭션 유형이 다르더라도 자식이 네이티브 트랜잭션 유형의 코디네이터가 됩니다.

트랜잭션 브리지는 org.jboss.jbossts.txbridge 패키지 및 하위 패키지에 상주합니다. 각 방향으로 브리징을 위한 두 개의 개별 클래스 집합으로 구성됩니다.

자세한 내용은 Naryana 프로젝트 문서의 TXBridge Guide 를 참조하십시오.

11.2.8. XA 리소스 및 XA 트랜잭션 정보

XA는 X/Open Group에서 개발한 eXtended Architecture의 약어로, 둘 이상의 백엔드 데이터 저장소를 사용하는 트랜잭션을 정의합니다. XA 표준은 글로벌 GSM과 로컬 리소스 관리자 간의 인터페이스를 설명합니다. XA를 사용하면 애플리케이션 서버, 데이터베이스, 캐시 및 메시지 큐와 같은 여러 리소스가 동일한 트랜잭션에 참여하면서 4개의 ACID 속성을 모두 유지할 수 있습니다. 4개의 ACID 속성 중 하나는 원자성입니다. 즉, 참가자 중 한 명이 변경 사항을 커밋하지 못하면 다른 참가자가 트랜잭션을 중단하고 트랜잭션이 발생된 이전과 동일한 상태로 상태를 복원합니다. XA 리소스는 XA 글로벌 트랜잭션에 참여할 수 있는 리소스입니다.

XA 트랜잭션은 여러 리소스에 걸쳐 있는 트랜잭션입니다. 여기에는 하나 이상의 데이터베이스 또는 기타 트랜잭션 리소스가 있는 조정이 포함되며, 모두 단일 글로벌 XA 트랜잭션에 포함됩니다.

11.2.9. XA 복구 정보

07은 X/Open XA 사양을 구현하며 여러 XA 리소스에서 XA 트랜잭션을 지원합니다.

XA 복구는 트랜잭션 참여자가 충돌하거나 사용할 수 없게 되는 경우에도 트랜잭션의 영향을 받는 모든 리소스가 업데이트 또는 롤백되도록 하는 프로세스입니다. JBoss EAP의 범위 내에서 트랜잭션 하위 시스템은 XA 데이터 소스, 자카르타 메시징 메시지 대기열, 자카르타 커넥터 리소스 어댑터 등 모든 XA 리소스 또는 하위 시스템에 XA 복구 메커니즘을 제공합니다.

XA 복구는 사용자의 개입 없이 수행됩니다. XA 복구 오류가 발생하는 경우 로그 출력에 오류가 기록됩니다. 지원이 필요한 경우 Red Hat 글로벌 지원 서비스에 문의하십시오. XA 복구 프로세스는 2분마다 기본적으로 시작되는 주기적인 복구 스레드에 의해 구동됩니다. 주기적인 복구 스레드는 모두 완료되지 않은 트랜잭션을 처리합니다.

참고

I-doubt 트랜잭션의 복구를 완료하는 데 4~8분이 걸릴 수 있습니다. 복구 프로세스를 여러 번 실행해야 할 수 있기 때문입니다.

11.2.10. XA 복구 프로세스의 제한 사항

XA 복구에는 다음과 같은 제한 사항이 있습니다.

  • 성공적으로 커밋된 트랜잭션에서 트랜잭션 로그를 지우지 못할 수 있습니다.

    XAResource 커밋 메서드가 성공적으로 완료되고 트랜잭션을 커밋한 후 JBoss EAP 서버가 충돌하지만 코디네이터가 로그를 업데이트하기 전에 서버를 다시 시작할 때 로그에 다음 경고 메시지가 표시될 수 있습니다.

    ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord
    Copy to Clipboard Toggle word wrap

    이는 복구 시 JBoss Transaction Manager(TM)가 로그에서 트랜잭션 참가자를 확인하고 커밋을 다시 시도하기 때문입니다. 결국 JBoss는 리소스가 커밋되어 더 이상 커밋을 다시 시도하지 않는다고 가정합니다. 이 경우 트랜잭션이 커밋되고 데이터가 손실되지 않으므로 이 경고를 무시해도 됩니다.

    경고를 방지하려면 com.arspringa.ats.jta.xaAssume rescueyComplete 속성 값을 true로 설정합니다 . 이 속성은 새 XAResource 인스턴스가 등록된 XAResource recoveryy 인스턴스에서 찾을 수 없을 때마다 확인됩니다. true 로 설정하면 복구에서 이전 커밋 시도가 성공했다고 가정하고, 추가 복구 시도 없이 인스턴스가 로그에서 제거할 수 있다고 가정합니다. 이 속성은 전역적이며 잘못 사용되는 경우 커밋되지 않은 상태로 유지될 수 있으므로 주의해서 사용해야 합니다.

    참고

    JBoss EAP 7.4는 성공적으로 커밋된 트랜잭션 이후에 트랜잭션 로그를 지우기 위해 구현되었으며 위의 상황이 자주 발생하지 않아야 합니다.

  • XAResource.prepare() 끝에 서버가 충돌할 때 롤백은 JTS 트랜잭션에 대해 호출되지 않습니다.

    XAResource.prepare() 메서드 호출이 완료되면 JBoss EAP 서버가 충돌하는 경우 모든 참여 XAResource 인스턴스가 준비됨 상태로 잠겨 있으며 서버를 다시 시작할 때 이러한 방식으로 유지됩니다. 트랜잭션은 롤백되지 않으며 트랜잭션 시간이 초과되거나 데이터베이스 관리자가 수동으로 리소스를 롤백하고 트랜잭션 로그를 지울 때까지 리소스가 잠겨 있습니다. 자세한 내용은 https://issues.jboss.org/browse/JBTM-2124의 내용을 참조하십시오.

  • 커밋된 트랜잭션에 주기적인 복구가 발생할 수 있습니다.

    서버가 과도하게 로드되면 서버 로그에 다음 경고 메시지와 stacktrace가 포함될 수 있습니다.

    ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_NOTA: javax.transaction.xa.XAException
    Copy to Clipboard Toggle word wrap

    부하가 많으면 트랜잭션에서 수행한 처리 시간이 주기적인 복구 프로세스 활동 시간과 겹칠 수 있습니다. 주기적인 복구 프로세스는 여전히 트랜잭션이 진행 중인 것을 감지하고 롤백을 시작하려고 시도하지만 실제로 트랜잭션이 계속 완료됩니다. 현재 주기적인 복구 시도는 시도하지만 롤백에 실패하여 서버 로그에 롤백 실패를 기록합니다. 이 문제의 근본적인 원인은 향후 릴리스에서 해결될 예정이지만 당분간 해결방법을 사용할 수 있습니다.

    com.arspringa.ats.jta.orphanSafetyInterval 속성을 기본값 10000 밀리초보다 높은 값으로 설정하여 복구 프로세스의 두 단계 간 간격을 늘립니다. 40000 밀리초 값을 사용하는 것이 좋습니다. 이 경우 이 문제가 해결되지 않습니다. 대신 발생할 가능성을 줄이고 경고 메시지가 로그에 표시됩니다. 자세한 내용은 https://developer.jboss.org/thread/266729의 내용을 참조하십시오.

11.2.11. 2단계 커밋 프로토콜 정보

2-단계 커밋(2PC) 프로토콜은 트랜잭션 결과를 결정하는 알고리즘과 관련이 있습니다. 2PC는 XA 트랜잭션을 완료하는 프로세스로 TTM(Transaction Manager)에 의해 구동됩니다.

1단계: 준비

첫 번째 단계에서 트랜잭션 참가자는 트랜잭션 코디네이터가 트랜잭션을 커밋할 수 있는지 또는 롤백해야 하는지 여부를 알립니다.

2단계: 커밋

두 번째 단계에서 트랜잭션 코디네이터는 전체 트랜잭션을 커밋하거나 롤백해야 하는지 여부를 결정합니다. 참가자 중 한 명이라도 커밋할 수 없는 경우 트랜잭션을 롤백해야 합니다. 그렇지 않으면 트랜잭션을 커밋할 수 있습니다. 코디네이터는 수행할 작업에 대한 리소스를 지시하고 이를 완료하면 코디네이터에게 알립니다. 이 시점에서 트랜잭션이 완료됩니다.

11.2.12. 트랜잭션 시간 제한 정보

원자성을 유지하고 트랜잭션의 ACID 표준을 준수하기 위해 일부 트랜잭션 부분은 장기 실행이 가능합니다. 트랜잭션 참여자는 커밋 시 큐에서 데이터베이스 테이블 또는 메시지의 일부인 XA 리소스를 잠가야 합니다. 따라서 커밋 또는 롤백 여부를 지시하기 전에 각 트랜잭션 참가자로부터 다시 수신 대기해야 합니다. 하드웨어 또는 네트워크 오류로 인해 리소스가 무기한 잠길 수 있습니다.

트랜잭션 시간 초과를 트랜잭션과 연결하여 라이프사이클을 제어할 수 있습니다. 트랜잭션 커밋 또는 롤백 전에 시간 제한 임계값을 통과하면 시간 초과로 트랜잭션이 자동으로 롤백됩니다.

전체 트랜잭션 하위 시스템에 대한 기본 시간 제한 값을 구성하거나 기본 시간 초과 값을 비활성화하고 트랜잭션별로 시간 초과를 지정할 수 있습니다.

11.2.13. 분산 트랜잭션 정보

분산 트랜잭션은 여러 JBoss EAP 서버에 참가자가 있는 트랜잭션입니다. JTS 사양은 JTS 트랜잭션을 여러 벤더의 애플리케이션 서버에 배포할 수 있어야 한다고 규정합니다. 자카르타 트랜잭션은 이를 정의하지 않지만 JBoss EAP는 JBoss EAP 서버 간에 분산된 자카르타 트랜잭션을 지원합니다.

참고

여러 벤더의 서버 간 트랜잭션 배포는 지원되지 않습니다.

참고

다른 애플리케이션 서버 벤더 문서에서는 분산 트랜잭션이라는 용어가 XA 트랜잭션을 의미합니다. JBoss EAP 설명서의 컨텍스트에서 분산된 트랜잭션은 여러 JBoss EAP 애플리케이션 서버에 배포된 트랜잭션을 참조합니다. 다양한 리소스(예: 데이터베이스 리소스 및 자카르타 메시징 리소스)로 구성된 트랜잭션을 이 문서의 XA 트랜잭션이라고 합니다. 자세한 내용은 JTS 및 XA 데이터 소스 및 XA 트랜잭션 정보를 참조하십시오.

11.2.14. ORB Portability API 정보

ORB(오브젝트 요청 브로커)는 트랜잭션 참가자, 코디네이터, 리소스 및 여러 애플리케이션 서버에 분산된 기타 서비스에 메시지를 보내고 받는 프로세스입니다. ORB는 ITL(표준 인터페이스 설명 언어)을 사용하여 메시지를 통신하고 해석합니다. CORBA(Common Object Request Broker Architecture)는 JBoss EAP의 ORB에서 사용하는 IDL입니다.

ORB를 사용하는 주요 서비스는 JTS 사양을 사용하는 분산형 자카르타 트랜잭션의 시스템입니다. 다른 시스템, 특히 레거시 시스템은 remote Jakarta Enterprise Beans 또는 Jakarta Enterprise Web Services 또는 Jakarta RESTful Web Services와 같은 다른 메커니즘이 아닌 통신에 ORB 사용을 선택할 수 있습니다.

ORB Portability API는 ORB와 상호 작용하는 메커니즘을 제공합니다. 이 API는 ORB에 대한 참조를 얻는 방법과 ORB에서 들어오는 연결을 수신 대기하는 모드에 애플리케이션을 배치하는 방법을 제공합니다. API의 일부 메서드는 일부 ORB에서 지원되지 않습니다. 이 경우 예외가 발생합니다.

API는 다음 두 가지 클래스로 구성됩니다.

  • com.arjuna.orbportability.orb
  • com.arjuna.orbportability.oa

ORB Portability API에 포함된 메서드 및 속성에 대한 자세한 내용은 Red Hat 고객 포털에서 제공되는 JBoss EAP Javadocs 번들을 참조하십시오.

11.3. 트랜잭션 최적화

11.3.1. 트랜잭션 최적화 개요

JBoss EAP의 Transaction Manager(TM)에는 애플리케이션이 활용할 수 있는 몇 가지 최적화가 포함되어 있습니다.

최적화는 특히 2단계 커밋 프로토콜을 개선하기 위한 서비스를 제공합니다. 일반적으로 는 글로벌 트랜잭션을 시작하며, 이는 2-단계 커밋을 통과합니다. 그러나 이러한 트랜잭션을 최적화할 때, 특정 상황에서는 전체 2단계 커밋을 진행하지 않아도 되므로 프로세스가 빨라집니다.

에서 사용하는 다른 최적화는 아래에 자세히 설명되어 있습니다.

11.3.2. 단일 단계 커밋을 위한 LRCO 최적화 정보(1PC)

단일 단계 커뮤니티(1PC)

2단계 커밋 프로토콜(2PC)이 트랜잭션에서 더 일반적으로 발생하지만 일부 상황에는 두 단계 모두 필요하지 않거나 수용할 수 없습니다. 이 경우 단일 단계 커밋(1PC) 프로토콜을 사용할 수 있습니다. 단일 단계 통신 프로토콜은 하나의 XA 또는 비 XA 리소스만 글로벌 트랜잭션의 일부인 경우에만 사용됩니다.

준비 단계는 일반적으로 두 번째 단계가 처리될 때까지 리소스를 잠급니다. 단일 단계 커밋은 준비 단계를 건너뛰고 리소스에서 커밋만 처리됩니다. 지정하지 않으면 글로벌 트랜잭션에 참가자가 한 명만 포함된 경우 단일 단계 커밋 최적화가 자동으로 사용됩니다.

마지막 리소스 커밋 최적화 (LRCO)

XA 트랜잭션에 비 XA 데이터 소스가 참여하는 경우 LRCO(마지막 리소스 커밋 최적화)라고 알려진 최적화가 사용됩니다. 이 프로토콜을 사용하면 대부분의 트랜잭션이 정상적으로 완료될 수 있지만, 특정 유형의 오류로 인해 일관되지 않은 트랜잭션 결과가 발생할 수 있습니다. 따라서 이 접근 방식을 마지막 수단으로만 사용하십시오.

비 XA 리소스는 준비 단계 종료 시 처리되며 이를 커밋하기 위한 시도가 수행됩니다. 커밋이 성공하면 트랜잭션 로그가 작성되고 나머지 리소스는 커밋 단계를 거칩니다. 마지막 리소스를 커밋하지 못하면 트랜잭션이 롤백됩니다.

트랜잭션에서 단일 로컬 TX 데이터 소스를 사용하는 경우 LRCO가 자동으로 적용됩니다.

이전에는 LRCO 방법을 통해 XA 트랜잭션에 비 XA 리소스를 추가할 수 있었습니다. 그러나 LRCO에는 오류 창이 있습니다. LRCO 방법을 사용하여 XA 트랜잭션에 비 XA 리소스를 추가하는 절차는 다음과 같습니다.

  1. XA 트랜잭션을 준비합니다.
  2. LRCO 커밋.
  3. 트랜잭션 로그를 작성합니다.
  4. XA 트랜잭션을 커밋합니다.

절차가 2단계와 3단계 사이에 충돌하면 데이터 불일치로 이어질 수 있으며 XA 트랜잭션을 커밋할 수 없습니다. 데이터는 LRCO 비 XA 리소스가 커밋되었지만 XA 리소스 준비에 대한 정보는 기록되지 않았기 때문입니다. 복구 관리자는 서버가 가동된 후 리소스를 롤백합니다. CMR(커밋 표시 가능 리소스)은 이 제한을 제거하고 XA 트랜잭션에 비 XA 리소스를 안정적으로 열거할 수 있도록 합니다.

참고

CMR은 데이터 소스에만 사용해야 하는 LRCO 최적화의 특별한 사례입니다. XA가 아닌 모든 리소스에는 적합하지 않습니다.

11.3.2.1. 표시 가능한 리소스 커밋
요약

CMR(커밋 Markable Resource) 인터페이스를 사용하여 리소스 관리자에 대한 액세스를 구성하면 XA(2PC) 트랜잭션에 XA가 아닌 데이터 소스에 안정적으로 열거할 수 있습니다. XA 이외의 리소스를 완전히 복구할 수 있도록 하는 LRCO 알고리즘 구현입니다.

CMR을 구성하려면 다음을 수행해야 합니다.

  1. 데이터베이스에 테이블 만들기.
  2. 연결할 수 있도록 데이터 소스를 활성화합니다.
  3. 트랜잭션 하위 시스템에 참조를 추가합니다.
데이터베이스에서 테이블 만들기

트랜잭션에는 하나의 CMR 리소스만 포함될 수 있습니다. 다음 예제와 유사한 SQL을 사용하여 테이블을 생성할 수 있습니다.

SELECT xid,actionuid FROM _tableName_ WHERE transactionManagerID IN (String[])
DELETE FROM _tableName_ WHERE xid IN (byte[[]])
INSERT INTO _tableName_ (xid, transactionManagerID, actionuid) VALUES (byte[],String,byte[])
Copy to Clipboard Toggle word wrap

다음은 다양한 데이터베이스 관리 시스템의 테이블을 생성하는 SQL 구문의 예입니다.

예제: Sybase 테이블 구문 생성

CREATE TABLE xids (xid varbinary(144), transactionManagerID varchar(64), actionuid varbinary(28))
Copy to Clipboard Toggle word wrap

예제: Oracle Create Table Syntax

CREATE TABLE xids (xid RAW(144), transactionManagerID varchar(64), actionuid RAW(28))
CREATE UNIQUE INDEX index_xid ON xids (xid)
Copy to Clipboard Toggle word wrap

예제: IBM Create Table Syntax

CREATE TABLE xids (xid VARCHAR(255) for bit data not null, transactionManagerID
varchar(64), actionuid VARCHAR(255) for bit data not null)
CREATE UNIQUE INDEX index_xid ON xids (xid)
Copy to Clipboard Toggle word wrap

예제: SQL Server Create Table Syntax

CREATE TABLE xids (xid varbinary(144), transactionManagerID varchar(64), actionuid varbinary(28))
CREATE UNIQUE INDEX index_xid ON xids (xid)
Copy to Clipboard Toggle word wrap

예제: PostgreSQL Create Table Syntax

CREATE TABLE xids (xid bytea, transactionManagerID varchar(64), actionuid bytea)
CREATE UNIQUE INDEX index_xid ON xids (xid)
Copy to Clipboard Toggle word wrap

예제: MariaDB 테이블 구문 생성

CREATE TABLE xids (xid BINARY(144), transactionManagerID varchar(64), actionuid BINARY(28))
CREATE UNIQUE INDEX index_xid ON xids (xid)
Copy to Clipboard Toggle word wrap

예제: MySQL Create Table Syntax

CREATE TABLE xids (xid VARCHAR(255), transactionManagerID varchar(64), actionuid VARCHAR(255))
CREATE UNIQUE INDEX index_xid ON xids (xid)
Copy to Clipboard Toggle word wrap

연결할 수 있는 데이터 소스 활성화

기본적으로 데이터 소스에 대해 CMR 기능이 비활성화되어 있습니다. 이를 활성화하려면 데이터 소스 구성을 생성하거나 수정하고 연결 가능한 특성이 true 로 설정되어 있는지 확인해야 합니다. 다음은 서버 XML 구성 파일의 데이터 소스 섹션의 예입니다.

<datasource enabled="true" jndi-name="java:jboss/datasources/ConnectableDS" pool-name="ConnectableDS" jta="true" use-java-context="true" connectable="true"/>
Copy to Clipboard Toggle word wrap
참고

이 기능은 XA 데이터 소스에는 적용되지 않습니다.

다음과 같이 관리 CLI를 사용하여 CMR로 리소스 관리자를 활성화할 수도 있습니다.

/subsystem=datasources/data-source=ConnectableDS:add(enabled="true", jndi-name="java:jboss/datasources/ConnectableDS", jta="true", use-java-context="true", connectable="true", connection-url="validConnectionURL", exception-sorter-class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter", driver-name="mssql")
Copy to Clipboard Toggle word wrap

이 명령은 서버 구성 파일의 데이터 소스 섹션에 다음 XML을 생성합니다.

<datasource jta="true" jndi-name="java:jboss/datasources/ConnectableDS" pool-name="ConnectableDS" enabled="true" use-java-context="true" connectable="true">
  <connection-url>validConnectionURL</connection-url>
  <driver>mssql</driver>
  <validation>
    <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter"/>
  </validation>
</datasource>
Copy to Clipboard Toggle word wrap
참고

데이터 소스에 유효한 드라이버가 정의되어 있어야 합니다. 위의 예제에서는 mssqldriver-name 으로 사용하지만 mssql 드라이버는 존재하지 않습니다. 자세한 내용은 JBoss EAP 구성 가이드 의 MySQL 데이터 소스 예제 를 참조하십시오.

참고

데이터 소스 구성에서 exception-sorter-class-name 매개변수를 사용합니다. 자세한 내용은 JBoss EAP 구성 가이드의 데이터 소스 구성 예제 를 참조하십시오.

새로운 CMR 기능을 사용하도록 기존 리소스 업데이트

CMR 기능을 사용하도록 기존 데이터 소스만 업데이트해야 하는 경우 연결 가능한 속성을 수정하면 됩니다.

/subsystem=datasources/data-source=ConnectableDS:write-attribute(name=connectable,value=true)
Copy to Clipboard Toggle word wrap
Transactions 하위 시스템에 참조 추가

트랜잭션 하위 시스템은 아래와 같이 트랜잭션 하위 시스템 구성 섹션의 항목을 통해 CMR이 가능한 데이터 소스를 식별합니다.

<subsystem xmlns="urn:jboss:domain:transactions:5.0">
    ...
    <commit-markable-resources>
        <commit-markable-resource jndi-name="java:jboss/datasources/ConnectableDS">
            <xid-location name="xids" batch-size="100" immediate-cleanup="false"/>
        </commit-markable-resource>
        ...
    </commit-markable-resources>
</subsystem>
Copy to Clipboard Toggle word wrap

관리 CLI를 사용하여 동일한 결과를 얻을 수 있습니다.

/subsystem=transactions/commit-markable-resource=java\:jboss\/datasources\/ConnectableDS/:add(batch-size=100,immediate-cleanup=false,name=xids)
Copy to Clipboard Toggle word wrap
참고

트랜잭션 하위 시스템에서 CMR 참조를 추가한 후 서버를 다시 시작해야 합니다.

11.3.3. Presumed-Abort Optimization 정보

트랜잭션이 롤백될 경우 이 정보를 로컬로 기록하고 모든 등록 참가자에게 알릴 수 있습니다. 이 알림은 유의 사항일 뿐이며 트랜잭션 결과에는 영향을 미치지 않습니다. 모든 참가자에게 연락한 후 트랜잭션에 대한 정보를 제거할 수 있습니다.

트랜잭션 상태에 대한 후속 요청이 발생하면 사용 가능한 정보가 없습니다. 이 경우 요청자는 트랜잭션이 중단되고 롤백되었다고 가정합니다. 이러한 가정적 최적화는 트랜잭션이 커밋될 때까지 참가자에 대한 정보를 유지할 필요가 없음을 의미합니다. 이 시점 이전의 실패가 트랜잭션이 중단된 것으로 간주되기 때문입니다.

11.3.4. 읽기 전용 최적화 정보

참가자가 준비를 요청하면 코디네이터에서 트랜잭션 중에 데이터를 수정하지 않았음을 나타낼 수 있습니다. 참가자가 거래 결과에 영향을 주지 않으므로 이러한 참가자는 트랜잭션 결과에 대해 알 필요가 없습니다. 이 읽기 전용 참가자는 커밋 프로토콜의 두 번째 단계에서 생략할 수 있습니다.

11.4. 트랜잭션 결과

11.4.1. 트랜잭션 아웃 정보

트랜잭션에는 다음 세 가지 결과가 있습니다.

커밋
모든 트랜잭션 참가자가 커밋할 수 있는 경우 트랜잭션 코디네이터에서 해당 작업을 수행하도록 지시합니다. 자세한 내용은 Transaction Commit 정보를 참조하십시오.
롤백
트랜잭션 참가자가 커밋할 수 없거나 트랜잭션 코디네이터가 참가자에게 커밋하도록 지시할 수 없는 경우 트랜잭션이 롤백됩니다. 자세한 내용은 트랜잭션 롤백 정보를 참조하십시오.
복구 결과
일부 트랜잭션 참가자가 커밋하고 다른 트랜잭션을 롤백하는 경우 추론적인 결과라고 합니다. 추론적 결과에는 사람의 개입이 필요합니다. 자세한 내용은 Heuristic Outcomes 를 참조하십시오.

11.4.2. 트랜잭션 커밋 정보

트랜잭션 참가자가 커밋하면 새 상태가 지속됩니다. 트랜잭션과 관련된 작업을 수행하는 참가자가 새 상태를 생성합니다. 가장 일반적인 예는 트랜잭션 멤버가 데이터베이스에 레코드를 쓸 때입니다.

커밋 후 트랜잭션 코디네이터에서 트랜잭션에 대한 정보가 제거되고 새로 작성된 상태가 이제 지속적 상태가 됩니다.

11.4.3. 트랜잭션 롤백 정보

트랜잭션 참가자는 트랜잭션이 시작되기 전에 상태를 반영하도록 해당 상태를 복원하여 롤백합니다. 롤백 후 상태는 트랜잭션이 시작되지 않은 경우와 동일합니다.

11.4.4. Heuristic Outcomes 정보

추론적 결과 또는 비원형 결과는 트랜잭션의 참가자의 결정이 트랜잭션 관리자의 결정과 다른 상황입니다. 복구로 인해 시스템에 대한 무결성이 손실될 수 있으며, 일반적으로 문제를 해결하기 위해 사람의 개입이 필요합니다. 여기에 의존하는 코드를 작성하지 마십시오.

일반적으로 복구 결과는 2-단계 커밋(2PC) 프로토콜의 두 번째 단계에서 발생합니다. 드물지만 이 결과는 1PC에서 발생할 수 있습니다. 이러한 문제는 주로 기본 서버의 기본 하드웨어 또는 통신 하위 시스템에 장애가 발생하기 때문입니다.

트랜잭션 관리자 및 전체 충돌 복구를 통해서도 다양한 하위 시스템 또는 리소스의 시간 초과로 인해 복구가 가능합니다. 일부 형태의 분산 계약이 필요한 모든 시스템에서는 시스템의 일부가 글로벌 결과의 관점에서 다양해지는 상황에서 발생할 수 있습니다.

다음과 같은 네 가지 유형의 추론 결과가 있습니다.

heuristic rollback

커밋 작업은 리소스를 커밋할 수 없었지만 모든 참가자가 롤백할 수 있었기 때문에 원자적 결과가 계속 달성되었습니다.

Huristic 커밋

모든 참가자가 단독으로 커밋되었기 때문에 시도한 롤백 작업이 실패했습니다. 예를 들어 코디네이터가 트랜잭션을 성공적으로 준비할 수 있지만 로그 업데이트 실패와 같은 측면의 실패로 인해 롤백하기로 결정하는 경우 발생할 수 있습니다. 참여자들이 약속하기로 결정할 수도 있습니다.

heuristic 혼합

일부 참가자는 약속하고 다른 참가자도 롤백했습니다.

추론적 위험

일부 업데이트의 배치는 알 수 없습니다. 알려진 사람들에게는 모두 커밋되었거나 모두 롤백되어 있습니다.

11.4.5. JBoss Transactions 오류 및 예외

UserTransaction 클래스 메서드에 의해 throw된 예외에 대한 자세한 내용은 UserTransaction API Javadoc를 참조하십시오.

11.5. 트랜잭션 라이프 사이클 개요

11.5.1. 트랜잭션 라이프 사이클

자카르타 트랜잭션에 대한 자세한 내용은 자카르타 트랜잭션 정보를 참조하십시오.

리소스가 트랜잭션에 참여하도록 요청하면 일련의 이벤트가 동작에 설정됩니다. Transaction Manager(TM)는 애플리케이션 서버 내에 있으며 트랜잭션을 관리하는 프로세스입니다. 트랜잭션 참가자는 트랜잭션에 참여하는 객체입니다. 리소스는 데이터 소스, Jakarta Messaging 연결 팩토리 또는 기타 Jakarta Connectors 연결입니다.

  1. 애플리케이션이 새 트랜잭션을 시작합니다.

    트랜잭션을 시작하기 위해 애플리케이션은 Java Naming and Directory Interface에서 또는 주석에서 Jakarta Enterprise Bean인 경우 UserTransaction 클래스 인스턴스를 가져옵니다. UserTransaction 인터페이스에는 최상위 트랜잭션을 시작, 커밋 및 롤백하는 방법이 포함되어 있습니다. 새로 생성된 트랜잭션은 호출 스레드와 자동으로 연결됩니다. 자카르타 트랜잭션에서는 중첩 트랜잭션이 지원되지 않으므로 모든 트랜잭션은 최상위 트랜잭션입니다.

    Jakarta Enterprise Bean은 UserTransaction.begin() 메서드가 호출될 때 트랜잭션을 시작합니다. 이 트랜잭션의 기본 동작은 TransactionAttribute 주석 또는 ejb.xml 설명자를 사용하여 영향을 받을 수 있습니다. 해당 지점 다음에 사용되는 모든 리소스는 트랜잭션과 연결됩니다. 둘 이상의 리소스가 등록되면 트랜잭션이 XA 트랜잭션이 되고 커밋 시 2단계 커밋 프로토콜에 참여합니다.

    참고

    기본적으로 트랜잭션은 자카르타 엔터프라이즈 빈의 애플리케이션 컨테이너에 의해 구동됩니다. 이를 CMT (컨테이너 관리 트랜잭션)라고 합니다. 트랜잭션 사용자가 구동되도록 하려면 트랜잭션 관리를 BMT(빈 관리 트랜잭션)로 변경합니다. BMT에서는 사용자가 트랜잭션을 관리하는 데 UserTransaction 개체를 사용할 수 있습니다.

  2. 애플리케이션은 상태를 수정합니다.

    다음 단계에서는 애플리케이션이 작업을 수행하고 등록한 리소스에서만 해당 상태를 변경합니다.

  3. 애플리케이션에서 커밋 또는 롤백을 결정합니다.

    애플리케이션에서 상태 변경을 완료하면 커밋 또는 롤백 여부를 결정합니다. UserTransaction.commit() 또는 UserTransaction.rollback() 중 하나를 적절한 메서드를 호출합니다. CMT의 경우 이 프로세스는 자동으로 구동되는 반면 BMT의 경우 UserTransaction 의 메서드 커밋 또는 롤백은 명시적으로 호출해야 합니다.

  4. ©는 해당 레코드에서 트랜잭션을 제거합니다.

    커밋 또는 롤백이 완료된 후 HFS는 레코드를 정리하고 트랜잭션에 대한 정보를 트랜잭션 로그에서 제거합니다.

실패 복구

리소스, 트랜잭션 참여자 또는 애플리케이션 서버를 충돌하거나 사용할 수 없게 되면 트랜잭션 관리자는 기본 오류가 해결되고 리소스를 다시 사용할 수 있을 때 복구를 처리합니다. 이 프로세스는 자동으로 수행됩니다. 자세한 내용은 XA 복구를 참조하십시오.

11.6. 트랜잭션 하위 시스템 구성

트랜잭션 하위 시스템을 사용하면 통계, 시간 제한 값, 트랜잭션 로깅과 같은 트랜잭션 관리자 옵션을 구성할 수 있습니다. 트랜잭션을 관리하고 트랜잭션 통계를 볼 수도 있습니다.

자세한 내용은 JBoss EAP 구성 가이드에서 트랜잭션 구성을 참조하십시오.

11.7. 실제 트랜잭션 사용

11.7.1. 트랜잭션 사용 개요

다음 절차는 애플리케이션에서 트랜잭션을 사용해야 하는 경우에 유용합니다.

11.7.2. 제어 트랜잭션

소개

이 절차 목록은 Jakarta Transactions API를 사용하는 애플리케이션에서 트랜잭션을 제어하는 다양한 방법을 간략하게 설명합니다.

11.7.2.1. 트랜잭션 시작

다음 절차에서는 새 트랜잭션을 시작하는 방법을 설명합니다. Jakarta Transactions 또는 JTS로 구성된 Transaction Manager ™를 실행할 때 API가 동일합니다.

  1. UserTransaction 인스턴스 가져오기.

    Jakarta Enterprise Beans가 @TransactionManagement(TransactionManagementType.BEAN) 주석을 통해 빈 관리 트랜잭션을 사용하는 경우 Java Naming 및 Directory Interface, injection 또는 Jakarta Enterprise Beans 컨텍스트를 사용하여 인스턴스를 가져올 수 있습니다.

    • Java 네이밍 및 디렉터리 인터페이스를 사용하여 인스턴스를 가져옵니다.

      new InitialContext().lookup("java:comp/UserTransaction")
      Copy to Clipboard Toggle word wrap
    • 삽입을 사용하여 인스턴스를 가져옵니다.

      @Resource UserTransaction userTransaction;
      Copy to Clipboard Toggle word wrap
    • Jakarta Enterprise Beans 컨텍스트를 사용하여 인스턴스를 가져옵니다.

      • 상태 비저장/상태 저장 빈에서 다음을 수행합니다.

        @Resource SessionContext ctx;
        ctx.getUserTransaction();
        Copy to Clipboard Toggle word wrap
      • 메시지 기반 빈에서:

        @Resource MessageDrivenContext ctx;
        ctx.getUserTransaction()
        Copy to Clipboard Toggle word wrap
  2. 데이터 소스에 연결한 후 UserTransaction.begin() 을 호출합니다.

    try {
        System.out.println("\nCreating connection to database: "+url);
        stmt = conn.createStatement();  // non-tx statement
        try {
            System.out.println("Starting top-level transaction.");
            userTransaction.begin();
            stmtx = conn.createStatement(); // will be a tx-statement
            ...
        }
    }
    Copy to Clipboard Toggle word wrap

결과

트랜잭션이 시작됩니다. 데이터 소스의 모든 용도는 트랜잭션을 커밋하거나 롤백할 때까지 트랜잭션입니다.

전체 예는 Jakarta Transactions 트랜잭션 예제 를 참조하십시오.

참고

Jakarta Enterprise Beans(CMT 또는 BMT와 함께 사용됨)의 이점 중 하나는 컨테이너가 트랜잭션 처리의 모든 내부를 관리한다는 것입니다. 즉, JBoss EAP 컨테이너 간에 XA 트랜잭션 또는 트랜잭션 배포의 일부인 트랜잭션을 관리할 수 있다는 것입니다.

11.7.2.1.1. 중첩 트랜잭션

중첩 트랜잭션을 사용하면 애플리케이션에서 기존 트랜잭션에 포함된 트랜잭션을 생성할 수 있습니다. 이 모델에서는 여러 하위 트랜잭션을 트랜잭션에 반복적으로 포함할 수 있습니다. 하위 트랜잭션은 상위 트랜잭션을 커밋하거나 롤백하지 않고 커밋하거나 롤백할 수 있습니다. 그러나 커밋 작업의 결과는 모든 트랜잭션의 상위에 대한 약속에 따릅니다.

구현 관련 정보는 Narayana 프로젝트 설명서 를 참조하십시오.

중첩 트랜잭션은 JTS 사양과 함께 사용하는 경우에만 사용할 수 있습니다. 중첩 트랜잭션은 JBoss EAP 애플리케이션 서버의 지원 기능이 아닙니다. 또한 많은 데이터베이스 벤더가 중첩 트랜잭션을 지원하지 않으므로 중첩 트랜잭션을 추가하기 전에 데이터베이스 벤더에게 문의하십시오.

11.7.2.2. 트랜잭션 커밋

다음 절차에서는 자카르타 트랜잭션을 사용하여 트랜잭션을 커밋하는 방법을 설명합니다.

사전 요구 사항

트랜잭션을 커밋하려면 먼저 트랜잭션을 시작해야 합니다. 트랜잭션을 시작하는 방법에 대한 자세한 내용은 트랜잭션 시작을 참조하십시오.

  1. UserTransaction 에서 commit() 메서드를 호출합니다.

    UserTransaction 에서 commit() 메서드를 호출하면 ->에서 트랜잭션을 커밋합니다.

    @Inject
    private UserTransaction userTransaction;
    
    public void updateTable(String key, String value) {
        EntityManager entityManager = entityManagerFactory.createEntityManager();
        try {
            userTransaction.begin();
            <!-- Perform some data manipulation using entityManager -->
            ...
            // Commit the transaction
            userTransaction.commit();
        } catch (Exception ex) {
            <!-- Log message or notify Web page -->
            ...
            try {
                userTransaction.rollback();
            } catch (SystemException se) {
                throw new RuntimeException(se);
            }
            throw new RuntimeException(ex);
        } finally {
            entityManager.close();
        }
    }
    Copy to Clipboard Toggle word wrap
  2. CMT(컨테이너 관리 트랜잭션)를 사용하는 경우 수동으로 커밋할 필요가 없습니다.

    컨테이너 관리 트랜잭션을 사용하도록 빈을 구성하는 경우 컨테이너는 코드에서 구성하는 주석을 기반으로 사용자의 트랜잭션 라이프사이클을 관리합니다.

    @PersistenceContext
    private EntityManager em;
    
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void updateTable(String key, String value)
      <!-- Perform some data manipulation using entityManager -->
      ...
    }
    Copy to Clipboard Toggle word wrap

결과

데이터 소스 커밋 및 트랜잭션이 종료되거나 예외가 발생합니다.

참고

전체 예는 Jakarta Transactions 트랜잭션 예제 를 참조하십시오.

11.7.2.3. 트랜잭션 롤백

다음 절차에서는 자카르타 트랜잭션을 사용하여 트랜잭션을 롤백하는 방법을 설명합니다.

사전 요구 사항

트랜잭션을 롤백하려면 먼저 트랜잭션을 시작해야 합니다. 트랜잭션을 시작하는 방법에 대한 자세한 내용은 트랜잭션 시작을 참조하십시오.

  1. UserTransaction 에서 rollback() 메서드를 호출합니다.

    UserTransaction 에서 rollback() 메서드를 호출할 때 4.6은 트랜잭션을 롤백하고 데이터를 이전 상태로 되돌립니다.

    @Inject
    private UserTransaction userTransaction;
    
    public void updateTable(String key, String value)
        EntityManager entityManager = entityManagerFactory.createEntityManager();
        try {
            userTransaction.begin():
            <!-- Perform some data manipulation using entityManager -->
              ...
              // Commit the transaction
            userTransaction.commit();
        } catch (Exception ex) {
            <!-- Log message or notify Web page -->
            ...
            try {
                userTransaction.rollback();
            } catch (SystemException se) {
                throw new RuntimeException(se);
            }
            throw new RuntimeException(e);
        } finally {
            entityManager.close();
        }
    }
    Copy to Clipboard Toggle word wrap
  2. CMT(컨테이너 관리 트랜잭션)를 사용하는 경우 트랜잭션을 수동으로 롤백할 필요가 없습니다.

    컨테이너 관리 트랜잭션을 사용하도록 빈을 구성하는 경우 컨테이너는 코드에서 구성하는 주석을 기반으로 사용자의 트랜잭션 라이프사이클을 관리합니다.

참고

RuntimeException이 throw되면 CMT의 롤백이 발생합니다. setRollbackOnly 메서드를 명시적으로 호출하여 롤백을 얻을 수도 있습니다. 또는 롤백하려면 애플리케이션 예외에 @ApplicationException(rollback=true)을 사용합니다.

결과

귀하의 트랜잭션이 자동으로 롤백됩니다.

참고

전체 예는 Jakarta Transactions 트랜잭션 예제 를 참조하십시오.

11.7.3. 트랜잭션에서 Heuristic Outcome 처리

추론적 트랜잭션 결과는 드물지만 일반적으로 특별한 원인을 갖습니다. 추론적이라는 단어는 "직접"을 의미하며, 일반적으로 이러한 결과를 처리해야 하는 방식입니다. 추론적 거래 결과에 대한 자세한 내용은 Heuristic Outcomes 를 참조하십시오.

다음 절차에서는 Jakarta 트랜잭션을 사용하여 트랜잭션의 복구 결과를 처리하는 방법을 설명합니다.

  1. 트랜잭션 결과의 원인은 리소스 관리자가 커밋하거나 롤백할 수 있다고 약속한 다음 약속을 이행하지 못하기 때문입니다. 이는 타사 구성 요소, 타사 구성 요소와 JBoss EAP 간의 통합 계층 문제 또는 JBoss EAP 자체에 문제가 될 수 있습니다.

    지금까지 가장 일반적인 복구 오류의 원인은 환경에 일시적인 오류와 리소스 관리자를 처리하는 코딩 오류입니다.

  2. 일반적으로 환경에 일시적인 오류가 있는 경우 복구 오류를 확인하기 전에 이를 알 수 있습니다. 이는 네트워크 중단, 하드웨어 오류, 데이터베이스 장애, 정전 또는 기타 여러 가지 문제로 인해 발생할 수 있습니다.

    스트레스 테스트 중에 테스트 환경에서 복구 결과가 나오면 테스트 환경의 약점이 있음을 의미합니다.

    주의

    JBoss EAP는 장애 발생 시 복구되지 않은 상태인 트랜잭션을 자동으로 복구하지만 복구 트랜잭션은 복구하지 않습니다.

  3. 환경에 분명한 오류가 없거나 복구 결과를 쉽게 재현할 수 있는 경우 코딩 오류 때문일 수 있습니다. 솔루션을 사용하려면 타사 벤더에 문의해야 합니다.

    JBoss EAP의 트랜잭션 관리자에 문제가 있다고 생각되는 경우 지원 티켓을 작성해야 합니다.

  4. 관리 CLI를 사용하여 수동으로 트랜잭션 복구를 시도할 수 있습니다. 자세한 내용은 JBoss EAP 에서 트랜잭션 관리의 트랜잭션 참가자 복구 섹션을 참조하십시오.
  5. 트랜잭션 결과를 수동으로 확인하는 프로세스는 오류의 정확한 상황에 따라 달라집니다. 환경에 적용할 수 있는 다음 단계를 수행합니다.

    1. 관련된 리소스 관리자를 식별합니다.
    2. 트랜잭션 관리자 및 리소스 관리자의 상태를 검사합니다.
    3. 관련된 구성 요소 중 하나 이상에서 로그 정리 및 데이터 조정을 수동으로 강제 적용합니다.
  6. 테스트 환경에서 또는 데이터의 무결성에 관심이 없는 경우 트랜잭션 로그를 삭제하고 JBoss EAP를 다시 시작하면 복구 결과가 제거됩니다. 기본적으로 트랜잭션 로그는 독립 실행형 서버의 EAP_HOME/standalone/data/tx-object-store/ 디렉터리에 또는 관리형 도메인의 EAP_HOME/domain/servers/SERVER_NAME/data/tx-object-store/ 디렉터리에 있습니다. 관리형 도메인의 경우 SERVER_NAME 은 서버 그룹에 참여하는 개별 서버의 이름을 나타냅니다.

    참고

    트랜잭션 로그의 위치는 사용 중인 오브젝트 저장소와 object-store- relative-to 및 object-store- path 매개변수에 설정된 값에 따라 달라집니다. 파일 시스템 로그(예: 표준 섀도우 및 Apache ActiveMQ Artemis 로그)의 경우 기본 디렉터리 위치가 사용되지만 JDBC 오브젝트 저장소를 사용하는 경우 트랜잭션 로그가 데이터베이스에 저장됩니다.

11.7.4. 자카르타 트랜잭션 트랜잭션 오류 처리

11.7.4.1. 트랜잭션 오류 처리

트랜잭션 오류는 타이밍에 의존하는 경우가 많기 때문에 해결하기 어렵습니다. 다음은 문제 해결을 위한 일반적인 오류와 아이디어입니다.

참고

이러한 지침은 추론적 오류에는 적용되지 않습니다. 복구 오류가 발생하면 트랜잭션 처리에서 Heuristic Outcome을 참조하고 Red Hat 글로벌 지원 서비스에 문의하십시오.

트랜잭션 시간이 초과되었지만 비즈니스 로직 스레드는 확인되지 않았습니다.

이러한 유형의 오류는 Hibernate가 지연 로드를 위한 데이터베이스 연결을 얻을 수 없을 때 나타납니다. 자주 발생하는 경우 시간 초과 값을 늘릴 수 있습니다. 트랜잭션 관리자 구성에 대한 정보는 JBoss EAP 구성 가이드를 참조하십시오.

이 방법이 적합하지 않은 경우 외부 환경을 조정하여 보다 신속하게 수행하거나 코드를 보다 효율적으로 재구성할 수 있습니다. 시간 초과 문제가 있는 경우 Red Hat 글로벌 지원 서비스에 문의하십시오.

트랜잭션이 이미 스레드에서 실행 중이거나 NotSupportedException 예외가 수신됨

NotSupportedException 예외는 일반적으로 Jakarta 트랜잭션 트랜잭션을 중첩하려고 시도했으며 이는 지원되지 않음을 나타냅니다. 트랜잭션을 중첩하지 않으려는 경우 다른 트랜잭션이 스레드 풀 작업에서 시작되었을 가능성이 크지만 트랜잭션을 일시 중단하거나 종료하지 않고 작업을 완료합니다.

일반적으로 애플리케이션에서는 자동으로 처리하는 UserTransaction 을 사용합니다. 그렇지 않으면 프레임워크에 문제가 있을 수 있습니다.

코드가 TransactionManager 또는 Transaction 메서드를 직접 사용하는 경우 트랜잭션을 커밋하거나 롤백할 때 다음 동작을 주의하십시오. 코드가 TransactionManager 메서드를 사용하여 트랜잭션 을 제어하는 경우 트랜잭션을 커밋하거나 롤백하면 현재 스레드의 트랜잭션의 연결이 끊깁니다. 그러나 코드에서 Transaction 메서드를 사용하는 경우 트랜잭션이 실행 중인 스레드와 연결되지 않을 수 있으며 스레드 풀에 반환하기 전에 수동으로 해당 스레드에서 연결을 해제해야 합니다.

두 번째 로컬 리소스를 열거할 수 없습니다.
이 오류는 XA가 아닌 두 번째 리소스를 트랜잭션에 등록하려고 하면 발생합니다. 트랜잭션에 여러 리소스가 필요한 경우 XA여야 합니다.

11.8. 트랜잭션 참조

11.8.1. 자카르타 트랜잭션의 트랜잭션 예

이 예제에서는 자카르타 트랜잭션을 시작, 커밋 및 롤백하는 방법을 보여줍니다. 사용자 환경에 맞게 connection 및 datasource 매개 변수를 조정하고 데이터베이스에 테스트 테이블을 두 개 설정해야 합니다.

public class JDBCExample {
    public static void main (String[] args) {
        Context ctx = new InitialContext();
        // Change these two lines to suit your environment.
        DataSource ds = (DataSource)ctx.lookup("jdbc/ExampleDS");
        Connection conn = ds.getConnection("testuser", "testpwd");
        Statement stmt = null; // Non-transactional statement
        Statement stmtx = null; // Transactional statement
        Properties dbProperties = new Properties();

        // Get a UserTransaction
        UserTransaction txn = new InitialContext().lookup("java:comp/UserTransaction");

        try {
            stmt = conn.createStatement();  // non-tx statement

            // Check the database connection.
            try {
                stmt.executeUpdate("DROP TABLE test_table");
                stmt.executeUpdate("DROP TABLE test_table2");
            }
            catch (Exception e) {
                throw new RuntimeException(e);
                // assume not in database.
            }

            try {
                stmt.executeUpdate("CREATE TABLE test_table (a INTEGER,b INTEGER)");
                stmt.executeUpdate("CREATE TABLE test_table2 (a INTEGER,b INTEGER)");
            }
            catch (Exception e) {
                throw new RuntimeException(e);
            }

            try {
                System.out.println("Starting top-level transaction.");

                txn.begin();

                stmtx = conn.createStatement(); // will be a tx-statement

                // First, we try to roll back changes

                System.out.println("\nAdding entries to table 1.");

                stmtx.executeUpdate("INSERT INTO test_table (a, b) VALUES (1,2)");

                ResultSet res1 = null;

                System.out.println("\nInspecting table 1.");

                res1 = stmtx.executeQuery("SELECT * FROM test_table");

                while (res1.next()) {
                    System.out.println("Column 1: "+res1.getInt(1));
                    System.out.println("Column 2: "+res1.getInt(2));
                }
                System.out.println("\nAdding entries to table 2.");

                stmtx.executeUpdate("INSERT INTO test_table2 (a, b) VALUES (3,4)");
                res1 = stmtx.executeQuery("SELECT * FROM test_table2");

                System.out.println("\nInspecting table 2.");

                while (res1.next()) {
                    System.out.println("Column 1: "+res1.getInt(1));
                    System.out.println("Column 2: "+res1.getInt(2));
                }

                System.out.print("\nNow attempting to rollback changes.");

                txn.rollback();

                // Next, we try to commit changes
                txn.begin();
                stmtx = conn.createStatement();
                System.out.println("\nAdding entries to table 1.");
                stmtx.executeUpdate("INSERT INTO test_table (a, b) VALUES (1,2)");
                ResultSet res2 = null;

                System.out.println("\nNow checking state of table 1.");

                res2 = stmtx.executeQuery("SELECT * FROM test_table");

                while (res2.next()) {
                    System.out.println("Column 1: "+res2.getInt(1));
                    System.out.println("Column 2: "+res2.getInt(2));
                }

                System.out.println("\nNow checking state of table 2.");

                stmtx = conn.createStatement();

                res2 = stmtx.executeQuery("SELECT * FROM test_table2");

                while (res2.next()) {
                    System.out.println("Column 1: "+res2.getInt(1));
                    System.out.println("Column 2: "+res2.getInt(2));
                }

                txn.commit();
            }
            catch (Exception ex) {
                throw new RuntimeException(ex);

            }
        }
        catch (Exception sysEx) {
            sysEx.printStackTrace();
            System.exit(0);
        }
    }
}
Copy to Clipboard Toggle word wrap

11.8.2. 트랜잭션 API 문서

트랜잭션 자카르타 트랜잭션 API 문서는 다음 위치에서 Javadoc로 제공됩니다.

애플리케이션을 개발하는 데 Red Hat CodeReady Studio를 사용하면 API 문서가 도움말 메뉴에 포함되어 있습니다.

12장. 자카르타 지속성

12.1. 자카르타 지속성 정보

Jakarta Persistence는 Java 개체 또는 클래스와 관계형 데이터베이스 간의 데이터 액세스, 지속 및 관리를 위한 Jakarta EE 사양입니다. Jakarta Persistence 사양은 투명한 객체 또는 관계형 매핑 패러다임의 관심과 성공을 인정합니다. 개체 또는 관계 지속성 메커니즘에 필요한 기본 API 및 메타데이터를 표준화합니다.

참고

Jakarta Persistence 자체는 제품이 아닌 사양일 뿐입니다. 지속성이나 기타 모든 것을 수행할 수 없습니다. Jakarta Persistence는 인터페이스 집합이며 구현이 필요합니다.

12.2. 간단한 JPA 애플리케이션 생성

아래 절차에 따라 Red Hat CodeReady Studio에서 간단한 JPA 애플리케이션을 만듭니다.

절차

  1. Red Hat CodeReady Studio에서 JPA 프로젝트를 만듭니다.

    1. Red Hat CodeReady Studio에서 파일프로젝트를 클릭합니다. 목록에서 JPA 를 찾아 확장한 다음 JPA 프로젝트를 선택합니다. 다음 대화 상자가 표시됩니다.

      그림 12.1. 새 JPA 프로젝트 대화 상자

    2. 프로젝트 이름을 입력합니다.
    3. 대상 런타임 을 선택합니다. 대상 런타임을 사용할 수 없는 경우 다음 지침에 따라 새 서버 및 런타임을 정의합니다. CodeReady Studio Tools 가이드 의 IDE 내에서 JBoss EAP 다운로드, 설치 및 설정.

      참고

      Red Hat CodeReady Studio에서 Target 런타임7.4 또는 이후 런타임 버전으로 설정하면 프로젝트가 Jakarta EE 8 사양과 호환됩니다.

    4. JPA 버전에서 2.1 이 선택되었는지 확인합니다.
    5. Configuration(구성) 에서 Basic JPA Configuration(기본 JPA 구성)을 선택합니다.
    6. 완료를 클릭합니다.
    7. 메시지가 표시되면 이 프로젝트 유형과 JPA 관점 창을 연결할지 여부를 선택합니다.
  2. 새 지속성 설정 파일을 만들고 구성합니다.

    1. Red Hat CodeReady Studio에서 EJB 3.x 프로젝트를 엽니다.
    2. Project Explorer 패널에서 프로젝트 루트 디렉터리를 마우스 오른쪽 버튼으로 클릭합니다.
    3. 기타...를 선택합니다..
    4. XML 폴더에서 XML File 을 선택하고 Next (다음)를 클릭합니다.
    5. ejbModule/META-INF/ 폴더를 상위 디렉터리로 선택합니다.
    6. 파일 이름을 persistence.xml 로 지정하고 Next 를 클릭합니다.
    7. XML 스키마 파일에서 Create XML file을 선택하고 Next (다음)를 클릭합니다.
    8. Select XML Catalog(XML 카탈로그 선택) 항목 목록에서 http://java.sun.com/xml/ns/persistence/persistence_2.0.xsd 를 선택하고 Next (다음)를 클릭합니다.

      그림 12.2. 지속성 XML 스키마

    9. Finish( 완료 )를 클릭하여 파일을 만듭니다. persistence.xmlMETA-INF/ 폴더에 생성되었으며 구성할 준비가 되었습니다.

      예제: 지속성 설정 파일

      <persistence xmlns="http://java.sun.com/xml/ns/persistence"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_2.xsd"
         version="2.2">
         <persistence-unit name="example" transaction-type="JTA">
            <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
            <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
            <mapping-file>ormap.xml</mapping-file>
            <jar-file>TestApp.jar</jar-file>
            <class>org.test.Test</class>
            <shared-cache-mode>NONE</shared-cache-mode>
            <validation-mode>CALLBACK</validation-mode>
            <properties>
               <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>
               <property name="hibernate.hbm2ddl.auto" value="create-drop"/>
            </properties>
         </persistence-unit>
      </persistence>
      Copy to Clipboard Toggle word wrap

12.3. 자카르타 지속성 엔티티

애플리케이션에서 데이터베이스로의 연결을 설정하고 나면 데이터베이스의 데이터를 Java 오브젝트로 매핑할 수 있습니다. 데이터베이스 테이블에 대해 매핑하는 데 사용되는 Java 개체를 엔터티 개체라고 합니다.

엔터티에는 개체 관계 메타데이터를 통해 표현되는 다른 엔터티와 관계가 있습니다. object-relational 메타데이터는 주석을 사용하여 엔터티 클래스 파일에서 직접 또는 애플리케이션에 포함된 persistence.xml 이라는 XML 설명자 파일에 지정할 수 있습니다.

Java 개체를 데이터베이스에 대한 높은 수준의 매핑은 다음과 같습니다.

  • Java 클래스는 데이터베이스 테이블에 매핑됩니다.
  • Java 인스턴스는 데이터베이스 행에 매핑됩니다.
  • Java 필드는 데이터베이스 열에 매핑됩니다.

12.4. 지속성 문맥

Jakarta Persistence 지속성 컨텍스트에는 지속성 프로바이더가 관리하는 엔터티가 포함됩니다. 지속성 컨텍스트는 데이터 소스와 상호 작용하기 위한 첫 번째 수준의 트랜잭션 캐시 역할을 합니다. 엔터티 인스턴스 및 해당 라이프사이클을 관리합니다. 로드된 엔터티는 애플리케이션에 반환되기 전에 지속성 컨텍스트에 배치됩니다. 또한 엔터티 변경은 트랜잭션이 커밋될 때 데이터베이스에 저장되도록 지속성 컨텍스트에 배치됩니다.

컨테이너 관리 지속성 컨텍스트의 수명은 트랜잭션 범위 지속성 컨텍스트라고 하는 트랜잭션으로 범위가 지정되거나 확장 지속성 컨텍스트라고 하는 단일 트랜잭션 이상으로 확장된 라이프사이클 범위가 있을 수 있습니다. enum 데이터 유형이 있는 PersistenceContextType 속성은 컨테이너 관리 엔터티 관리자의 지속성 컨텍스트 수명 범위를 정의하는 데 사용됩니다. 지속성 컨텍스트 수명 범위는 EntityManager 인스턴스가 생성될 때 정의됩니다.

12.4.1. 트랜잭션에 저장된 지속성 컨텍스트

트랜잭션 범위 지속성 컨텍스트는 활성 자카르타 트랜잭션과 함께 작동합니다. 트랜잭션 커밋 시 지속성 컨텍스트가 데이터 소스에 플러시됩니다. 엔터티 오브젝트는 분리되지만 애플리케이션 코드에서 참조할 수 있습니다. 데이터 소스에 저장해야 하는 모든 엔터티 변경은 트랜잭션 중에 수행해야 합니다. EntityManager 호출이 완료되면 트랜잭션 외부에서 읽기인 엔터티가 분리됩니다.

12.4.2. 연장 지속성 컨텍스트

확장된 지속성 컨텍스트는 여러 트랜잭션에 걸쳐 있으며, 활성 자카르타 트랜잭션 없이 데이터 수정을 대기열에 추가할 수 있습니다. 컨테이너 관리 지속성 컨텍스트는 상태 저장 세션 빈에만 삽입할 수 있습니다.

12.5. Jakarta Persistence EntityManager

Jakarta Persistence 엔터티 관리자는 지속성 컨텍스트에 대한 연결을 나타냅니다. 엔터티 관리자를 사용하여 지속성 컨텍스트에서 정의한 데이터베이스에 대해 읽고 쓸 수 있습니다.

지속성 컨텍스트는 javax.persistence 패키지의 Java 주석 @PersistenceContext 를 통해 제공됩니다. 엔터티 관리자는 Java 클래스 javax.persistence.EntityManager 를 통해 제공됩니다. 관리 빈에서 EntityManager 인스턴스는 다음과 같이 삽입할 수 있습니다.

예제: 엔터티 관리자 주입

@Stateless
public class UserBean {
    @PersistenceContext
    EntityManager entitymanager;
    ...
}
Copy to Clipboard Toggle word wrap

12.5.1. Application-Managed EntityManager

애플리케이션 관리 엔터티 관리자는 기본 지속성 프로바이더인 org.hibernate.jpa.HibernatePersistenceProvider 에 직접 액세스할 수 있습니다. 애플리케이션 관리 엔터티 관리자의 범위는 애플리케이션이 생성되고 애플리케이션에서 종료될 때까지 지속될 때의 범위입니다. @PersistenceUnit 주석을 사용하여 애플리케이션 관리 엔터티 관리자를 반환하는 javax.persistence.EntityManagerFactory 인터페이스에 지속성 유닛을 삽입할 수 있습니다.

애플리케이션이 특정 지속성 유닛의 EntityManager 인스턴스 전체에 분산되지 않은 지속성 컨텍스트에 액세스해야 하는 경우 애플리케이션 관리 엔터티 관리자를 사용할 수 있습니다. 이 경우 각 EntityManager 인스턴스는 격리된 새 지속성 컨텍스트를 생성합니다. EntityManager 인스턴스 및 관련 PersistenceContext 는 애플리케이션에서 명시적으로 생성 및 제거됩니다. EntityManager 인스턴스가 스레드 보안이 아니므로 EntityManager 인스턴스를 직접 주입할 수 없는 경우에도 애플리케이션 관리 엔터티 관리자를 사용할 수 있습니다. EntityManagerFactory 인스턴스는 스레드 보안입니다.

예제: 애플리케이션 관리 엔터티 관리자

@PersistenceUnit
EntityManagerFactory emf;
EntityManager em;
@Resource
UserTransaction utx;
...
em = emf.createEntityManager();
try {
    utx.begin();
    em.persist(SomeEntity);
    em.merge(AnotherEntity);
    em.remove(ThirdEntity);
    utx.commit();
}
catch (Exception e) {
    utx.rollback();
}
Copy to Clipboard Toggle word wrap

12.5.2. Container-Managed EntityManager

컨테이너 관리 엔터티 관리자는 애플리케이션의 기본 지속성 프로바이더를 관리합니다. 트랜잭션 범위 지속성 컨텍스트 또는 확장 지속성 컨텍스트를 사용할 수 있습니다. 컨테이너 관리 엔터티 관리자는 필요에 따라 기본 지속성 프로바이더의 인스턴스를 생성합니다. 새로운 기본 지속성 프로바이더인 org.hibernate.jpa.HibernatePersistenceProvider 인스턴스가 생성될 때마다 새로운 지속성 컨텍스트도 생성됩니다.

12.6. EntityManager 작업

/META-INF 디렉터리에 persistence.xml 파일이 있으면 엔터티 관리자가 로드되고 데이터베이스에 대한 활성 연결이 있습니다. EntityManager 속성을 사용하여 엔터티 관리자를 JNDI에 바인딩하고 엔터티를 추가, 업데이트, 제거 및 쿼리할 수 있습니다.

중요

Hibernate와 함께 보안 관리자를 사용하려면 EntityManagerFactory 가 JBoss EAP 서버에서 부트스트랩된 경우에만 Hibernate가 이를 지원합니다. 애플리케이션에서 EntityManagerFactory 또는 SessionFactory 를 부트스트랩하는 경우 지원되지 않습니다. 보안 관리자에게 대한 자세한 내용은 How to Configure Server Security (서버 보안 구성 방법)에서 Java Security Manager 를 참조하십시오.

12.6.1. EntityManager를 JNDI에 바인딩

기본적으로 JBoss EAP는 EntityManagerFactory 를 JNDI에 바인딩하지 않습니다. jboss.entity.manager.factory .jndi.name 속성을 설정하여 애플리케이션의 persistence. xml 파일에서 이를 명시적으로 구성할 수 있습니다. 이 속성의 값은 EntityManagerFactory 를 바인딩하려는 JNDI 이름이어야 합니다.

jboss.entity.manager.jndi.name 속성을 사용하여 컨테이너 관리 트랜잭션 범위 엔터티 관리자를 JNDI에 바인딩할 수도 있습니다.

예제: EntityManager 및 EntityManager Factory 를 JNDI에 바인딩

<property name="jboss.entity.manager.jndi.name" value="java:/MyEntityManager"/>
<property name="jboss.entity.manager.factory.jndi.name" value="java:/MyEntityManagerFactory"/>
Copy to Clipboard Toggle word wrap

예제: EntityManager를 사용하여 엔터티 저장

public User createUser(User user) {
    entityManager.persist(user);
    return user;
}
Copy to Clipboard Toggle word wrap

예제: EntityManager를 사용하여 엔터티 업데이트

public void updateUser(User user) {
    entityManager.merge(user);
}
Copy to Clipboard Toggle word wrap

예제: EntityManager를 사용하여 엔터티 제거

public void deleteUser(String user) {
    User user = findUser(username);
    if (user != null)
        entityManager.remove(user);
}
Copy to Clipboard Toggle word wrap

예제: EntityManager를 사용하여 엔터티 쿼리

public User findUser(String username) {
    CriteriaBuilder builder = entityManager.getCriteriaBuilder();
    CriteriaQuery<User> criteria = builder.createQuery(User.class);
    Root<User> root = criteria.from(User.class);
    TypedQuery<User> query = entityManager
        .createQuery(criteria.select(root).where(
            builder.equal(root.<String> get("username"), username)));
    try {
        return query.getSingleResult();
    }
    catch (NoResultException e) {
        return null;
    }
}
Copy to Clipboard Toggle word wrap

12.7. 지속성 유닛 배포

지속성 유닛은 다음을 포함하는 논리 그룹화입니다.

  • 엔터티 관리자 팩토리 및 해당 엔터티 관리자의 구성 정보.
  • 엔터티 관리자가 관리하는 클래스.
  • 클래스의 데이터베이스 매핑을 지정하는 메타데이터 매핑.

persistence.xml 파일에는 데이터 소스 이름을 포함한 지속성 유닛 구성이 포함되어 있습니다. JAR 파일 또는 /META-INF/ 디렉터리에 persistence.xml 파일이 포함된 디렉터리는 지속성 유닛의 루트로 사용됩니다.

Jakarta EE 환경에서 지속성 유닛의 루트는 다음 중 하나여야 합니다.

  • EJB-JAR 파일
  • WAR 파일의 /WEB-INF/classes/ 디렉토리
  • WAR 파일의 /WEB-INF/lib/ 디렉토리에 있는 JAR 파일
  • EAR 라이브러리 디렉토리의 JAR 파일
  • 애플리케이션 클라이언트 JAR 파일

예제: 지속성 설정 파일

<persistence xmlns="http://java.sun.com/xml/ns/persistence"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_2.xsd"
   version="2.2">
   <persistence-unit name="example" transaction-type="JTA">
      <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
      <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
      <mapping-file>ormap.xml</mapping-file>
      <jar-file>TestApp.jar</jar-file>
      <class>org.test.Test</class>
      <shared-cache-mode>NONE</shared-cache-mode>
      <validation-mode>CALLBACK</validation-mode>
      <properties>
         <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>
         <property name="hibernate.hbm2ddl.auto" value="create-drop"/>
      </properties>
   </persistence-unit>
</persistence>
Copy to Clipboard Toggle word wrap

12.8. 두 번째 수준 캐시

12.8.1. 두 번째 수준 캐시 정보

두 번째 수준 캐시는 애플리케이션 세션 외부에서 지속되는 정보를 보관하는 로컬 데이터 저장소입니다. 캐시는 애플리케이션과 별도로 데이터를 유지하여 런타임을 개선하여 지속성 프로바이더가 관리합니다.

JBoss EAP는 다음과 같은 목적으로 캐싱을 지원합니다.

  • 웹 세션 클러스터링
  • 상태 저장 세션 빈 클러스터링
  • SSO 클러스터링
  • Hibernate 두 번째 수준 캐시
  • 자카르타 지속성 두 번째 수준 캐시
주의

각 캐시 컨테이너는 repldist 캐시를 정의합니다. 이러한 캐시는 사용자 애플리케이션에서 직접 사용해서는 안 됩니다.

12.8.1.1. 기본 두 번째 수준 캐시 공급자

Infinispan은 JBoss EAP의 기본 두 번째 수준 캐시 프로바이더입니다. Infinispan은 Apache 라이센스 2.0에서 사용할 수 있는 선택적 스키마가 있는 분산 메모리 내 키/값 데이터 저장소입니다.

12.8.1.1.1. 지속성 유닛에서 두 번째 수준 캐시 구성
참고

향후 JBoss EAP 릴리스와의 호환성을 보장하기 위해 persistence.xml 속성 덮어쓰기 대신 jenkinsfile 하위 시스템을 사용하여 캐시 구성을 사용자 지정해야 합니다.

지속성 유닛의 shared-cache-mode 요소를 사용하여 두 번째 수준 캐시를 구성할 수 있습니다.

  1. Red Hat CodeReady Studio에서 persistence.xml 파일을 생성하려면 Create a Simple Jakarta Persistence Application 을 참조하십시오.
  2. 다음을 persistence.xml 파일에 추가합니다.

    <persistence-unit name="...">
      (...) <!-- other configuration -->
      <shared-cache-mode>SHARED_CACHE_MODE</shared-cache-mode>
      <properties>
        <property name="hibernate.cache.use_second_level_cache" value="true" />
        <property name="hibernate.cache.use_query_cache" value="true" />
      </properties>
    </persistence-unit>
    Copy to Clipboard Toggle word wrap

    SHARED_CACHE_MODE 요소에는 다음 값을 사용할 수 있습니다.

    • ALL: 모든 엔터티는 캐시 가능한 것으로 간주해야 합니다.
    • NONE: 어떠한 엔터티도 캐시 가능한 것으로 간주해서는 안 됩니다.
    • ENABLE_SELECTIVE: 캐시 가능으로 표시된 엔터티만 캐시 가능으로 간주해야 합니다.
    • DISABLE_SELECTIVE: not cacheable로 명시적으로 표시된 엔터티를 제외한 모든 엔터티는 캐시 가능으로 간주되어야 합니다.
    • 지정되지 않음: 동작이 정의되지 않았습니다. 공급자별 기본값은 적용 가능합니다.

예제: persistence.xml을 사용하여 엔터티로컬 쿼리 캐시의 속성 변경

<persistence ... version="2.2">
    <persistence-unit ...>
        ...
        <properties>
            <!-- Values below are not recommendations. Appropriate values should be determined based on system use/capacity. -->

            <!-- entity default overrides -->
            <property name="hibernate.cache.infinispan.entity.memory.size" value="5000"/>
            <property name="hibernate.cache.infinispan.entity.expiration.max_idle" value="300000"/> <!-- 5 minutes -->
            <property name="hibernate.cache.infinispan.entity.expiration.lifespan" value="1800000"/> <!-- 30 minutes -->
            <property name="hibernate.cache.infinispan.entity.expiration.wake_up_interval" value="300000"/>  <!-- 5 minutes -->

            <!-- local-query default overrides -->
            <property name="hibernate.cache.infinispan.query.memory.size" value="5000"/>
            <property name="hibernate.cache.infinispan.query.expiration.max_idle" value="300000"/> <!-- 5 minutes -->
            <property name="hibernate.cache.infinispan.query.expiration.lifespan" value="1800000"/> <!-- 30 minutes -->
            <property name="hibernate.cache.infinispan.query.expiration.wake_up_interval" value="300000"/> <!-- 5 minutes -->
        </properties>
    </persistence-unit>
</persistence>
Copy to Clipboard Toggle word wrap

Expand
표 12.1. 엔터티 및 로컬 쿼리 캐시의 속성
속성설명

memory.size

개체 메모리 크기를 나타냅니다.

expiration.max_idle

캐시 항목이 캐시에서 유지 관리되는 최대 유휴 시간(밀리초)을 나타냅니다.

expiration.lifespan

캐시 항목이 만료된 후 최대 수명(밀리초)을 나타냅니다. 기본값은 60초입니다. 무한한 수명을 -1을 사용하여 지정할 수 있습니다.

expiration.wake_up_interval

캐시에서 만료된 항목을 제거하기 위해 후속 실행 간 간격(밀리초)을 나타냅니다. -1을 사용하여 만료를 비활성화할 수 있습니다.

13장. Jakarta Bean Validation

13.1. Jakarta Bean Validation 정보

Jakarta Bean Validation은 Java 객체의 데이터를 검증하는 모델입니다. 모델은 기본 제공 및 사용자 지정 주석 제한 조건을 사용하여 애플리케이션 데이터의 무결성을 보장합니다. 매개 변수 및 반환 값에 대한 제약 조건을 보장하기 위해 메서드 및 생성자 검증도 제공합니다. 사양은 Jakarta Bean Validation 2.0 사양에 설명되어 있습니다.

Hibernate Validator는 Jakarta Bean Validation의 JBoss EAP 구현입니다. 또한 Jakarta Bean Validation 2.0 사양의 참조 구현입니다.

JBoss EAP는 Jakarta Bean Validation 2.0 사양과 100% 호환됩니다. Hibernate Validator는 사양에 추가 기능도 제공합니다.

Jakarta Bean Validation을 시작하려면 JBoss EAP와 함께 제공되는 bean-validation 빠른 시작을 참조하십시오. 빠른 시작을 다운로드하고 실행하는 방법에 대한 자세한 내용은 JBoss EAP Getting Started Guide 의 빠른 시작 예제 사용을 참조하십시오.

JBoss EAP 7.4에는 Hibernate Validator 6.0.x가 포함되어 있습니다.

Hibernate Validator 6.0.x의 기능
  • Jakarta Bean Validation 2.0은 엔터티 및 메서드 유효성 검사를 위한 메타데이터 모델 및 API를 정의합니다.

    메타데이터의 기본 소스는 XML을 사용하여 메타데이터를 재정의하고 확장할 수 있는 주석입니다.

    API는 특정 애플리케이션 계층 또는 프로그래밍 모델에 종속되지 않습니다. 서버 측 애플리케이션 프로그래밍과 리치 클라이언트 Swing 애플리케이션 개발에 모두 사용할 수 있습니다.

  • 이번 Hibernate Validator 릴리스에는 버그 수정 외에도 가장 일반적인 사용 사례에서 많은 성능 개선이 포함되어 있습니다.
  • 버전 1.1부터 Jakarta Bean Validation 제약 조건을 Jakarta Bean Validation API를 사용하여 임의의 Java 유형의 메서드의 매개변수 및 반환 값에도 적용할 수 있습니다.
  • Hibernate Validator 6.0.x 및 Jakarta Bean Validation 2.0에는 Java 8 이상이 필요합니다.

    자세한 내용은 Hibernate Validator 6.0.17.Final - JSR 380 참조 구현을 참조하십시오. 참조 가이드.

13.2. 검증 제한

13.2.1. 검증 제한 조건 정보

유효성 검사 제한 조건은 필드, 속성 또는 빈과 같은 Java 요소에 적용되는 규칙입니다. 제약 조건에는 일반적으로 제한을 설정하는 데 사용되는 속성 집합이 있습니다. 사전 정의된 제한 조건이 있으며 사용자 지정 제약 조건을 생성할 수 있습니다. 각 제한 조건은 주석 형태로 표시됩니다.

Hibernate Validator의 기본 제공 유효성 검사 제한 조건은 다음과 같습니다. Hibernate Validator 제한 조건.

13.2.2. Hibernate Validator 제약 조건

참고

해당되는 경우 애플리케이션 수준 제한 조건은 아래 표의 Hibernate 메타데이터 영향 열에 설명된 데이터베이스 수준의 제약 조건을 생성합니다.

Java별 검증 제한

다음 표에는 javax.validation.constraints 패키지에 포함된 Java 사양에 정의된 유효성 검사 제한 조건이 포함되어 있습니다.

Expand
주석속성 유형런타임 검사Hibernate 메타데이터 영향

@AssertFalse

부울

메서드가 false로 평가되는지 확인합니다. 주석이 아닌 코드로 표현된 제약 조건에 유용합니다.

없음.

@AssertTrue

부울

메서드가 true로 평가되는지 확인합니다. 주석이 아닌 코드로 표현된 제약 조건에 유용합니다.

없음.

@Digits(integerDigits=1)

숫자의 숫자 또는 문자열 표시

속성이 정수Digits 정수 숫자 및 부분Digits 부분 자리수까지 갖는 숫자 인지 확인하십시오.

열 정확도 및 스케일링을 정의합니다.

@Future

날짜 또는 일정

날짜가 향후 상태인지 확인합니다.

없음.

@Max(value=)

숫자의 숫자 또는 문자열 표시

값이 max보다 작거나 같은지 확인합니다.

열에 검사 제한 조건을 추가합니다.

@Min(value=)

숫자의 숫자 또는 문자열 표시

값이 Min보다 크거나 같은지 확인합니다.

열에 검사 제한 조건을 추가합니다.

@NotNull

 

값이 null이 아닌지 확인합니다.

열은 null이 아닙니다.

@Past

날짜 또는 일정

날짜가 과거인지 확인합니다.

열에 검사 제한 조건을 추가합니다.

@Pattern(regexp="regexp", flag=) or @Patterns( {@Pattern(…​)} )

문자열

속성에 일치하는 플래그가 지정된 정규 표현식과 일치하는지 확인합니다. java.util.regex.Pattern 을 참조하십시오.

없음.

@Size(min=, max=)

배열, 컬렉션, 맵

요소 크기가 min과 max 사이의지, 두 값 모두 포함된지 확인합니다.

없음.

@Valid

개체

연결된 오브젝트에서 검증을 재귀적으로 수행합니다. 오브젝트가 Collection 또는 array인 경우 요소가 재귀적으로 검증됩니다. 오브젝트가 Map인 경우 값 요소의 유효성이 재귀적으로 확인됩니다.

없음.

참고

@Valid 매개변수는 javax.validation.constraints 패키지에 있더라도 Jakarta Bean Validation 사양의 일부입니다.

Hibernate Validator별 검증 제한

다음 표에는 org.hibernate.validator.constraints 패키지의 일부인 벤더별 유효성 검사 제한 조건이 포함되어 있습니다.

Expand
주석속성 유형런타임 검사Hibernate 메타데이터 영향

@Length(min=, max=)

문자열

문자열 길이가 범위와 일치하는지 확인합니다.

열 길이는 max로 설정됩니다.

@CreditCardNumber

문자열

문자열이 잘 포맷된 신용 카드 번호인지, Luhn 알고리즘의 파생인지 확인하십시오.

없음.

@EAN

문자열

문자열이 올바른 형식의 EAN인지 또는 UPC-A 코드인지 확인합니다.

없음.

@Email

문자열

문자열이 전자 메일 주소 사양을 준수하는지 확인합니다.

없음.

@NotEmpty

 

문자열이 null이 아니거나 비어 있지 않은지 확인합니다. 연결이 null이 아니거나 비어 있지 않은지 확인합니다.

문자열에 대한 열은 null이 아닙니다.

@Range(min=, max=)

숫자의 숫자 또는 문자열 표시

값이 min과 max 사이의지, 두 값이 모두 포함된지 확인합니다.

열에 검사 제한 조건을 추가합니다.

13.2.3. Jakarta Bean Validation 사용자 정의 제약 조건 사용

Jakarta Bean Validation API는 @NotNull, @ Size 등과 같은 표준 제한 조건 주석 집합을 정의합니다. 그러나 이러한 사전 정의된 제약 조건이 충분하지 않은 경우 특정 검증 요구 사항에 맞게 사용자 지정 제한 조건을 쉽게 생성할 수 있습니다.

Jakarta Bean Validation 사용자 지정 제약 조건을 생성하려면 제약 조건 주석을 생성하고 제약 조건 유효성 검사기를 구현해야 합니다. 다음은 JBoss EAP와 함께 제공되는 bean-validation-custom-constraint 빠른 시작에서 축약된 코드 예제입니다. 전체 작업 예는 빠른 시작을 참조하십시오.

13.2.3.1. 제한적인 주석 생성

다음 예제에서는 AddressValidator 클래스에 정의된 사용자 지정 제약 조건 집합을 사용하여 엔터티 PersonpersonAddress 필드가 검증되었음을 보여줍니다.

  1. 엔터티 Person 을 만듭니다.

    예제: 개인 수업

    package org.jboss.as.quickstarts.bean_validation_custom_constraint;
    
    @Entity
    @Table(name = "person")
    public class Person implements Serializable {
    
        private static final long serialVersionUID = 1L;
    
        @Id
        @GeneratedValue
        @Column(name = "person_id")
        private Long personId;
    
        @NotNull
    
        @Size(min = 4)
        private String firstName;
    
        @NotNull
        @Size(min = 4)
        private String lastName;
    
        // Custom Constraint @Address for bean validation
        @NotNull
        @Address
        @OneToOne(mappedBy = "person", cascade = CascadeType.ALL)
        private PersonAddress personAddress;
    
        public Person() {
    
        }
    
        public Person(String firstName, String lastName, PersonAddress address) {
            this.firstName = firstName;
            this.lastName = lastName;
            this.personAddress = address;
        }
    
        /* getters and setters omitted for brevity*/
    }
    Copy to Clipboard Toggle word wrap

  2. 제약 조건 유효성 검사기 파일을 생성합니다.

    예제: 주소 인터페이스

    package org.jboss.as.quickstarts.bean_validation_custom_constraint;
    
    import java.lang.annotation.Documented;
    import java.lang.annotation.ElementType;
    import java.lang.annotation.Retention;
    import java.lang.annotation.RetentionPolicy;
    import java.lang.annotation.Target;
    import javax.validation.Constraint;
    import javax.validation.Payload;
    
    // Linking the AddressValidator class with @Address annotation.
    @Constraint(validatedBy = { AddressValidator.class })
    // This constraint annotation can be used only on fields and method parameters.
    @Target({ ElementType.FIELD, ElementType.PARAMETER })
    @Retention(value = RetentionPolicy.RUNTIME)
    @Documented
    public @interface Address {
    
        // The message to return when the instance of MyAddress fails the validation.
        String message() default "Address Fields must not be null/empty and obey character limit constraints";
    
        Class<?>[] groups() default {};
    
        Class<? extends Payload>[] payload() default {};
    }
    Copy to Clipboard Toggle word wrap

    예제: PersonAddress 클래스

    package org.jboss.as.quickstarts.bean_validation_custom_constraint;
    
    import java.io.Serializable;
    import javax.persistence.Column;
    import javax.persistence.Entity;
    import javax.persistence.GeneratedValue;
    import javax.persistence.GenerationType;
    import javax.persistence.Id;
    import javax.persistence.OneToOne;
    import javax.persistence.PrimaryKeyJoinColumn;
    import javax.persistence.Table;
    
    @Entity
    @Table(name = "person_address")
    public class PersonAddress implements Serializable {
    
        private static final long serialVersionUID = 1L;
    
        @Id
        @Column(name = "person_id", unique = true, nullable = false)
        @GeneratedValue(strategy = GenerationType.SEQUENCE)
        private Long personId;
    
        private String streetAddress;
        private String locality;
        private String city;
        private String state;
        private String country;
        private String pinCode;
    
        @OneToOne
        @PrimaryKeyJoinColumn
        private Person person;
    
        public PersonAddress() {
    
        }
    
        public PersonAddress(String streetAddress, String locality, String city, String state, String country, String pinCode) {
            this.streetAddress = streetAddress;
            this.locality = locality;
            this.city = city;
            this.state = state;
            this.country = country;
            this.pinCode = pinCode;
        }
    
        /* getters and setters omitted for brevity*/
    }
    Copy to Clipboard Toggle word wrap

13.2.3.2. 제약 조건 검증기 구현

주석을 정의한 경우 @Address 주석을 사용하여 요소를 검증할 수 있는 제한 조건 검증기를 생성해야 합니다. 이렇게 하려면 interface ConstraintValidator 를 다음과 같이 구현하십시오.

예제: AddressValidator Class

package org.jboss.as.quickstarts.bean_validation_custom_constraint;

import javax.validation.ConstraintValidator;
import javax.validation.ConstraintValidatorContext;
import org.jboss.as.quickstarts.bean_validation_custom_constraint.PersonAddress;

public class AddressValidator implements ConstraintValidator<Address, PersonAddress> {

    public void initialize(Address constraintAnnotation) {
    }

    /**
     * 1. A null address is handled by the @NotNull constraint on the @Address.
     * 2. The address should have all the data values specified.
     * 3. Pin code in the address should be of at least 6 characters.
     * 4. The country in the address should be of at least 4 characters.
     */
    public boolean isValid(PersonAddress value, ConstraintValidatorContext context) {
        if (value == null) {
            return true;
        }

        if (value.getCity() == null || value.getCountry() == null || value.getLocality() == null
            || value.getPinCode() == null || value.getState() == null || value.getStreetAddress() == null) {
            return false;
        }

        if (value.getCity().isEmpty()
            || value.getCountry().isEmpty() || value.getLocality().isEmpty()
            || value.getPinCode().isEmpty() || value.getState().isEmpty() || value.getStreetAddress().isEmpty()) {
            return false;
        }

        if (value.getPinCode().length() < 6) {
            return false;
        }

        if (value.getCountry().length() < 4) {
            return false;
        }

        return true;
    }
}
Copy to Clipboard Toggle word wrap

13.3. Jakarta Bean Validation Configuration

/META-INF 디렉터리에 있는 validation.xml 파일에서 XML 설명자를 사용하여 Jakarta Bean Validation을 구성할 수 있습니다. 이 파일이 클래스 경로에 있는 경우 ValidatorFactory 가 생성될 때 해당 구성이 적용됩니다.

예제: Jakarta Bean Validation Configuration 파일

다음 예제에서는 validation.xml 파일의 여러 구성 옵션을 보여줍니다. 모든 설정은 선택 사항입니다. 이러한 옵션은 javax.validation 패키지를 사용하여 구성할 수도 있습니다.

<validation-config xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration">

    <default-provider>
        org.hibernate.validator.HibernateValidator
    </default-provider>
    <message-interpolator>
        org.hibernate.validator.messageinterpolation.ResourceBundleMessageInterpolator
    </message-interpolator>
    <constraint-validator-factory>
        org.hibernate.validator.engine.ConstraintValidatorFactoryImpl
    </constraint-validator-factory>

    <constraint-mapping>
        /constraints-example.xml
    </constraint-mapping>

    <property name="prop1">value1</property>
    <property name="prop2">value2</property>
</validation-config>
Copy to Clipboard Toggle word wrap

노드 default-provider 를 사용하면 Jakarta Bean Validation 공급자를 선택할 수 있습니다. 이는 클래스 경로에 공급자가 두 개 이상 있는 경우 유용합니다. message-interpolator 및 constraint -validator-factory 속성은 javax.validation 패키지에 정의된 MessageInterpolatorConstraintValidatorFactory 인터페이스에 사용된 구현을 사용자 지정하는 데 사용됩니다. constraint -mapping 요소에는 실제 제약 조건이 포함된 추가 XML 파일이 나열됩니다.

14장. 자카르타 WebSocket 애플리케이션 생성

Jakarta WebSocket 프로토콜은 웹 클라이언트와 서버 간의 양방향 통신을 제공합니다. 클라이언트와 서버 간의 통신은 이벤트 기반이므로, 폴링 기반 방법과 비교하여 더 빠른 프로세싱과 더 작은 대역폭을 허용합니다. Jakarta WebSocket은 JavaScript API를 사용하는 웹 애플리케이션 및 자카르타 WebSocket 사양을 사용하는 클라이언트 Jakarta WebSocket 엔드포인트에서 사용할 수 있습니다.

연결이 먼저 HTTP 연결로 클라이언트와 서버 간에 설정됩니다. 그런 다음 클라이언트는 Upgrade 헤더를 사용하여 자카르타 WebSocket 연결을 요청합니다. 모든 통신은 최소한의 데이터 오버헤드로 동일한 TCP/IP 연결을 통해 전이중됩니다. 각 메시지에는 불필요한 HTTP 헤더 콘텐츠가 포함되지 않으므로 Jakarta WebSocket 통신에는 더 작은 대역폭이 필요합니다. 결과적으로 애플리케이션에 적합한 대기 시간 통신 경로가 짧기 때문에 실시간 응답성이 필요합니다.

JBoss EAP Jakarta WebSocket 구현은 서버 엔드포인트에 대한 완전한 종속성 주입 지원을 제공하지만 클라이언트 엔드포인트에 Contexts 및 Dependency Injection 서비스를 제공하지는 않습니다.

자카르타 WebSocket 애플리케이션에는 다음과 같은 구성 요소 및 구성을 변경해야 합니다.

  • Java 클라이언트 또는 자카르타 WebSocket이 활성화된 HTML 클라이언트. 다음 위치에서 HTML 클라이언트 브라우저 지원을 확인할 수 있습니다. http://caniuse.com/#feat=websockets
  • 자카르타 WebSocket 서버 엔드 포인트 클래스.
  • Jakarta WebSocket API에 종속성을 선언하도록 구성된 프로젝트 종속성입니다.

자카르타 WebSocket 애플리케이션 만들기

다음 코드 예제는 JBoss EAP와 함께 제공되는 websocket-hello 빠른 시작에서 가져온 것입니다. 연결을 열고 메시지를 전송하며 연결을 종료하는 Jakarta WebSocket 애플리케이션의 간단한 예입니다. 다른 기능을 구현하지 않거나 실제 애플리케이션에 필요한 오류 처리를 포함하지 않습니다.

  1. JavaScript HTML 클라이언트를 만듭니다.

    다음은 자카르타 WebSocket 클라이언트의 예입니다. 여기에는 다음과 같은 JavaScript 기능이 포함되어 있습니다.

    • connect(): 이 기능은 자카르타 WebSocket URI를 전달하여 자카르타 WebSocket 연결을 생성합니다. 리소스 위치는 서버 엔드포인트 클래스에 정의된 리소스와 일치합니다. 이 기능은 또한 open, onmessage , on error 및 on close 에서 Jakarta WebSocket을 가로채고 처리합니다.
    • sendMessage(): 이 함수는 양식에 입력한 이름을 가져오고 메시지를 생성한 다음 WebSocket.send() 명령을 사용하여 전송합니다.
    • disconnect(): 이 함수는 WebSocket.close() 명령을 실행합니다.
    • displayMessage(): 이 함수는 페이지에 표시 메시지를 Jakarta WebSocket endpoint 메서드에서 반환한 값으로 설정합니다.
    • displayStatus(): 이 기능은 자카르타 WebSocket 연결 상태를 표시합니다.

      예제: 애플리케이션 index.html 코드

      <html>
        <head>
          <title>WebSocket: Say Hello</title>
          <link rel="stylesheet" type="text/css" href="resources/css/hello.css" />
          <script type="text/javascript">
            var websocket = null;
            function connect() {
              var wsURI = 'ws://' + window.location.host + '/websocket-hello/websocket/helloName';
              websocket = new WebSocket(wsURI);
              websocket.onopen = function() {
                  displayStatus('Open');
                  document.getElementById('sayHello').disabled = false;
                  displayMessage('Connection is now open. Type a name and click Say Hello to send a message.');
              };
              websocket.onmessage = function(event) {
                  // log the event
                  displayMessage('The response was received! ' + event.data, 'success');
              };
              websocket.onerror = function(event) {
                  // log the event
                  displayMessage('Error! ' + event.data, 'error');
              };
              websocket.onclose = function() {
                  displayStatus('Closed');
                  displayMessage('The connection was closed or timed out. Please click the Open Connection button to reconnect.');
                  document.getElementById('sayHello').disabled = true;
              };
            }
            function disconnect() {
              if (websocket !== null) {
                  websocket.close();
                  websocket = null;
              }
              message.setAttribute("class", "message");
              message.value = 'WebSocket closed.';
              // log the event
            }
            function sendMessage() {
              if (websocket !== null) {
                  var content = document.getElementById('name').value;
                  websocket.send(content);
              } else {
                  displayMessage('WebSocket connection is not established. Please click the Open Connection button.', 'error');
              }
            }
            function displayMessage(data, style) {
              var message = document.getElementById('hellomessage');
              message.setAttribute("class", style);
              message.value = data;
            }
            function displayStatus(status) {
              var currentStatus = document.getElementById('currentstatus');
              currentStatus.value = status;
            }
          </script>
        </head>
        <body>
          <div>
            <h1>Welcome to Red Hat JBoss Enterprise Application Platform!</h1>
            <div>This is a simple example of a Jakarta WebSocket implementation.</div>
            <div id="connect-container">
              <div>
                <fieldset>
                  <legend>Connect or disconnect using websocket :</legend>
                  <input type="button" id="connect" onclick="connect();" value="Open Connection" />
                  <input type="button" id="disconnect" onclick="disconnect();" value="Close Connection" />
                </fieldset>
              </div>
              <div>
                  <fieldset>
                    <legend>Type your name below, then click the `Say Hello` button :</legend>
                    <input id="name" type="text" size="40" style="width: 40%"/>
                    <input type="button" id="sayHello" onclick="sendMessage();" value="Say Hello" disabled="disabled"/>
                  </fieldset>
              </div>
              <div>Current WebSocket Connection Status: <output id="currentstatus" class="message">Closed</output></div>
              <div>
                <output id="hellomessage" />
              </div>
            </div>
          </div>
        </body>
      </html>
      Copy to Clipboard Toggle word wrap

  2. 자카르타 WebSocket 서버 엔드포인트를 만듭니다.

    다음 방법 중 하나를 사용하여 Jakarta WebSocket 서버 끝점을 만들 수 있습니다.

    • 프로그래밍 엔드 포인트: 엔드포인트는 엔드포인트 클래스를 확장합니다.
    • 주석이 있는 엔드 포인트: 엔드포인트 클래스는 주석을 사용하여 자카르타 WebSocket 이벤트와 상호 작용합니다. 프로그래밍 끝점보다 코딩하는 것이 더 간단합니다.

    아래 코드 예제에서는 주석이 지정된 엔드포인트 접근법을 사용하고 다음 이벤트를 처리합니다.

    • @ServerEndpoint 주석은 이 클래스를 자카르타 WebSocket 서버 엔드포인트로 식별하고 경로를 지정합니다.
    • 자카르타 WebSocket 연결이 열리면 @OnOpen 주석이 트리거됩니다.
    • 메시지가 수신되면 @OnMessage 주석이 트리거됩니다.
    • 자카르타 WebSocket 연결이 닫히면 @OnClose 주석이 트리거됩니다.

      예제: 자카르타 웹소켓 엔드 포인트 코드

      package org.jboss.as.quickstarts.websocket_hello;
      
      import javax.websocket.CloseReason;
      import javax.websocket.OnClose;
      import javax.websocket.OnMessage;
      import javax.websocket.OnOpen;
      import javax.websocket.Session;
      import javax.websocket.server.ServerEndpoint;
      
      @ServerEndpoint("/websocket/helloName")
      public class HelloName {
      
          @OnMessage
          public String sayHello(String name) {
              System.out.println("Say hello to '" + name + "'");
              return ("Hello" + name);
          }
      
          @OnOpen
          public void helloOnOpen(Session session) {
              System.out.println("WebSocket opened: " + session.getId());
          }
      
          @OnClose
          public void helloOnClose(CloseReason reason) {
              System.out.println("WebSocket connection closed with CloseCode: " + reason.getCloseCode());
          }
      }
      Copy to Clipboard Toggle word wrap

  3. 프로젝트 POM 파일에서 자카르타 WebSocket API 종속성을 선언합니다.

    Maven을 사용하는 경우 프로젝트 pom.xml 파일에 다음과 같은 종속성을 추가합니다.

    예제: Maven 종속성

    <dependency>
      <groupId>org.jboss.spec.javax.websocket</groupId>
      <artifactId>jboss-websocket-api_1.1_spec</artifactId>
      <scope>provided</scope>
    </dependency>
    Copy to Clipboard Toggle word wrap

JBoss EAP와 함께 제공되는 빠른 시작에는 추가 자카르타 WebSocket 클라이언트 및 엔드포인트 코드 예가 포함되어 있습니다.

15장. 자카르타 인증

15.1. Jakarta Authorization 정보

Jakarta Authorization은 컨테이너와 권한 부여 서비스 공급자 간의 계약을 정의하는 표준으로, 컨테이너에서 사용할 공급자를 구현합니다. 사양에 대한 자세한 내용은 Jakarta Authorization 사양을 참조하십시오.

JBoss EAP는 보안 하위 시스템의 보안 기능 내에서 Jakarta Authorization에 대한 지원을 구현합니다.

15.2. 자카르타 권한 부여 보안 구성

올바른 모듈로 보안 도메인을 구성한 다음 필수 매개변수를 포함하도록 jboss-web.xml 을 수정하여 Jakarta Authorization을 구성할 수 있습니다.

보안 도메인에 자카르타 인증 추가

보안 도메인에 Jakarta Authorization 지원을 추가하려면 required 플래그가 설정된 security 도메인의 권한 부여 스택에 Jakarta Authorization 권한 부여 정책을 추가합니다. 다음은 Jakarta Authorization 지원이 포함된 보안 도메인의 예입니다. 그러나 XML을 직접 수정하는 대신 관리 콘솔 또는 관리 CLI에서 보안 도메인을 구성하는 것이 좋습니다.

예제: 자카르타 인증을 통한 보안 도메인

<security-domain name="jacc" cache-type="default">
    <authentication>
        <login-module code="UsersRoles" flag="required">
        </login-module>
    </authentication>
    <authorization>
        <policy-module code="JACC" flag="required"/>
    </authorization>
</security-domain>
Copy to Clipboard Toggle word wrap

자카르타 인증을 사용하도록 웹 애플리케이션 구성

jboss-web.xml 파일은 배포의 WEB-INF/ 디렉터리에 있으며, 웹 컨테이너에 대한 재정의 및 추가 JBoss 특정 구성이 포함되어 있습니다. Jakarta Authorization-enabled 보안 도메인을 사용하려면 <security-domain> 요소를 포함하고 < use-jboss-authorization> 요소도 true 로 설정해야 합니다. 다음 XML은 위의 Jakarta Authorization 보안 도메인을 사용하도록 구성되어 있습니다.

예제: Jakarta Authentication Security Domain 사용

<jboss-web>
    <security-domain>jacc</security-domain>
    <use-jboss-authorization>true</use-jboss-authorization>
</jboss-web>
Copy to Clipboard Toggle word wrap

자카르타 인증을 사용하도록 자카르타 엔터프라이즈 빈 애플리케이션 구성

보안 도메인을 사용하도록 Jakarta Enterprise Bean을 구성하고 Jakarta Authorization Authorization을 사용하는 것은 웹 애플리케이션과 다릅니다. Jakarta Enterprise Beans의 경우 메서드 메서드 또는 그룹에 대한 메서드 권한을 ejb-jar.xml 설명자에서 선언할 수 있습니다. <ejb-jar> 요소 내에서 모든 child <method-permission> 요소에는 Jakarta Authorization 역할에 대한 정보가 포함되어 있습니다. 자세한 내용은 아래 설정 예제를 참조하십시오. EJBMethodPermission 클래스는 Jakarta EE API의 일부이며 Class EJBMethodPermission 에 설명되어 있습니다.

예제: 자카르타 엔터프라이즈 빈에서 자카르타 인증 방법 사용 권한

<ejb-jar>
  <assembly-descriptor>
    <method-permission>
      <description>The employee and temp-employee roles can access any method of the EmployeeService bean </description>
      <role-name>employee</role-name>
      <role-name>temp-employee</role-name>
      <method>
        <ejb-name>EmployeeService</ejb-name>
        <method-name>*</method-name>
      </method>
    </method-permission>
  </assembly-descriptor>
</ejb-jar>
Copy to Clipboard Toggle word wrap

또한 웹 애플리케이션의 경우와 마찬가지로 보안 도메인을 사용하여 Jakarta Enterprise Bean의 인증 및 권한 부여 메커니즘을 제한할 수 있습니다. 보안 도메인은 <security> 하위 요소의 jboss-ejb3.xml 설명자에 선언됩니다. 보안 도메인 외에도 <run-as-principal> 을 지정하여 Jakarta Enterprise Beans가 실행되는 주체를 변경할 수도 있습니다.

예제: Jakarta Enterprise Bean의 보안 도메인 선언

<ejb-jar>
    <assembly-descriptor>
        <security>
        <ejb-name>*</ejb-name>
        <security-domain>myDomain</security-domain>
        <run-as-principal>myPrincipal</run-as-principal>
        </security>
    </assembly-descriptor>
</ejb-jar>
Copy to Clipboard Toggle word wrap

elytron 하위 시스템을 사용하여 자카르타 권한 부여 활성화

레거시 보안 하위 시스템에서 자카르타 인증 비활성화

기본적으로 애플리케이션 서버는 레거시 보안 하위 시스템을 사용하여 Jakarta Authorization 정책 프로바이더 및 팩토리를 구성합니다. 기본 구성은 PicketBox의 구현으로 매핑됩니다.

Elytron을 사용하여 Jakarta Authorization 구성을 관리하거나 애플리케이션 서버에 설치하려는 기타 모든 정책을 관리하려면 먼저 레거시 보안 하위 시스템에서 Jakarta Authorization을 비활성화해야 합니다. 이를 위해 다음 관리 CLI 명령을 사용할 수 있습니다.

/subsystem=security:write-attribute(name=initialize-jacc, value=false)
Copy to Clipboard Toggle word wrap

이렇게 하지 않으면 서버 로그에 다음과 같은 오류가 발생할 수 있습니다. MSC000004: org.wildfly.security.policy 서비스 중지 중에 오류가 발생했습니다: java.lang.StackOverflowError.

자카르타 인증 정책 공급자 정의

elytron 하위 시스템은 Jakarta Authorization 사양을 기반으로 기본 제공 정책 프로바이더를 제공합니다. 정책 공급자를 생성하려면 다음 관리 CLI 명령을 실행할 수 있습니다.

/subsystem=elytron/policy=jacc:add(jacc-policy={})

reload
Copy to Clipboard Toggle word wrap

웹 배포에 대한 자카르타 인증 활성화

Jakarta Authorization 정책 공급자가 정의되면 다음 명령을 실행하여 웹 배포에 대해 Jakarta Authorization을 활성화할 수 있습니다.

/subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain,enable-jacc=true)
Copy to Clipboard Toggle word wrap

위의 명령은 jboss-web.xml 파일에 제공되지 않는 경우 애플리케이션의 기본 보안 도메인을 정의합니다. 이미 application-security-domain 이 정의되어 있고 Jakarta Authorization을 활성화하려는 경우 다음 명령을 실행할 수 있습니다.

/subsystem=undertow/application-security-domain=my-security-domain:write-attribute(name=enable-jacc,value=true)
Copy to Clipboard Toggle word wrap

자카르타 엔터프라이즈 빈 배포에 대한 자카르타 인증 활성화

Jakarta Authorization 정책 공급자가 정의되면 다음 명령을 실행하여 Jakarta Enterprise Beans 배포에 대한 Jakarta Authorization Authorization을 활성화할 수 있습니다.

/subsystem=ejb3/application-security-domain=other:add(security-domain=ApplicationDomain,enable-jacc=true)
Copy to Clipboard Toggle word wrap

위의 명령은 Jakarta Enterprise Bean의 기본 보안 도메인을 정의합니다. 이미 application-security-domain 이 정의되어 있고 Jakarta Authorization을 활성화하려는 경우 다음과 같이 명령을 실행할 수 있습니다.

/subsystem=ejb3/application-security-domain=my-security-domain:write-attribute(name=enable-jacc,value=true)
Copy to Clipboard Toggle word wrap

사용자 지정 Elytron 정책 공급자 생성

사용자 지정 정책 프로바이더는 권한을 확인하기 위해 일부 외부 인증 서비스와 통합하려는 경우와 같이 사용자 지정 java.security.Policy 가 필요할 때 사용됩니다. 사용자 지정 정책 프로바이더를 생성하려면 java.security.Policy 를 구현하고, 구현을 통해 사용자 지정 모듈을 생성 및 연결하며 elytron 하위 시스템의 모듈에서 구현을 사용해야 합니다.

/subsystem=elytron/policy=policy-provider-a:add(custom-policy={class-name=MyPolicyProviderA, module=x.y.z})
Copy to Clipboard Toggle word wrap

자세한 내용은 정책 공급자 속성을 참조하십시오.

참고

대부분의 경우 Jakarta EE 규격 애플리케이션 서버의 일부이므로 Jakarta Authorization 정책 공급자를 사용할 수 있습니다.

16장. 자카르타 인증

16.1. Jakarta Authentication Security 정보

Jakarta Authentication은 Java 애플리케이션을 위한 플러그형 인터페이스입니다. 사양에 대한 자세한 내용은 Jakarta Authentication 사양을 참조하십시오.

16.2. 자카르타 인증 구성

보안 도메인에 <authentication-jaspi> 요소를 추가하여 Jakarta 인증 공급자를 인증할 수 있습니다. 구성은 표준 인증 모듈과 유사하지만 로그인 모듈 요소는 <login-module-stack> 요소로 묶여 있습니다. 구성의 구조는 다음과 같습니다.

예제: authentication-jaspi 요소 구조

<authentication-jaspi>
    <login-module-stack name="...">
      <login-module code="..." flag="...">
        <module-option name="..." value="..."/>
      </login-module>
    </login-module-stack>
    <auth-module code="..." login-module-stack-ref="...">
      <module-option name="..." value="..."/>
    </auth-module>
</authentication-jaspi>
Copy to Clipboard Toggle word wrap

로그인 모듈 자체는 표준 인증 모듈과 동일한 방식으로 구성됩니다.

웹 기반 관리 콘솔은 JASPI 인증 모듈 구성을 노출하지 않습니다. EAP _HOME /domain/configuration/domain.xml 파일 또는 EAP_HOME/standalone/ configuration/standalone.xml파일에 구성을 직접 추가하기 전에 JBoss EAP 실행 인스턴스를 완전히 중지해야 합니다.

16.3. Elytron을 사용하여 자카르타 인증 보안 구성

JBoss EAP 7.3부터 elytron 하위 시스템은 Jakarta Authentication에서 서블릿 프로필 구현을 제공합니다. 이를 통해 Elytron에서 제공하는 보안 기능과 보다 긴밀하게 통합할 수 있습니다.

웹 애플리케이션에 대한 자카르타 인증 활성화

웹 애플리케이션에 대해 Jakarta Authentication 통합을 사용하려면 웹 애플리케이션을 Elytron http-authentication-factory 또는 security- domain 과 연결해야 합니다. 이렇게 하면 배포에 사용할 Elytron 보안 핸들러가 설치되고 배포에 대해 Elytron 보안 프레임워크가 활성화됩니다.

배포에 대해 Elytron 보안 프레임워크가 활성화되면 요청이 처리될 때 전역적으로 등록된 AuthConfigFactory 가 쿼리됩니다. 해당 배포에 사용해야 하는 AuthConfigProvider 가 등록되었는지 확인합니다. AuthConfigProvider 가 있는 경우 배포 인증 구성 대신 JASPI 인증이 사용됩니다. AuthConfigProvider 를 찾을 수 없는 경우 배포에 대한 인증 구성이 대신 사용됩니다. 이로 인해 다음과 같은 세 가지 가능성 중 하나가 발생할 수 있습니다.

  • http-authentication-factory 의 인증 메커니즘 사용.
  • web.xml 에 지정된 메커니즘 사용.
  • 애플리케이션에 정의된 메커니즘이 없는 경우 인증이 수행되지 않습니다.

AuthConfigFactory 에 수행된 업데이트는 즉시 사용할 수 있습니다. 즉 AuthConfigProvider 가 등록되고 기존 애플리케이션과 일치하는 경우 애플리케이션을 재배포할 필요 없이 즉시 사용할 수 있습니다.

JBoss EAP에 배포된 모든 웹 애플리케이션에는 보안 도메인이 있으며, 다음 순서로 해결됩니다.

  1. 배포 설명자 또는 주석에서 다음을 수행합니다.
  2. undertow 하위 시스템의 default-security-domain 특성에 정의된 값입니다.
  3. 기본값은 other 입니다.
참고

이 보안 도메인은 PicketBox 보안 도메인에 대한 참조라고 가정하므로 활성화의 최종 단계는 undertow 하위 시스템에서 application-security-domain 리소스를 사용하여 Elytron에 매핑되도록 합니다.

이 매핑은 다음 중 하나를 수행할 수 있습니다.

  • 예를 들면 다음과 같습니다.

    /subsystem=undertow/application-security-domain=MyAppSecurity:add(security-domain=ApplicationDomain)
    Copy to Clipboard Toggle word wrap
  • 인증 메커니즘 인스턴스를 가져오려면 http-authentication-factory 리소스를 참조합니다. 예를 들면 다음과 같습니다.

    /subsystem=undertow/application-security-domain=MyAppSecurity:add(http-authentication-factory=application-http-authentication)
    Copy to Clipboard Toggle word wrap

Jakarta Authentication 통합을 활성화하기 위한 최소 단계는 다음과 같습니다.

  1. default-security-domain 속성이 기본적으로 다른 사용자로 설정되도록 undertow 하위 시스템에서 정의되지 않은 상태로 둡니다.
  2. 다른 항목의 application-security-domain 매핑을 Elytron 보안 도메인에 추가합니다.

이러한 단계에서 배포와 연결된 보안 도메인은 인증에 사용되는 ServerAuthModule 인스턴스로 전달될 콜백Handler 로 래핑되는 보안 도메인입니다.

추가 옵션

Jakarta Authentication 동작을 추가로 제어할 수 있도록 두 개의 추가 특성이 application-security-domain 리소스에 추가되었습니다.

Expand
표 16.1. application-security-domain 리소스에 추가된 특성
속성설명

enable-jaspi

이 매핑을 사용하는 모든 배포에 대한 Jakarta Authentication 지원을 비활성화하려면 false로 설정할 수 있습니다.

integrated-jaspi

기본적으로 모든 ID는 보안 도메인에서 로드됩니다. false로 설정하면 대신 임시 ID가 생성됩니다.

하위 시스템 설정

배포에 AuthConfigProvider 가 반환되는 구성을 등록하는 한 가지 방법은 elytron 하위 시스템에 jaspi-configuration 을 등록하는 것입니다.

다음 명령은 두 개의 ServerAuthModule 정의가 포함된 구성을 추가하는 방법을 보여줍니다.

/subsystem=elytron/jaspi-configuration=simple-configuration:add(layer=HttpServlet, application-context="default-host /webctx", description="Elytron Test Configuration", server-auth-modules=[{class-name=org.wildfly.security.examples.jaspi.SimpleServerAuthModule, module=org.wildfly.security.examples.jaspi, flag=OPTIONAL, options={a=b, c=d}}, {class-name=org.wildfly.security.examples.jaspi.SecondServerAuthModule, module=org.wildfly.security.examples.jaspi}])
Copy to Clipboard Toggle word wrap

이렇게 하면 다음과 같은 구성이 지속됩니다.

<jaspi>
    <jaspi-configuration name="simple-configuration" layer="HttpServlet" application-context="default-host /webctx" description="Elytron Test Configuration">
        <server-auth-modules>
            <server-auth-module class-name="org.wildfly.security.examples.jaspi.SimpleServerAuthModule" module="org.wildfly.security.examples.jaspi" flag="OPTIONAL">
                <options>
                    <property name="a" value="b"/>
                    <property name="c" value="d"/>
                </options>
            </server-auth-module>
            <server-auth-module class-name="org.wildfly.security.examples.jaspi.SecondServerAuthModule" module="org.wildfly.security.examples.jaspi"/>
        </server-auth-modules>
    </jaspi-configuration>
</jaspi>
Copy to Clipboard Toggle word wrap
참고

name 특성은 관리 모델에서 리소스를 참조할 수 있는 이름일 뿐입니다.

이 구성을 AuthConfigFactory 에 등록할 때 계층application-context 속성이 사용됩니다. 두 속성 모두 와일드카드 일치를 생략할 수 있습니다. description 속성도 선택 사항이며 AuthConfigFactory 에 설명을 제공하는 데 사용됩니다.

구성 내에서 다음 특성을 사용하여 하나 이상의 server-auth-module 인스턴스를 정의할 수 있습니다.

  • class-name - ServerAuthModule 의 정규화된 클래스 이름입니다.
  • module - ServerAuthModule을 로드할 모듈 입니다.
  • flag - 이 모듈이 다른 모듈과 관련하여 작동하는 방식을 나타내는 제어 플래그입니다.
  • 옵션 - 초기화 시 ServerAuthModule 에 전달할 구성 옵션입니다.

이러한 방식으로 정의된 구성은 AuthConfigFactory 에 즉시 등록됩니다. 계층애플리케이션 컨텍스트 와 일치하는 Elytron 보안 프레임워크를 사용하는 기존 배포는 이 구성을 즉시 사용하기 시작합니다.

프로그래밍 방식 설정

Jakarta Authentication 사양에 정의된 API를 사용하면 애플리케이션이 사용자 지정 AuthConfigProvider 인스턴스를 동적으로 등록할 수 있습니다. 그러나 사양은 사용할 실제 구현 또는 구현 인스턴스를 생성하는 표준 방법을 제공하지 않습니다. Elytron 프로젝트에는 배포에서 이를 지원하는 데 사용할 수 있는 간단한 유틸리티가 포함되어 있습니다.

다음 코드 예제에서는 이 API를 사용하여 위의 하위 시스템 구성에 설명된 것과 유사한 구성을 등록하는 방법을 보여줍니다.

String registrationId = org.wildfly.security.auth.jaspi.JaspiConfigurationBuilder.builder("HttpServlet", servletContext.getVirtualServerName() + " " + servletContext.getContextPath())
    .addAuthModuleFactory(SimpleServerAuthModule::new, Flag.OPTIONAL, Collections.singletonMap("a", "b"))
    .addAuthModuleFactory(SecondServerAuthModule::new)
.register();
Copy to Clipboard Toggle word wrap

예를 들어 서블릿의 init() 메서드 내에서 이 코드를 실행하여 해당 배포에 고유한 AuthConfigProvider 를 등록할 수 있습니다. 이 코드 예제에서는 ServletContext 를 컨설팅하여 애플리케이션 컨텍스트도 어셈블했습니다.

register() 메서드는 AuthConfigFactory 에서 이 등록을 직접 제거하는 데 사용할 수도 있는 결과 등록 ID를 반환합니다.

하위 시스템 구성과 마찬가지로 이 호출은 Elytron 보안 프레임워크를 사용하는 모든 웹 애플리케이션에 즉시 적용됩니다.

인증 프로세스

undertow 하위 시스템에서 application-security-domain 리소스의 구성에 따라 ServerAuthModule 에 전달된 CallbackHandler 는 다음 모드 중 하나에서 작동할 수 있습니다.

통합 모드

통합 모드에서 작동하는 경우 ServerAuthModule 인스턴스가 실제 인증을 처리하지만 해당 SecurityDomain에서 참조하는 Security Realms를 사용하여 참조된 Security Domain 에서 생성된 ID가 로드됩니다 . 이 모드에서는 서블릿 컨테이너 내에서 할당할 역할을 재정의할 수 있습니다.

이 모드의 장점은 ServerAuthModule이 ID 로드를 위한 Elytron 구성을 활용하여 데이터베이스 및 LDAP와 같은 일반적인 위치에 저장된 ID를 로드할 수 있다는 것입니다. ServerAuthModule 은 이러한 위치를 인식할 필요가 없습니다. 또한 역할 및 권한 매핑과 같은 기타 Elytron 구성을 적용할 수 있습니다. 참조된 SecurityDomain 은 SASL 인증 또는 기타 비 JASPI 애플리케이션에 대해 참조할 수도 있으며, 모두 공통 ID 저장소에서 지원합니다.

Expand
표 16.2. 통합 모드에서 콜백Handlers 메서드의 작동.
작업설명

PasswordValidationCallback

사용자 이름과 암호는 인증을 수행하기 위해 SecurityDomain 과 함께 사용됩니다. 성공하면 인증된 ID가 있습니다.

CallerPrincipalCallback

콜백 은 요청이 웹 애플리케이션에 도달한 후 사용할 수 있는 인증된 ID 또는 ID를 설정하는 데 사용됩니다.

참고

PasswordValidationCallback 을 통해 인증된 ID가 이미 설정된 경우 이 콜백 은 런스 요청으로 해석됩니다. 이 경우 인증된 ID가 이 콜백 에 지정된 ID로 실행되도록 권한 부여 검사를 수행합니다. PasswordValidationCallback 에서 인증된 ID를 설정하지 않은 경우 ServerAuthModule 에서 인증 단계를 처리한 것으로 간주됩니다.

null 주체 및 이름을 사용하여 콜백 이 수신되면 다음을 수행합니다.

  • 인증된 ID가 이미 설정된 경우 권한 부여가 해당 ID로 수행됩니다.
  • ID를 설정하지 않은 경우 익명 ID에 대한 권한 부여가 수행됩니다.

익명 ID에 대한 권한 부여가 수행되는 경우 익명 ID에 LoginPermission 을 부여하도록 SecurityDomain 을 구성해야 합니다.

GroupPrincipalCallback

이 모드에서는 보안 도메인에 구성된 로드, 역할 디코딩 및 역할 매핑이 ID를 설정하는 데 사용됩니다. 이 콜백 이 수신되면 지정된 그룹을 사용하여 ID에 할당된 역할을 결정합니다. 요청은 서블릿 컨테이너에 있으며 이러한 역할은 서블릿 컨테이너에만 표시됩니다.

통합되지 않은 모드

통합되지 않은 모드에서 작동하는 경우 ServerAuthModule은 모든 인증 및 ID 관리를 완벽하게 담당합니다. 지정된 콜백을 사용하여 ID를 설정할 수 있습니다. 결과 ID는 SecurityDomain 에서 생성되지만 참조된 SecurityRealms 에 저장된 ID와 독립적입니다.

이 모드의 장점은 간단한 SecurityDomain 정의를 넘어 어떤 것도 요구하지 않고도 ID를 완전히 처리할 수 있는 JASPI 구성을 애플리케이션 서버에 배포할 수 있다는 점입니다. 이 SecurityDomain 에는 런타임 시 사용할 ID를 실제로 포함할 필요가 없습니다. 이 모드의 단점은 이제 ServerAuthModule 이 모든 ID 처리를 담당하므로 구현이 훨씬 더 복잡해질 수 있다는 것입니다.

Expand
표 16.3. 통합되지 않은 모드에서 콜백Handlers 메서드의 작업입니다.
작업설명

PasswordValidationCallback

이 모드에서는 콜백 이 지원되지 않습니다. 이 모드의 목적은 ServerAuthModule 이 참조된 SecurityDomain 과 독립적으로 작동하기 위한 것입니다. 암호를 검증하도록 요청하는 것은 적합하지 않습니다.

CallerPrincipalCallback

콜백 은 결과 ID의 주체를 설정하는 데 사용됩니다. ServerAuthModule 은 모든 ID 검사 요구 사항을 처리하므로 보안 도메인에 ID가 존재하고 권한 부여 확인이 수행되지 않는지 확인하기 위해 검사가 수행되지 않습니다.

콜백 이 null 주체 및 이름으로 수신되면 ID가 익명 ID로 설정됩니다. ServerAuthModule 이 결정을 내리기 때문에 권한 부여 확인은 SecurityDomain 을 사용하여 수행되지 않습니다.

GroupPrincipalCallback

SecurityDomain 에서 로드하지 않고 이 모드에서 ID가 생성되므로 기본적으로 역할이 할당되지 않습니다. 이 콜백 이 수신되면 요청이 서블릿 컨테이너에 있는 동안 그룹을 가져와 결과 ID에 할당합니다. 이러한 역할은 서블릿 컨테이너에만 표시됩니다.

validateRequest

ServerAuthContext 에서 validateRequest 를 호출하는 동안 개별 ServerAuthModule 인스턴스가 정의된 순서대로 호출됩니다. 각 모듈에 대해 컨트롤 플래그를 지정할 수도 있습니다. 이 플래그는 응답을 해석하는 방법과 처리가 다음 서버 인증 모듈로 계속 진행되어야 하는지 또는 즉시 반환해야 하는지 정의합니다.

컨트롤 플래그

구성이 elytron 하위 시스템 내에서 제공되거나 JaspiConfigurationBuilder API를 사용하는지 여부에 따라 컨트롤 플래그를 각 ServerAuthModule 과 연결할 수 있습니다. 지정하지 않으면 기본값은 REQUIRED 입니다. 플래그에는 결과에 따라 다음과 같은 의미가 있습니다.

Expand
플래그AuthStatus.SEND_SUCCESSAuthStatus.SEND_FAILURE, AuthStatus.SEND_CONTINUE

필수 항목

검증은 나머지 모듈로 계속됩니다. 나머지 모듈의 요구 사항이 충족되면 요청을 계속할 수 있습니다.

검증은 나머지 모듈로 계속됩니다. 그러나 결과에 관계없이 검증에 성공하지 않고 제어 권한이 클라이언트로 돌아갑니다.

필수 사항

검증은 나머지 모듈로 계속됩니다. 나머지 모듈의 요구 사항이 충족되면 요청을 계속할 수 있습니다.

요청은 즉시 클라이언트로 반환됩니다.

충분하지 않음

검증은 이전에 필수 또는 필수 모듈이 AuthStatus. SUCCESS 이외의 AuthStatus 를 반환하지 않은 경우 성공 및 완료로 간주됩니다. 요청이 보안 리소스의 권한 부여로 진행됩니다.

검증을 통해 나머지 모듈 목록이 계속 중단됩니다. 이 상태는 REQUIRED 또는 REQUISITE 모듈이 없는 경우에만 결정에 영향을 미칩니다.

선택 사항

검증은 필수 또는 필수 모듈이 SUCCESS 를 반환하지 않은 경우에도 나머지 모듈에 계속 유지됩니다. 이는 검증이 성공으로 간주되고 권한 부여 단계 및 보안 리소스로 진행하기 위한 요청을 진행하기에 충분합니다.

검증을 통해 나머지 모듈 목록이 계속 중단됩니다. 이 상태는 REQUIRED 또는 REQUISITE 모듈이 없는 경우에만 결정에 영향을 미칩니다.

참고

모든 ServerAuthModule 인스턴스의 경우 AuthException 이 발생하면 추가 모듈 호출 없이 클라이언트에 즉시 오류가 보고됩니다.

secureResponse

secureResponse 호출 중에 각 ServerAuthModule 이 호출되지만 이번에는 모듈이 secureResponse 에서 작업을 수행하는 역순으로 호출됩니다. 모듈이 validateResponse 에서 작업을 수행한 경우 이를 추적할 모듈의 책임이 있습니다.

control 플래그는 secureResponse 처리에 영향을 미치지 않습니다. 다음 중 하나가 true이면 처리가 종료됩니다.

  • 모든 ServerAuthModule 인스턴스가 호출되었습니다.
  • 모듈은 AuthStatus.SEND_FAILURE 를 반환합니다.
  • 모듈에서 AuthException 이 발생합니다.
보안 ID 생성

인증 프로세스가 완료되면 배포에 대한 org.wildfly.security.auth.server.SecurityIdentity Callbacks to the Callback Handler 의 결과로 생성됩니다. 콜백에 따라 SecurityDomain 에서 직접 로드된 ID이거나 콜백에서 설명하는 임시 ID가 됩니다. 이 SecurityIdentity 는 다른 인증 메커니즘에 대해 수행하는 것과 동일한 방식으로 요청과 연결됩니다.

17장. 자카르타 보안

17.1. 자카르타 보안 정보

Jakarta Security는 인증 및 ID 저장소를 위한 플러그인 인터페이스와 프로그래밍 방식의 보안을 위한 액세스 지점을 제공하는 새로운 주입형 SecurityContext 인터페이스를 정의합니다. 사양에 대한 자세한 내용은 Jakarta Security Specification 을 참조하십시오.

17.2. Elytron을 사용하여 자카르타 보안 구성

elytron 하위 시스템을 사용하여 자카르타 보안 활성화

Jakarta Security에 정의된 SecurityContext 인터페이스는 Jakarta Authorization 정책 공급자를 사용하여 현재 인증된 ID에 액세스합니다. SecurityContext 인터페이스를 사용하도록 배포하려면 Jakarta Authorization 구성을 관리하고 기본 Jakarta Authorization 정책 공급자를 정의하도록 elytron 하위 시스템을 구성해야 합니다.

  1. 레거시 보안 하위 시스템에서 자카르타 권한 부여를 비활성화합니다. Jakarta Authorization이 이미 Elytron에서 관리되도록 구성된 경우 이 단계를 건너뜁니다.

    /subsystem=security:write-attribute(name=initialize-jacc, value=false)
    Copy to Clipboard Toggle word wrap
  2. OR lyron 하위 시스템에서 자카르타 권한 부여 정책 프로바이더를 정의하고 서버를 다시 로드합니다.

    /subsystem=elytron/policy=jacc:add(jacc-policy={})
    reload
    Copy to Clipboard Toggle word wrap
웹 애플리케이션의 자카르타 보안 활성화

웹 애플리케이션에 자카르타 보안을 사용하려면 웹 애플리케이션을 Elytron http-authentication-factory 또는 security- domain 과 연결해야 합니다. 그러면 Elytron 보안 핸들러가 설치되고 배포에 대한 Elytron 보안 프레임워크가 활성화됩니다.

Jakarta Security를 활성화하기 위한 최소 단계는 다음과 같습니다.

  1. default-security-domain 속성이 기본적으로 다른 사용자로 설정되도록 undertow 하위 시스템에서 정의되지 않은 상태로 둡니다.
  2. 다른 항목의 application-security-domain 매핑을 Elytron 보안 도메인에 추가합니다.

    /subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain, integrated-jaspi=false)
    Copy to Clipboard Toggle word wrap

    integrated-jaspifalse로 설정하면 애드혹 ID가 동적으로 생성됩니다.

Jakarta Security는 Jakarta Authentication을 기반으로 합니다. Jakarta Authentication 구성에 대한 자세한 내용은 Elytron을 사용하여 Jakarta Authentication Security 구성을 참조하십시오.

18장. 자카르타 배치 애플리케이션 개발

JBoss EAP는 자카르타 EE 사양에 정의된 Jakarta Batch를 지원합니다. Jakarta Batch에 대한 자세한 내용은 Jakarta Batch 를 참조하십시오.

JBoss EAP의 batch-jberet 하위 시스템은 배치 구성 및 모니터링을 용이하게 합니다.

JBoss EAP에서 배치 처리를 사용하도록 애플리케이션을 구성하려면 필요한 종속성 을 지정해야 합니다. 배치 처리를 위한 추가 JBoss EAP 기능으로는 작업 사양 언어(JSL) 상속배치 속성 주입이 포함됩니다.

18.1. 필수 배치 종속성

배치 애플리케이션을 JBoss EAP에 배포하려면 애플리케이션의 pom.xml 에서 배치 처리에 필요한 몇 가지 추가 종속성을 선언해야 합니다. 이러한 필수 종속성의 예는 다음과 같습니다. 종속 항목 대부분은 JBoss EAP에 이미 포함되어 있으므로 제공된 범위가 설정됩니다.

예: pom.xml 배치 종속성

<dependencies>
    <dependency>
        <groupId>org.jboss.spec.javax.batch</groupId>
        <artifactId>jboss-batch-api_1.0_spec</artifactId>
        <scope>provided</scope>
    </dependency>

    <dependency>
        <groupId>javax.enterprise</groupId>
        <artifactId>cdi-api</artifactId>
        <scope>provided</scope>
    </dependency>

    <dependency>
        <groupId>org.jboss.spec.javax.annotation</groupId>
        <artifactId>jboss-annotations-api_1.2_spec</artifactId>
        <scope>provided</scope>
    </dependency>

    <!-- Include your application's other dependencies. -->
    ...
</dependencies>
Copy to Clipboard Toggle word wrap

18.2. JSL(작업 사양 언어) 상속

JBoss EAP batch-jberet 하위 시스템의 기능은 작업 정의의 일반적인 부분을 추상화하기 위해 JSL(작업 사양 언어) 상속을 사용하는 기능입니다.

동일한 작업 XML 파일 내의 단계 및 흐름 상속

상위 요소(예: step 및 flow)는 직접 실행하지 못하도록 abstract="true" 속성으로 표시됩니다. 하위 요소에는 상위 요소를 가리키는 상위 속성이 포함됩니다.

<job id="inheritance" xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0">
    <!-- abstract step and flow -->
    <step id="step0" abstract="true">
        <batchlet ref="batchlet0"/>
    </step>

    <flow id="flow0" abstract="true">
        <step id="flow0.step1" parent="step0"/>
    </flow>

    <!-- concrete step and flow -->
    <step id="step1" parent="step0" next="flow1"/>

    <flow id="flow1" parent="flow0"/>
</job>
Copy to Clipboard Toggle word wrap
다른 작업 XML 파일에서 단계 상속

하위 요소(예: step 및 job)에는 다음이 포함됩니다.

  • 상위 요소를 포함하는 .xml 확장자 없이 작업 XML 파일 이름을 지정하는 jsl-name 속성.
  • 상위 속성 - jsl-name 으로 지정된 작업 XML 파일의 상위 요소를 가리킵니다.

상위 요소는 직접 실행에서 제외하기 위해 abstract="true" 속성으로 표시됩니다.

예: chunk-child.xml

<job id="chunk-child" xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0">
    <step id="chunk-child-step" parent="chunk-parent-step" jsl-name="chunk-parent">
    </step>
</job>
Copy to Clipboard Toggle word wrap

예: chunk-parent.xml

<job id="chunk-parent" >
    <step id="chunk-parent-step" abstract="true">
        <chunk checkpoint-policy="item" skip-limit="5" retry-limit="5">
            <reader ref="R1"></reader>
            <processor ref="P1"></processor>
            <writer ref="W1"></writer>

            <checkpoint-algorithm ref="parent">
                <properties>
                    <property name="parent" value="parent"></property>
                </properties>
            </checkpoint-algorithm>
            <skippable-exception-classes>
                <include class="java.lang.Exception"></include>
                <exclude class="java.io.IOException"></exclude>
            </skippable-exception-classes>
            <retryable-exception-classes>
                <include class="java.lang.Exception"></include>
                <exclude class="java.io.IOException"></exclude>
            </retryable-exception-classes>
            <no-rollback-exception-classes>
                <include class="java.lang.Exception"></include>
                <exclude class="java.io.IOException"></exclude>
            </no-rollback-exception-classes>
        </chunk>
    </step>
</job>
Copy to Clipboard Toggle word wrap

18.3. 배치 속성 삽입

JBoss EAP batch-jberet 하위 시스템의 기능은 배치 아티팩트 클래스의 필드에 삽입된 작업 XML 파일에 속성을 정의하는 기능입니다. 작업 XML 파일에 정의된 속성은 @Inject 및 @ BatchProperty 주석을 사용하여 필드에 삽입할 수 있습니다.

주입 필드는 다음 Java 유형 중 하나일 수 있습니다.

  • java.lang.String
  • java.lang.StringBuilder
  • java.lang.StringBuffer
  • 기본 유형 및 래퍼 유형:

    • 부울,부울
    • int,정수
    • 두 배 , 주셔서 감사합니다.
    • ,
    • 문자,문자
    • 유동,유동
    • 음,
    • 바이트,바이트
  • java.math.BigInteger
  • java.math.BigDecimal
  • java.net.URL
  • java.net.URI
  • java.io.File
  • java.util.jar.JarFile
  • java.util.Date
  • java.lang.Class
  • java.net.Inet4Address
  • java.net.Inet6Address
  • java.util.List, List<?>, List<String>
  • java.util.Set, Set<?>, Set<String>
  • java.util.Map, Map<?, ?>, Map<String, String>, Map<String, ?>
  • java.util.logging.Logger
  • java.util.regex.Pattern
  • javax.management.ObjectName

다음 배열 유형도 지원됩니다.

  • java.lang.String[]
  • 기본 유형 및 래퍼 유형:

    • boolean[], 부울[]
    • int[], Integer[]
    • double[], but []
    • long[], Long[]
    • characters[], 문자[]
    • floating[], Float[]
    • short[], short[]
    • byte[], Byte[]
  • java.math.BigInteger[]
  • java.math.BigDecimal[]
  • java.net.URL[]
  • java.net.URI[]
  • java.io.File[]
  • java.util.jar.JarFile[]
  • java.util.zip.ZipFile[]
  • java.util.Date[]
  • java.lang.Class[]

다음은 배치 속성 삽입을 사용하는 몇 가지 예입니다.

다양한 유형으로 배치 클래스에 숫자를 삽입

예제: 작업 XML 파일

<batchlet ref="myBatchlet">
    <properties>
        <property name="number" value="10"/>
    </properties>
</batchlet>
Copy to Clipboard Toggle word wrap

예제: 아티팩트 클래스

@Named
public class MyBatchlet extends AbstractBatchlet {
    @Inject
    @BatchProperty
    int number;  // Field name is the same as batch property name.

    @Inject
    @BatchProperty (name = "number")  // Use the name attribute to locate the batch property.
    long asLong;  // Inject it as a specific data type.

    @Inject
    @BatchProperty (name = "number")
    Double asDouble;

    @Inject
    @BatchProperty (name = "number")
    private String asString;

    @Inject
    @BatchProperty (name = "number")
    BigInteger asBigInteger;

    @Inject
    @BatchProperty (name = "number")
    BigDecimal asBigDecimal;
}
Copy to Clipboard Toggle word wrap

임의의 배열로 Batchlet 클래스에 숫자 시퀀스 삽입

예제: 작업 XML 파일

<batchlet ref="myBatchlet">
    <properties>
        <property name="weekDays" value="1,2,3,4,5,6,7"/>
    </properties>
</batchlet>
Copy to Clipboard Toggle word wrap

예제: 아티팩트 클래스

@Named
public class MyBatchlet extends AbstractBatchlet {
    @Inject
    @BatchProperty
    int[] weekDays;  // Array name is the same as batch property name.

    @Inject
    @BatchProperty (name = "weekDays")  // Use the name attribute to locate the batch property.
    Integer[] asIntegers;  // Inject it as a specific array type.

    @Inject
    @BatchProperty (name = "weekDays")
    String[] asStrings;

    @Inject
    @BatchProperty (name = "weekDays")
    byte[] asBytes;

    @Inject
    @BatchProperty (name = "weekDays")
    BigInteger[] asBigIntegers;

    @Inject
    @BatchProperty (name = "weekDays")
    BigDecimal[] asBigDecimals;

    @Inject
    @BatchProperty (name = "weekDays")
    List asList;

    @Inject
    @BatchProperty (name = "weekDays")
    List<String> asListString;

    @Inject
    @BatchProperty (name = "weekDays")
    Set asSet;

    @Inject
    @BatchProperty (name = "weekDays")
    Set<String> asSetString;
}
Copy to Clipboard Toggle word wrap

배치 클래스에 클래스 속성 삽입

예제: 작업 XML 파일

<batchlet ref="myBatchlet">
    <properties>
        <property name="myClass" value="org.jberet.support.io.Person"/>
    </properties>
</batchlet>
Copy to Clipboard Toggle word wrap

예제: 아티팩트 클래스

@Named
public class MyBatchlet extends AbstractBatchlet {
    @Inject
    @BatchProperty
    private Class myClass;
}
Copy to Clipboard Toggle word wrap

속성 주입을 위해 주석이 있는 필드에 기본값 할당

타겟 배치 속성이 작업 XML 파일에 정의되지 않은 경우 아티팩트 Java 클래스의 필드에 기본값을 할당할 수 있습니다. target 속성이 유효한 값으로 확인되면 해당 속성이 해당 필드에 삽입됩니다. 그렇지 않으면 값이 삽입되지 않고 기본 필드 값이 사용됩니다.

예제: 아티팩트 클래스

/**
 Comment character. If commentChar batch property is not specified in job XML file, use the default value '#'.
 */
@Inject
@BatchProperty
private char commentChar = '#';
Copy to Clipboard Toggle word wrap

19장. 클라이언트 구성

19.1. wildfly-config.xml 파일을 사용한 클라이언트 설정

JBoss EAP 7.1은 모든 클라이언트 구성을 하나의 구성 파일로 통합하기 위한 와일드플ly -config.xml 파일을 도입했습니다.

다음 표는 JBoss EAP에서 the wildfly-config.xml 파일을 사용하여 수행할 수 있는 클라이언트 및 구성 유형과 각 구성의 참조 스키마 링크에 대한 링크를 설명합니다.

Expand
클라이언트 설정스키마 위치/구성 정보

인증 클라이언트

스키마 참조는 EAP_HOME/docs/schema/elytron-client-1_2.xsd 에서 제품 설치에 제공됩니다.

스키마는 http://www.jboss.org/schema/jbossas/elytron-client-1_2.xsd 에도 게시되어 있습니다.

자세한 내용 및 구성 예는 the wildfly-config.xml 파일을 사용하여 클라이언트 인증 구성을 참조하십시오.

자세한 내용은 JBoss EAP에 대한 ID 관리 구성 방법의 Elytron Client로 클라이언트 인증 구성에서 확인할 수 있습니다.

Jakarta Enterprise Beans 클라이언트

스키마 참조는 EAP_HOME/docs/schema/wildfly-client-ejb_3_0.xsd 에서 제품 설치에 제공됩니다.

스키마는 http://www.jboss.org/schema/jbossas/wildfly-client-ejb_3_0.xsd 에도 게시되어 있습니다.

자세한 내용 및 구성에 대한 자세한 내용은 Jakarta Enterprise Beans Client Configuration Using the wildfly-config.xml 파일을 참조하십시오.

또 다른 간단한 예는 JBoss EAP 의 마이그레이션 가이드의 Jakarta Enterprise Bean Client에서 Elytron 으로 마이그레이션 섹션에 있습니다.

HTTP 클라이언트

스키마 참조는 EAP_HOME/docs/schema/wildfly-http-client_1_0.xsd 에서 제품 설치에 제공됩니다.

스키마는 http://www.jboss.org/schema/jbossas/wildfly-http-client_1_0.xsd 에도 게시되어 있습니다.

참고

이 기능은 기술 프리뷰로 만 제공됩니다.

자세한 내용 및 구성 예는 HTTP 클라이언트 구성을 참조하십시오 .

클라이언트 원격화

스키마 참조는 EAP_HOME/docs/schema/jboss-remoting_5_0.xsd 에서 제품 설치에 제공됩니다.

스키마는 http://www.jboss.org/schema/jbossas/jboss-remoting_5_0.xsd 에도 게시되어 있습니다.

자세한 내용 및 구성에 대해서는 클라이언트 구성 제거를 참조하십시오.

XNIO 작업자 클라이언트

스키마 참조는 EAP_HOME/docs/schema/xnio_3_5.xsd 에서 제품 설치에 제공됩니다.

스키마는 http://www.jboss.org/schema/jbossas/xnio_3_5.xsd 에도 게시되어 있습니다.

자세한 내용 및 구성에 대한 자세한 내용은 기본 XNIO 작업자 구성에서 the wildfly-config.xml 파일을 참조하십시오.

19.1.1. wildfly-config.xml 파일을 사용한 클라이언트 인증 구성

urn:elytron: client:1.2 네임스페이스에 있는 authentication- client 요소를 사용하여 wildfly-config.xml 파일을 사용하여 클라이언트 인증 정보를 구성할 수 있습니다. 이 섹션에서는 이 요소를 사용하여 클라이언트 인증을 구성하는 방법에 대해 설명합니다.

인증-클라이언트 요소 및 속성

authentication-client 요소에는 하위 요소와 함께 다음 최상위 하위 요소를 선택적으로 포함할 수 있습니다.

credential-stores

이 선택적 요소는 구성의 다른 위치에서 참조되는 인증 정보 저장소를 구성 내에 자격 증명을 포함하는 대안으로 정의합니다.

원하는 수의 자격 증명 저장소 요소를 포함할 수 있습니다.

예: credentials-stores 구성

<configuration>
  <authentication-client xmlns="urn:elytron:client:1.2">
    <credential-stores>
      <credential-store name="..." type="..." provider="..." >
        <attributes>
          <attribute name="..." value="..." />
        </attributes>
        <protection-parameter-credentials>...</protection-parameter-credentials>
      </credential-store>
    </credential-stores>
  </authentication-client>
</configuration>
Copy to Clipboard Toggle word wrap

credential-store

이 요소는 구성의 다른 위치에서 참조되는 자격 증명 저장소를 정의합니다.

다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

name

자격 증명 저장소의 이름입니다. 이 속성은 필수입니다.

type

자격 증명 저장소 유형입니다. 이 속성은 선택 사항입니다.

공급자

자격 증명 저장소를 로드하는 데 사용할 java.security.Provider 의 이름입니다. 이 속성은 선택 사항입니다.

다음 하위 요소 중 하나와 하나만 포함할 수 있습니다.

속성

이 요소는 자격 증명 저장소를 초기화하는 데 사용되는 구성 속성을 정의하며 구성에 필요한 만큼 반복될 수 있습니다.

예: 특성 구성

<attributes>
  <attribute name="..." value="..." />
</attributes>
Copy to Clipboard Toggle word wrap

protection-parameter-credentials

이 요소에는 자격 증명 저장소를 초기화할 때 사용할 보호 매개 변수로 조합할 하나 이상의 자격 증명이 포함되어 있습니다.

인증 정보 저장소 구현에 따라 하나 이상의 다음 하위 요소를 포함할 수 있습니다.

예: protection-parameter-credentials 구성

<protection-parameter-credentials>
  <key-store-reference>...</key-store-reference>
  <credential-store-reference store="..." alias="..." clear-text="..." />
  <clear-password password="..." />
  <key-pair public-key-pem="..." private-key-pem="..." />
  <certificate private-key-pem="..." pem="..." />
  <public-key-pem>...</public-key-pem>
  <bearer-token value="..." />
  <oauth2-bearer-token token-endpoint-uri="...">...</oauth2-bearer-token>
</protection-parameter-credentials>
Copy to Clipboard Toggle word wrap

key-store-reference

현재 JBoss EAP의 인증 메커니즘에서 사용하지 않는 이 요소는 키 저장소에 대한 참조를 정의합니다.

다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

key-store-name

키 저장소 이름입니다. 이 속성은 필수입니다.

alias

참조된 키 저장소에서 로드할 항목의 별칭입니다. 이는 단일 항목만 포함하는 키 저장소에만 대해 생략할 수 있습니다.

및 다음 하위 요소 중 하나만 포함할 수 있습니다.

예: 키 저장소-참조 구성

<key-store-reference key-store-name="..." alias="...">
  <key-store-clear-password password="..." />
  <key-store-credential>...</key-store-credential>
</key-store-reference>
Copy to Clipboard Toggle word wrap

credential-store-reference

이 요소는 자격 증명 저장소에 대한 참조를 정의합니다.

다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

저장

자격 증명 저장소 이름입니다.

alias

참조된 자격 증명 저장소에서 로드할 항목의 별칭입니다. 이는 단일 항목만 포함하는 키 저장소에만 대해 생략할 수 있습니다.

clear-text

일반 텍스트 암호.

clear-password
이 요소는 일반 텍스트 암호를 정의합니다.
key-pair

현재 JBoss EAP의 인증 메커니즘에서 사용하지 않는 이 요소는 공개 및 개인 키 쌍을 정의합니다.

다음 하위 요소를 포함할 수 있습니다.

public-key-pem
현재 JBoss EAP의 인증 메커니즘에서 사용하지 않는 이 요소는 PEM 인코딩 공개 키를 정의합니다.
private-key-pem
이 요소는 PEM 인코딩 개인 키를 정의합니다.
certificate

현재 JBoss EAP의 인증 메커니즘에서 사용하지 않는 이 요소는 인증서를 지정합니다.

다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

private-key-pem

PEM으로 인코딩된 개인 키입니다.

PEM

해당 인증서입니다.

bearer-token
이 요소는 전달자 토큰을 정의합니다.
oauth2-bearer-token

이 요소는 OAuth 2 전달자 토큰을 정의합니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

token-endpoint-uri

토큰 엔드포인트의 URI입니다.

다음 하위 요소 중 하나와 하나만 포함할 수 있습니다.

client-credentials

이 요소는 클라이언트 자격 증명을 정의합니다.

다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

client-id

클라이언트 ID입니다. 이 속성은 필수입니다.

client-secret

클라이언트 비밀입니다. 이 속성은 필수입니다.

resource-owner-credentials

이 요소는 리소스 소유자 자격 증명을 정의합니다.

다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

name

리소스 이름입니다. 이 속성은 필수입니다.

암호문

암호. 이 속성은 필수입니다.

key-stores

이 선택적 요소는 구성의 다른 위치에서 참조되는 키 저장소를 정의합니다.

예: 키 저장소 구성

<configuration>
  <authentication-client xmlns="urn:elytron:client:1.2">
    <key-stores>
      <key-store name="...">
        <!-- The following 3 elements specify where to load the keystore from. -->
        <file name="..." />
        <load-from uri="..." />
        <resource name="..." />
        <!-- One of the following to specify the protection parameter to unlock the keystore. -->
        <key-store-clear-password password="..." />
        <key-store-credential>...</key-store-credential>
      </key-store>
    </key-stores>
   ...
  </authentication-client>
</configuration>
Copy to Clipboard Toggle word wrap

key-store

이 선택적 요소는 구성의 다른 위치에서 참조되는 키 저장소를 정의합니다.

키 저장소에는 다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

name

키 저장소의 이름입니다. 이 속성은 필수입니다.

type

키 저장소 유형(예: JCEKS )입니다. 이 속성은 필수입니다.

공급자

자격 증명 저장소를 로드하는 데 사용할 java.security.Provider 의 이름입니다. 이 속성은 선택 사항입니다.

wrap-passwords

true인 경우 암호가 래핑됩니다. 암호는 명확한 암호 콘텐츠를 가지고 UTF-8로 인코딩하고 결과 바이트를 비밀 키로 저장하여 저장됩니다. 기본값은 false입니다.

키 저장소를 로드할 위치를 정의하는 다음 요소 중 정확히 하나가 포함되어야 합니다.

또한 키 저장소를 초기화할 때 사용할 protection 매개 변수를 지정하는 다음 요소 중 하나를 포함해야 합니다.

file

이 요소는 키 저장소 파일의 이름을 지정합니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

name

정규화된 파일 경로 및 파일 이름.

load-from

이 요소는 키 저장소 파일의 URI를 지정합니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

uri

키 저장소 파일의 URI입니다.

resource

이 요소는 스레드 컨텍스트 클래스 로더에서 로드할 리소스의 이름을 지정합니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

name

리소스의 이름.

key-store-clear-password

이 요소는 일반 텍스트 암호를 지정합니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

암호

일반 텍스트 암호.

key-store-credential

이 요소는 이 키 저장소에 액세스하기 위해 보호 매개 변수로 사용할 항목을 가져오는 다른 키 저장소에 대한 참조를 지정합니다.

key-store-credential 요소에는 다음 속성이 있습니다.

Expand
특성 이름특성 설명

key-store-name

키 저장소 이름입니다. 이 속성은 필수입니다.

alias

참조된 키 저장소에서 로드할 항목의 별칭입니다. 이는 단일 항목만 포함하는 키 저장소에만 대해 생략할 수 있습니다.

및 다음 하위 요소 중 하나만 포함할 수 있습니다.

예: key-store-credential 구성

<key-store-credential key-store-name="..." alias="...">
  <key-store-clear-password password="..." />
  <key-store-credential>...</key-store-credential>
</key-store-credential>
Copy to Clipboard Toggle word wrap

authentication-rules

이 요소는 아웃바운드 연결과 일치하는 규칙을 정의하여 적절한 인증 구성을 적용합니다. 인증 구성이 필요한 경우 액세스한 리소스의 URI와 선택적 추상 유형 및 추상 유형 기관이 구성에 정의된 규칙과 일치하여 사용할 인증 구성을 식별합니다.

이 요소에는 하나 이상의 하위 규칙 요소가 포함될 수 있습니다.

예: authentication-rules 구성

<configuration>
  <authentication-client xmlns="urn:elytron:client:1.2">
    ...
    <authentication-rules>
      <rule use-configuration="...">
        ...
      </rule>
     </authentication-rules>
     ...
  </authentication-client>
</configuration>
Copy to Clipboard Toggle word wrap

규칙

이 요소는 아웃바운드 연결과 일치하는 규칙을 정의하여 적절한 인증 구성을 적용합니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

use-configuration

규칙이 일치할 때 선택되는 인증 구성입니다.

인증 구성 규칙 일치는 SSL 컨텍스트 규칙 일치와 독립적입니다. 인증 규칙 구조는 SSL 컨텍스트 규칙 구조와 동일합니다. 단, SSL 컨텍스트 규칙은 SSL 컨텍스트 규칙을 참조합니다.

다음 하위 요소를 포함할 수 있습니다.

예: 인증을 위한 규칙 구성

<rule use-configuration="...">
    <!-- At most one of the following two can be defined. -->
    <match-no-user />
    <match-user name="..." />
    <!-- Each of the following can be defined at most once. -->
    <match-protocol name="..." />
    <match-host name="..." />
    <match-path name="..." />
    <match-port number="..." />
    <match-urn name="..." />
    <match-domain name="..." />
    <match-abstract-type name="..." authority="..." />
</rule>
Copy to Clipboard Toggle word wrap

match-no-user
이 규칙은 URI에 포함된 user-info 가 없는 경우와 일치합니다.
match-user
이 규칙은 URI에 포함된 user-info 가 이 요소에 지정된 name 특성과 일치하는 경우 일치합니다.
match-protocol
이 규칙은 URI 내의 프로토콜이 이 요소에 지정된 프로토콜 이름 특성과 일치하는 경우 일치합니다.
match-host
이 규칙은 URI 내에 지정된 호스트 이름이 이 요소에 지정된 호스트 이름 특성과 일치하는 경우 일치합니다.
match-path
이 규칙은 URI 내에 지정된 경로가 이 요소에 지정된 경로 이름 특성과 일치하는 경우 일치합니다.
match-port
이 규칙은 URI 내에 지정된 포트 번호가 이 요소에 지정된 포트 번호 특성과 일치하는 경우 일치합니다. 이는 URI 내에 지정된 번호와 프로토콜에서 파생된 기본 포트 번호와 일치하지 않습니다.
match-urn
이 규칙은 URI의 체계별 부분이 이 요소에 지정된 name 특성과 일치하는 경우 일치합니다.
match-domain-name
이 규칙은 URI의 프로토콜이 domain 이고 URI의 체계별 부분이 이 요소에 지정된 name 특성과 일치하는 경우 일치합니다.
match-abstract-type
이 규칙은 추상 유형이 name 특성과 일치하고 authority가 이 요소에 지정된 authority 속성과 일치하는 경우 일치합니다.
authentication-configurations

이 요소는 인증 규칙에 따라 선택할 명명된 인증 구성을 정의합니다.

하나 이상의 구성 요소를 포함할 수 있습니다.

예: authentication-configurations 구성

<configuration>
  <authentication-client xmlns="urn:elytron:client:1.2">
    <authentication-configurations>
      <configuration name="...">
        <!-- Destination Overrides. -->
        <set-host name="..." />
        <set-port number="..." />
        <set-protocol name="..." />
        <!-- At most one of the following two elements. -->
        <set-user-name name="..." />
        <set-anonymous />
        <set-mechanism-realm name="..." />
        <rewrite-user-name-regex pattern="..." replacement="..." />
        <sasl-mechanism-selector selector="..." />
        <set-mechanism-properties>
          <property key="..." value="..." />
        </set-mechanism-properties>
        <credentials>...</credentials>
        <set-authorization-name name="..." />
        <providers>...</providers>
        <!-- At most one of the following two elements. -->
        <use-provider-sasl-factory />
        <use-service-loader-sasl-factory module-name="..." />
      </configuration>
    </authentication-configurations>
  </authentication-client>
</configuration>
Copy to Clipboard Toggle word wrap

설정

이 요소는 인증 규칙에 따라 선택할 명명된 인증 구성을 정의합니다.

다음 하위 요소를 포함할 수 있습니다.

set-host-name

이 요소는 인증된 호출의 호스트 이름을 재정의합니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

name

호스트 이름입니다.

set-port-number

이 요소는 인증된 호출의 포트 번호를 재정의합니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

숫자

포트 번호입니다.

set-protocol

이 요소는 인증된 호출의 프로토콜을 재정의합니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

name

프로토콜.

set-user-name

이 요소는 인증에 사용할 사용자 이름을 설정합니다. set-anonymous 요소와 함께 사용하면 안 됩니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

name

인증에 사용할 사용자 이름입니다.

set-anonymous
요소는 익명 인증으로 전환하는 데 사용됩니다. set-user-name 요소와 함께 사용해서는 안 됩니다.
set-mechanism-realm-name

이 요소는 필요한 경우 SASL 메커니즘에서 선택할 영역의 이름을 지정합니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

name

영역의 이름입니다.

rewrite-user-name-regex

이 요소는 정규 표현식 패턴을 정의하고 인증에 사용되는 사용자 이름을 다시 작성하기 위한 교체 방법을 정의합니다.

다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

패턴

정규 표현식 패턴.

교체

를 대체하여 인증에 사용되는 사용자 이름을 다시 작성합니다.

sasl-mechanism-selector

이 요소는 org.wildfly.security.sasl.SaslMechanismSelector.fromString(문자열) 메서드의 구문을 사용하여 SASL 메커니즘 선택기를 지정합니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

선택기

SASL 메커니즘 선택기.

the sasl-mechanism-selector 에 필요한 교체에 대한 자세한 내용은 How to Configure Server Security for JBoss EAP 에서 참조하십시오.

set-mechanism-properties
이 요소에는 인증 메커니즘에 전달할 하나 이상의 속성 요소가 포함될 수 있습니다.
property

이 요소는 인증 메커니즘에 전달할 속성을 정의합니다.

다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

key

속성 이름입니다.

value

속성 값입니다.

인증 정보

이 요소는 인증 중에 사용할 수 있는 하나 이상의 자격 증명을 정의합니다.

인증 정보 저장소 구현에 따라 하나 이상의 다음 하위 요소를 포함할 수 있습니다.

이러한 요소는 protection-parameter-credentials 요소에 포함된 항목과 동일한 하위 요소입니다. 자세한 내용 및 구성 예는 protection-parameter-credentials 요소를 참조하십시오.

set-authorization-name

이 요소는 인증 ID와 다른 경우 권한 부여에 사용해야 하는 이름을 지정합니다.

다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

name

권한 부여에 사용해야 하는 이름입니다.

use-provider-sasl-factory
이 요소는 이 구성에서 상속되거나 정의되었으며 사용 가능한 SASL 클라이언트 팩토리를 찾는 데 사용되는 java.security.Provider 인스턴스를 지정합니다. 이 요소는 use-service-loader-sasl-factory 요소와 함께 사용하면 안 됩니다.
use-service-loader-sasl-factory

이 요소는 서비스 로더 검색 메커니즘을 사용하여 SASL 클라이언트 팩토리를 검색하는 데 사용되는 모듈을 지정합니다. 모듈을 지정하지 않으면 구성을 로드한 클래스 로더가 사용됩니다. 이 요소는 use-provider-sasl-factory 요소와 함께 사용하면 안 됩니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

module-name

모듈의 이름입니다.

net-authenticator

이 요소에는 구성이 없습니다. 있는 경우 org.wildfly.security.auth.util.ElytronAuthenticatorjava.net.Authenticator.setDefault(Authenticator)에 등록됩니다. 이를 통해 인증이 필요한 HTTP 호출에 JDK API를 사용할 때 Elytron 인증 클라이언트 구성을 인증에 사용할 수 있습니다.

참고

JDK는 JVM에서 첫 번째 호출 시 인증을 캐시하므로 동일한 URI에 대한 다른 호출에 다른 자격 증명이 필요하지 않은 독립 실행형 프로세스에서만 이 방법을 사용하는 것이 좋습니다.

ssl-context-rules

이 선택적 요소는 SSL 컨텍스트 규칙을 정의합니다. ssl-context 가 필요한 경우 액세스한 리소스의 URI와 선택적 추상 유형 및 추상 유형 권한이 구성에 정의된 규칙과 일치하여 사용해야 하는 ssl-context 를 식별합니다.

이 요소에는 하나 이상의 하위 규칙 요소가 포함될 수 있습니다.

예: ssl-context-rules 구성

<configuration>
  <authentication-client xmlns="urn:elytron:client:1.2">
    <ssl-context-rules>
      <rule use-ssl-context="...">
        ...
      </rule>
    </ssl-context-rules>
    ...
  </authentication-client>
</configuration>
Copy to Clipboard Toggle word wrap

규칙

이 요소는 SSL 컨텍스트 정의와 일치하는 규칙을 정의합니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

use-ssl-context

규칙이 일치할 때 선택하는 SSL 컨텍스트 정의입니다.

SSL 컨텍스트 규칙 일치는 인증 규칙 일치와 독립적입니다. SSL 컨텍스트 규칙 구조는 SSL 컨텍스트를 참조하는 반면 인증 규칙은 인증 구성을 참조한다는 점을 제외하고는 인증 구성 규칙 구조와 동일합니다.

다음 하위 요소를 포함할 수 있습니다.

예: SSL 컨텍스트에 대한 규칙 구성

<rule use-ssl-context="...">
  <!-- At most one of the following two can be defined. -->
  <match-no-user />
  <match-user name="..." />
  <!-- Each of the following can be defined at most once. -->
  <match-protocol name="..." />
  <match-host name="..." />
  <match-path name="..." />
  <match-port number="..." />
  <match-urn name="..." />
  <match-domain name="..." />
  <match-abstract-type name="..." authority="..." />
</rule>
Copy to Clipboard Toggle word wrap

ssl-contexts

이 선택적 요소는 SSL 컨텍스트 규칙에 의해 선택할 SSL 컨텍스트 정의를 정의합니다.

예: ssl-contexts 구성

<configuration>
  <authentication-client xmlns="urn:elytron:client:1.2">
    <ssl-contexts>
      <default-ssl-context name="..."/>
      <ssl-context name="...">
        <key-store-ssl-certificate>...</key-store-ssl-certificate>
        <trust-store key-store-name="..." />
        <cipher-suite selector="..." />
        <protocol names="... ..." />
        <provider-name name="..." />
        <providers>...</providers>
        <certificate-revocation-list path="..." maximum-cert-path="..." />
      </ssl-context>
    </ssl-contexts>
  </authentication-client>
</configuration>
Copy to Clipboard Toggle word wrap

default-ssl-context
이 요소는 javax.net.ssl.SSLContext.getDefault() 에서 반환한 SSL Context를 가져와 ssl-context-rules 에서 참조할 수 있도록 이름을 할당합니다. 이 요소는 반복할 수 있습니다. 즉, 다른 이름을 사용하여 기본 SSL 컨텍스트를 참조할 수 있습니다.
ssl-context

이 요소는 연결에 사용할 SSL 컨텍스트를 정의합니다.

선택적으로 다음 하위 요소 중 하나를 포함할 수 있습니다.

key-store-ssl-certificate

이 요소는 이 SSL 컨텍스트에 사용할 키 저장소 내의 항목에 대한 참조를 정의합니다.

다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

key-store-name

키 저장소 이름입니다. 이 속성은 필수입니다.

alias

참조된 키 저장소에서 로드할 항목의 별칭입니다. 이는 단일 항목만 포함하는 키 저장소에만 대해 생략할 수 있습니다.

다음과 같은 하위 요소를 포함할 수 있습니다.

이 구조는 키 저장소-자격 증명 구성에 사용되는 구조와 거의 동일합니다. 여기서 키 및 인증서에 대한 항목을 가져옵니다. 그러나 중첩된 key-store-clean-passwordkey-store-credential 요소는 여전히 항목을 잠금 해제하기 위한 보호 매개 변수를 제공합니다.

예: key-store-ssl-certificate 구성

<key-store-ssl-certificate key-store-name="..." alias="...">
  <key-store-clear-password password="..." />
  <key-store-credential>...</key-store-credential>
</key-store-ssl-certificate>
Copy to Clipboard Toggle word wrap

trust-store

이 요소는 TrustManager 를 초기화하는 데 사용되는 키 저장소에 대한 참조입니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

key-store-name

키 저장소 이름입니다. 이 속성은 필수입니다.

cipher-suite

이 요소는 활성화된 암호화 제품군에 대한 필터를 구성합니다.

다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

선택기

암호화 제품군을 필터링하는 선택기입니다. 선택기는 org.wildfly.security.ssl.CipherSuiteSelector.fromString(selector) 메서드로 생성된 OpenSSL 스타일 암호 목록 문자열의 형식을 사용합니다.

예: 기본 필터링을 사용하는 암호화-강의 구성

<cipher-suite selector="DEFAULT" />
Copy to Clipboard Toggle word wrap

protocol
이 요소는 지원할 프로토콜의 공백으로 구분된 목록을 정의합니다. 사용 가능한 프로토콜 목록은 How to Configure Server Security for JBoss EAP에서 client-ssl-context 속성 테이블을 참조하십시오. TLSv1.2 를 사용하는 것이 좋습니다.
provider-name
사용 가능한 공급업체가 식별되면 이 요소에 정의된 이름이 있는 공급자만 사용됩니다.
certificate-revocation-list

이 요소는 인증서 폐기 목록의 경로와 인증 경로에 존재할 수 있는 자체 발급되지 않은 최대 중간 인증서 수를 모두 정의합니다. 이 요소가 있으면 인증서 폐기 목록에 대해 피어의 인증서를 확인할 수 있습니다.

다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

경로

자격증 목록의 경로. 이 속성은 선택 사항입니다.

maximum-cert-path

인증 경로에 존재할 수 있는 자체 발급되지 않은 최대 중간 인증서 수입니다. 이 속성은 선택 사항입니다.

공급자

이 요소는 필요한 경우 java.security.Provider 인스턴스가 있는 방법을 정의합니다.

다음 하위 요소를 포함할 수 있습니다.

authentication-client 의 구성 섹션은 서로 독립적이므로 다음 위치에서 이 요소를 구성할 수 있습니다.

예제: 공급자 구성의 위치

<configuration>
  <authentication-client xmlns="urn:elytron:client:1.2">
    <providers />
    ...
    <credential-stores>
      <credential-store name="...">
        ...
        <providers />
      </credential-store>
    </credential-stores>
    ...
    <authentication-configurations>
      <authentication-configuration name="...">
        ...
        <providers />
      </authentication-configuration>
    </authentication-configurations>
    ...
    <ssl-contexts>
      <ssl-context name="...">
        ...
        <providers />
      </ssl-context>
    </ssl-contexts>
  </authentication-client>
</configuration>
Copy to Clipboard Toggle word wrap

프로바이더 구성은 재정의되지 않는 한 정의된 요소와 하위 요소에 모두 적용됩니다. 하위 요소의 공급자 사양은 상위 요소에 지정된 프로바이더 를 재정의합니다. 공급자 구성이 지정되지 않은 경우 기본 동작은 다음과 같습니다. 이는 전 세계에 등록된 공급자에 대해 Elytron 공급자 우선 순위를 부여하지만 세계적으로 등록된 공급자를 사용할 수도 있습니다.

예: 공급자 구성

<providers>
  <use-service-loader />
  <global />
</providers>
Copy to Clipboard Toggle word wrap

global
이 빈 요소는 java.security.Security.getProviders() 메서드 호출로 로드된 글로벌 공급자를 사용하도록 지정합니다.
use-service-loader
이 빈 요소는 지정된 모듈에 의해 로드되는 공급자를 사용하도록 지정합니다. 모듈을 지정하지 않으면 인증 클라이언트를 로드한 클래스 로더가 사용됩니다.
중요

모든 JBoss EAP 인증 메커니즘에서 현재 사용되지 않는 요소

현재 Elytron 클라이언트 구성의 자격 증명 요소의 하위 요소는 JBoss EAP의 인증 메커니즘에서 사용되지 않습니다. 인증 메커니즘의 사용자 지정 구현에서 사용할 수 있지만 이러한 메커니즘은 지원되지 않습니다.

  1. key-pair
  2. public-key-pem
  3. key-store-reference
  4. certificate

urn:jboss:wildfly -client-ejb:3.0 네임스페이스에 있는 jboss -ejb-client 요소를 사용하여 wildfly- config.xml 파일을 사용하여 Jakarta Enterprise Beans 클라이언트 연결, 글로벌 인터셉터 및 호출 시간 초과를 구성할 수 있습니다. 이 섹션에서는 이 요소를 사용하여 Jakarta Enterprise Beans 클라이언트를 구성하는 방법에 대해 설명합니다.

jboss-ejb-client 요소 및 속성

jboss-ejb-client 요소에는 다음 세 가지 최상위 하위 요소를 하위 요소와 함께 선택적으로 포함할 수 있습니다.

invocation-timeout

이 선택적 요소는 Jakarta Enterprise Beans 호출 시간 초과를 지정합니다. 다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

Jakarta Enterprise Beans 핸드셰이크 또는 메서드 호출 요청/응답 주기의 시간 제한(초)입니다. 이 속성은 필수입니다.

메서드 실행이 시간 초과 기간보다 오래 걸리는 경우 호출에서 java.util.concurrent.TimeoutException 이 발생하지만 서버 측은 중단되지 않습니다.

global-interceptors
이 선택적 요소는 글로벌 Jakarta Enterprise Beans 클라이언트 인터셉터를 지정합니다. 임의의 수의 인터셉터 요소를 포함할 수 있습니다.
interceptor

이 요소는 Jakarta Enterprise Beans 클라이언트 인터셉터를 지정하는 데 사용됩니다. 다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

클래스

org.jboss.ejb.client.EJBClientInterceptor 인터페이스를 구현하는 클래스의 이름입니다. 이 속성은 필수입니다.

module

인터셉터 클래스를 로드하는 데 사용해야 하는 모듈의 이름입니다. 이 속성은 선택 사항입니다.

연결
이 요소는 Jakarta Enterprise Beans 클라이언트 연결을 지정하는 데 사용됩니다. 원하는 수의 연결 요소를 포함할 수 있습니다.
연결

이 요소는 Jakarta Enterprise Beans 클라이언트 연결을 지정하는 데 사용됩니다. 선택적으로 인터셉터 요소를 포함할 수 있습니다. 다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

uri

연결의 대상 URI입니다. 이 속성은 필수입니다.

인터셉터
이 요소는 Jakarta Enterprise Beans 클라이언트 인터셉터를 지정하는 데 사용되며 많은 인터셉터 요소를 포함할 수 있습니다.
예: the wildfly-config.xml 파일의 Jakarta Enterprise Beans 클라이언트 구성

다음은 the wildfly-config.xml 파일에서 jboss-ejb-client 요소를 사용하여 Jakarta Enterprise Beans 클라이언트 연결, 글로벌 인터셉터 및 호출 타임아웃을 구성하는 예제입니다.

<configuration>
...
    <jboss-ejb-client xmlns="urn:jboss:wildfly-client-ejb:3.0">
        <invocation-timeout seconds="10"/>
        <connections>
            <connection uri="remote+http://10.20.30.40:8080"/>
        </connections>
        <global-interceptors>
            <interceptor class="org.jboss.example.ExampleInterceptor"/>
        </global-interceptors>
    </jboss-ejb-client>
...
</configuration>
Copy to Clipboard Toggle word wrap

19.1.3. wildfly-config.xml 파일을 사용한 HTTP 클라이언트 구성

다음은 the wildfly-config.xml 파일을 사용하여 HTTP 클라이언트를 구성하는 방법의 예입니다.

<configuration>
...
    <http-client xmlns="urn:wildfly-http-client:1.0">
        <defaults>
            <eagerly-acquire-session value="true" />
            <buffer-pool buffer-size="2000" max-size="10" direct="true" thread-local-size="1" />
        </defaults>
    </http-client>
...
</configuration>
Copy to Clipboard Toggle word wrap
중요

the wildfly-config.xml 파일을 사용하는 HTTP 클라이언트 구성은 기술 프리뷰로만 제공됩니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.

19.1.4. wildfly-config.xml 파일을 사용하여 클라이언트 설정 원격

urn:jboss-remoting:5.0 네임스페이스에 있는 endpoint 요소를 사용하여 the wildfly- config.xml 파일을 사용하여 클라이언트 리모팅을 구성할 수 있습니다. 이 섹션에서는 이 요소를 사용하여 원격 클라이언트를 구성하는 방법에 대해 설명합니다.

끝점 요소 및 속성

엔드포인트 요소는 선택적으로 다음 두 개의 최상위 하위 요소를 하위 요소와 함께 포함할 수 있습니다.

또한 다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

name

엔드포인트 이름입니다. 이 속성은 선택 사항입니다. 제공하지 않으면 가능한 경우 시스템의 호스트 이름에서 엔드포인트 이름을 파생합니다.

공급자
이 선택적 요소는 원격 엔드포인트에 대한 전송 프로바이더를 지정합니다. 원하는 수의 공급자 요소를 포함할 수 있습니다.
provider

이 요소는 원격 전송 공급자를 정의합니다. 다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

스키마

이 공급자에 해당하는 기본 URI 스키마입니다. 이 속성은 필수입니다.

aliases

이 공급자에게도 인식되는 다른 URI 체계 이름의 공백으로 구분된 목록입니다. 이 속성은 선택 사항입니다.

module

프로바이더 구현이 포함된 모듈의 이름입니다. 이 속성은 선택 사항입니다. 제공하지 않는 경우 JBoss Remoting을 로드하는 클래스 로더는 공급자 클래스를 검색합니다.

클래스

전송 프로바이더를 구현하는 클래스의 이름입니다. 이 속성은 선택 사항입니다. 제공되지 않는 경우 java.util.ServiceLoader 기능은 공급자 클래스를 검색하는 데 사용됩니다.

연결
이 선택적 요소는 원격 엔드포인트에 대한 연결을 지정합니다. 원하는 수의 연결 요소를 포함할 수 있습니다.
연결

이 요소는 원격 엔드포인트에 대한 연결을 정의합니다. 다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

대상

엔드포인트의 대상 URI입니다. 이 속성은 필수입니다.

read-timeout

해당 소켓에 대한 읽기 작업에 대한 시간 제한(초)입니다. 이 특성은 선택 사항이지만 heartbeat-interval 이 정의된 경우에만 제공해야 합니다.

write-timeout

쓰기 작업에 대한 시간 제한(초)입니다. 이 특성은 선택 사항이지만 heartbeat-interval 이 정의된 경우에만 제공해야 합니다.

ip-traffic-class

이 연결의 트래픽에 사용할 숫자 IP 트래픽 클래스를 정의합니다. 이 속성은 선택 사항입니다.

tcp-keepalive

TCP keepalive 사용 여부를 결정하는 부울 설정입니다. 이 속성은 선택 사항입니다.

heartbeat-interval

연결 하트비트를 확인할 때 사용할 간격(밀리초)입니다. 이 속성은 선택 사항입니다.

the wildfly-config.xml 파일에서 클라이언트 구성 원격화의 예

다음은 the wildfly-config.xml 파일을 사용하여 원격 클라이언트를 구성하는 예입니다.

<configuration>
  ...
  <endpoint xmlns="urn:jboss-remoting:5.0">
    <connections>
      <connection destination="remote+http://10.20.30.40:8080" read-timeout="50" write-timeout="50" heartbeat-interval="10000"/>
    </connections>
  </endpoint>
  ...
</configuration>
Copy to Clipboard Toggle word wrap

19.1.5. wildfly-config.xml 파일을 사용한 기본 XNIO 작업자 구성

urn:xnio:3.5 네임스페이스에 있는 worker 요소를 사용하여 the wildfly-config.xml 파일을 사용하여 XNIO 작업자를 구성할 수 있습니다. 이 섹션에서는 이 요소를 사용하여 XNIO 작업자 클라이언트를 구성하는 방법에 대해 설명합니다.

작업자 요소 및 속성

worker 요소는 선택적으로 하위 요소와 함께 다음 최상위 하위 요소를 포함할 수 있습니다.

daemon-threads

이 선택적 요소는 작업자 및 작업 스레드가 데몬 스레드인지 여부를 지정합니다. 이 요소에는 콘텐츠가 없습니다. 다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

value

작업자 및 작업 스레드가 데몬 스레드인지 여부를 지정하는 부울 값입니다. true 값은 작업자 및 작업 스레드가 데몬 스레드여야 함을 나타냅니다. false 값은 데몬 스레드가 될 수 없음을 나타냅니다. 이 속성은 필수입니다.

이 요소가 제공되지 않으면 값이 true 라고 가정합니다.

worker-name

이 요소는 작업자의 이름을 정의합니다. 작업자 이름은 스레드 덤프 및 자카르타 관리에 표시됩니다. 이 요소에는 콘텐츠가 없습니다. 다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

value

작업자의 이름입니다. 이 속성은 필수입니다.

pool-size

이 선택적 요소는 작업자의 작업 스레드 풀의 최대 크기를 정의합니다. 이 요소에는 콘텐츠가 없습니다. 다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

max-threads

생성해야 하는 최대 스레드 수를 지정하는 양의 정수입니다. 이 속성은 필수입니다.

task-keepalive

이 선택적 요소는 작업 스레드가 만료되기 전에 유지 시간을 설정합니다. 다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

value

유휴 스레드를 활성 상태로 유지하기 위해 최소 시간(초)을 지정하는 양의 정수입니다. 이 속성은 필수입니다.

io-threads

이 선택적 요소는 유지 관리해야 하는 I/O 선택기 스레드 수를 결정합니다. 일반적으로 이 숫자는 사용 가능한 코어 수의 배수인 소수의 상수여야 합니다. 다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

value

I/O 스레드 수를 지정하는 양의 정수입니다. 이 속성은 필수입니다.

stack-size

이 선택적 요소는 작업자 스레드에 대해 원하는 최소 스레드 스택 크기를 설정합니다. 이 요소는 밀도가 프리미엄인 매우 특별한 상황에서만 정의해야 합니다. 다음과 같은 속성이 있습니다.

Expand
특성 이름특성 설명

value

요청된 스택 크기를 바이트로 지정하는 양의 정수입니다. 이 속성은 필수입니다.

outbound-bind-addresses
이 선택적 요소는 아웃바운드 연결에 사용할 바인드 주소를 지정합니다. 각 바인딩 주소 매핑은 대상 IP 주소 블록과 해당 블록 내의 대상 연결에 사용할 바인드 주소 및 선택적 포트 번호로 구성됩니다. 다수의 bind-address 요소를 포함할 수 있습니다.
bind-address

이 선택적 요소는 개별 바인드 주소 매핑을 정의합니다. 다음과 같은 특성이 있습니다.

Expand
특성 이름특성 설명

일치

일치하는 CIDR 표기법의 IP 주소 블록입니다.

bind-address

address 블록이 일치하는 경우 바인딩할 IP 주소입니다. 이 속성은 필수입니다.

bind-port

주소 블록이 일치하는 경우 에 바인딩할 포트 번호입니다. 이 값은 0 으로 지정되므로 모든 포트에 바인딩됩니다. 이 속성은 선택 사항입니다.

the wildfly-config.xml 파일의 XNIO 작업자 구성 예

다음은 the wildfly-config.xml 파일을 사용하여 기본 XNIO 작업자를 구성하는 방법의 예입니다.

<configuration>
  ...
  <worker xmlns="urn:xnio:3.5">
    <io-threads value="10"/>
    <task-keepalive value="100"/>
  </worker>
  ...
</configuration>
Copy to Clipboard Toggle word wrap

부록 A. 참고 자료

A.1. Undertow 핸들러 제공

참고

핸들러의 전체 목록을 보려면 JBoss EAP 설치의 Undertow 코어와 일치하는 버전에서 Undertow 코어의 소스 JAR 파일을 확인해야 합니다. JBoss EAP Maven 리포지토리에서 Undertow 핵심 소스 JAR 파일을 다운로드한 다음 /io/undertow/server/handlers/ 디렉터리에서 사용 가능한 핸들러를 참조할 수 있습니다.

아래 예제와 유사하게 server.log 파일에서 JBoss EAP 서버 시작 중에 출력되는 INFO 메시지를 검색하여 JBoss EAP의 현재 설치에 사용된 Undertow 코어 버전을 확인할 수 있습니다.

INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.18.Final-redhat-1 starting
Copy to Clipboard Toggle word wrap
AccessControlListHandler

클래스 이름: io.undertow.server.handlers.AccessControlListHandler

이름: access-control

원격 피어의 특성에 따라 요청을 수락하거나 거부할 수 있는 핸들러.

Expand
표 A.1. 매개 변수
이름설명

ACL

ACL 규칙. 이 매개 변수는 필수입니다.

attribute

교환 특성 문자열. 이 매개 변수는 필수입니다.

default-allow

핸들러가 기본적으로 요청을 수락하거나 거부할지 여부를 지정하는 부울입니다. 기본값은 false입니다.

AccessLogHandler

클래스 이름: io.undertow.server.handlers.accesslog.AccessLogHandler

이름: access-log

로그 핸들러 액세스. 이 핸들러는 제공된 형식 문자열을 기반으로 액세스 로그 메시지를 생성하고 제공된 AccessLogReceiver 에 이러한 메시지를 전달합니다.

이 핸들러는 ExchangeAttribute 메커니즘을 통해 제공된 모든 특성을 로깅할 수 있습니다.

이 팩토리는 다음 패턴에 대한 토큰 핸들러를 생성합니다.

Expand
표 A.2. 패턴
패턴설명

%a

원격 IP 주소

%A

로컬 IP 주소

%b

HTTP 헤더를 제외하고 전송된 바이트 또는 바이트가 없는 경우 -

%B

HTTP 헤더를 제외하고 전송된 바이트

%h

원격 호스트 이름

%H

요청 프로토콜

%l

원격 논리 사용자 이름 from identd (항상 반환 -)

%m

요청 방법

%p

로컬 포트

%q

쿼리 문자열 ( ? 문자 제외)

%r

요청의 첫 번째 행

%s

응답의 HTTP 상태 코드

%t

날짜 및 시간(일반 로그 형식)

%u

인증된 원격 사용자

%U

요청된 URL 경로

%v

로컬 서버 이름

%D

요청을 처리하는 데 걸린 시간(밀리초)

%T

요청을 처리하는 데 걸리는 시간(초)

%I

현재 요청 스레드 이름 (나중에 스택 추적과 비교할 수 있음)

Common

%H %l %u %t "%r" %s %b

결합

%H %l %u %t "%r" %s %b "%{i,Referer}" "%{i,User-Agent}"

쿠키, 수신 헤더 또는 세션에서 정보를 작성할 수도 있습니다.

Apache 구문 다음에 모델링됩니다.

  • 수신 헤더의 %{I,xxx}
  • 나가는 응답 헤더의 %{O,xxx}
  • 특정 쿠키를 위한 %{C,xxx}
  • %{R,xxx} 여기서 xxxServletRequest의 속성입니다.
  • %{s,xxx} 여기서 xxxHttpSession의 속성입니다.
Expand
표 A.3. 매개 변수
이름설명

포맷

로그 메시지를 생성하는 데 사용되는 형식입니다. 기본 매개변수 입니다.

AllowedMethodsHandler

특정 HTTP 메서드를 허용 목록에 추가하는 핸들러입니다. 허용된 메서드 집합에 메서드가 있는 요청만 계속할 수 있습니다.

클래스 이름: io.undertow.server.handlers.AllowedMethodsHandler

이름: allowed-methods

Expand
표 A.4. 매개 변수
이름설명

방법

GET,POST,PUT 등과 같이 허용하는 메서드입니다. 기본 매개변수 입니다.

BlockingHandler

차단 요청을 시작하는 HttpHandler입니다. 스레드가 현재 I/O 스레드에서 실행 중인 경우 디스패치됩니다.

클래스 이름: io.undertow.server.handlers.BlockingHandler

이름: 차단

이 핸들러에는 매개 변수가 없습니다.

ByteRangeHandler

범위 요청에 대한 핸들러입니다. 이는 고정된 콘텐츠 길이의 모든 리소스에 대한 범위 요청을 처리할 수 있는 일반 핸들러입니다(예: content-length 헤더가 설정된 모든 리소스). 전체 콘텐츠가 생성되고 삭제되므로 이 방법이 범위 요청을 처리하는 가장 효율적인 방법은 아닙니다. 현재 이 핸들러는 단순한 단일 범위 요청만 처리할 수 있습니다. 여러 범위가 요청되면 Range 헤더가 무시됩니다.

클래스 이름: io.undertow.server.handlers.ByteRangeHandler

이름: byte-range

Expand
표 A.5. 매개 변수
이름설명

send-accept-ranges

허용 범위를 보낼지 여부에 대한 부울 값입니다. 기본 매개변수 입니다.

CanonicalPathHandler

이 핸들러는 정식 경로에 대한 상대 경로를 변환합니다.

클래스 이름: io.undertow.server.handlers.CanonicalPathHandler

이름: Canonical-path

이 핸들러에는 매개 변수가 없습니다.

DisableCacheHandler

브라우저 및 프록시의 응답 캐싱을 비활성화하는 핸들러.

클래스 이름: io.undertow.server.handlers.DisableCacheHandler

이름: disable-cache

이 핸들러에는 매개 변수가 없습니다.

DisallowedMethodsHandler

특정 HTTP 메서드를 블랙리스트로 지정하는 핸들러입니다.

클래스 이름: io.undertow.server.handlers.DisallowedMethodsHandler

이름: disallowed-methods

Expand
표 A.6. 매개 변수
이름설명

방법

GET,POST,PUT 등과 같이 허용하지 않는 메서드입니다. 기본 매개변수 입니다.

EncodingHandler

이 핸들러는 콘텐츠 인코딩 구현의 기초 역할을 합니다. 인코딩 핸들러는 지정된 서버 측 우선 순위와 함께 이 핸들러에 위임으로 추가됩니다.

q 값은 올바른 핸들러를 결정하는 데 사용됩니다. q 값이 없는 요청이 도착하면 서버에서 사용할 인코딩으로 우선 순위가 가장 높은 핸들러를 선택합니다.

일치하는 핸들러가 없으면 ID 인코딩이라고 가정합니다. q 값이 0 으로 인해 ID 인코딩이 구체적으로 허용되지 않은 경우 핸들러는 응답 코드 406(수용되지 않음) 을 설정하고 반환합니다.

클래스 이름: io.undertow.server.handlers.encoding.EncodingHandler

이름: 압축

이 핸들러에는 매개 변수가 없습니다.

FileErrorPageHandler

오류 페이지 역할을 하기 위해 디스크에서 파일을 제공하는 핸들러입니다. 이 핸들러는 기본적으로 응답하는 응답 코드를 구성하지 않으므로 응답하는 응답 코드를 구성해야 합니다.

클래스 이름: io.undertow.server.handlers.error.FileErrorPageHandler

이름: error-file

Expand
표 A.7. 매개 변수
이름설명

file

오류 페이지로 사용할 파일의 위치.

response-codes

정의된 오류 페이지 파일로 리디렉션되는 응답 코드 목록입니다.

HttpTraceHandler

HTTP 추적 요청을 처리하는 핸들러입니다.

클래스 이름: io.undertow.server.handlers.HttpTraceHandler

이름: trace

이 핸들러에는 매개 변수가 없습니다.

IPAddressAccessControlHandler

원격 피어의 IP 주소를 기반으로 요청을 수락하거나 거부할 수 있는 핸들러입니다.

클래스 이름: io.undertow.server.handlers.IPAddressAccessControlHandler

이름: ip-access-control

Expand
표 A.8. 매개 변수
이름설명

ACL

액세스 제어 목록을 나타내는 문자열입니다. 기본 매개변수 입니다.

failure-status

거부된 요청에 반환할 상태 코드를 나타내는 정수입니다.

default-allow

부울은 기본적으로 허용 여부를 나타냅니다.

JDBCLogHandler

클래스 이름: io.undertow.server.handlers.JDBCLogHandler

이름: jdbc-access-log

Expand
표 A.9. 매개 변수
이름설명

포맷

JDBC 로그 패턴을 지정합니다. 기본값은 common 입니다. 또한 combined 를 사용하여 VirtualHost, 요청 메서드, referrer 및 사용자 에이전트 정보를 로그 메시지에 추가할 수 있습니다.

데이터 소스

로깅할 데이터 소스의 이름입니다. 이 매개 변수는 필수이며 기본 매개변수 입니다.

tableName

테이블 이름.

remoteHostField

원격 호스트 주소.

userField

사용자 이름.

timestampField

타임스탬프.

virtualHostField

VirtualHost.

methodField

메서드.

queryField

쿼리.

statusField

상태.

bytesField

바이트.

refererField

참조자.

userAgentField

userAgent.

LearningPushHandler

브라우저에서 요청하는 리소스 캐시를 빌드하고 server push를 사용하여 지원 시 푸시하는 핸들러.

클래스 이름: io.undertow.server.handlers.LearningPushHandler

이름: learning-push

Expand
표 A.10. 매개 변수
이름설명

최대 크기

캐시 항목의 최대 시간을 나타내는 정수입니다.

max-entries

최대 캐시 항목 수를 나타내는 정수

LocalNameResolvingHandler

로컬 주소를 확인하기 위해 DNS 조회를 수행하는 핸들러입니다. 프론트엔드 서버에서 X-forwarded-host 헤더 또는 AJP가 사용 중인 경우 확인되지 않은 로컬 주소를 만들 수 있습니다.

클래스 이름: io.undertow.server.handlers.LocalNameResolvingHandler

이름: resolve-local-name

이 핸들러에는 매개 변수가 없습니다.

PathSeparatorHandler

URL의 슬래시 구분 기호가 아닌 문자를 슬래시로 변환하는 핸들러입니다. 일반적으로 Windows 시스템에서 역슬래시를 슬래시로 변환합니다.

클래스 이름: io.undertow.server.handlers.PathSeparatorHandler

이름: path-separator

이 핸들러에는 매개 변수가 없습니다.

PeerNameResolvingHandler

역방향 DNS 조회를 수행하여 피어 주소를 확인하는 핸들러입니다.

클래스 이름: io.undertow.server.handlers.PeerNameResolvingHandler

이름: resolve-peer-name

이 핸들러에는 매개 변수가 없습니다.

ProxyPeerAddressHandler

피어 주소를 X-Forwarded-For 헤더 값으로 설정하는 핸들러입니다. 항상 이 헤더를 설정하는 프록시 뒤에서만 사용해야 합니다. 그렇지 않으면 공격자가 피어 주소를 위조할 수 있습니다.

클래스 이름: io.undertow.server.handlers.ProxyPeerAddressHandler

이름: proxy-peer-address

이 핸들러에는 매개 변수가 없습니다.

RedirectHandler

302 리디렉션을 통해 지정된 위치로 리디렉션되는 리디렉션 핸들러. 위치는 교환 특성 문자열로 지정됩니다.

클래스 이름: io.undertow.server.handlers.RedirectHandler

이름: 리디렉션

Expand
표 A.11. 매개 변수
이름설명

value

리디렉션 대상입니다. 기본 매개변수 입니다.

RequestBufferingHandler

모든 요청 데이터를 버퍼링하는 핸들러.

클래스 이름: io.undertow.server.handlers.RequestBufferingHandler

이름: buffer-request

Expand
표 A.12. 매개 변수
이름설명

버퍼

최대 버퍼 수를 정의하는 정수입니다. 기본 매개변수 입니다.

RequestDumpingHandler

교환을 로그에 덤프하는 핸들러.

클래스 이름: io.undertow.server.handlers.RequestDumpingHandler

이름: dump-request

이 핸들러에는 매개 변수가 없습니다.

RequestLimitingHandler

최대 동시 요청 수를 제한하는 핸들러입니다. 제한 이외의 요청은 이전 요청이 완료될 때까지 차단됩니다.

클래스 이름: io.undertow.server.handlers.RequestLimitingHandler

이름: request-limit

Expand
표 A.13. 매개 변수
이름설명

requests

최대 동시 요청 수를 나타내는 정수입니다. 기본 매개변수 이며 필수입니다.

ResourceHandler

리소스를 제공하는 핸들러입니다.

클래스 이름: io.undertow.server.handlers.resource.ResourceHandler

이름: resource

Expand
표 A.14. 매개 변수
이름설명

위치

리소스 위치. 기본 매개변수 이며 필수입니다.

allow-listing

디렉토리 목록 허용 여부를 결정하는 부울 값입니다.

ResponseRateLimitingHandler

다운로드 속도를 설정된 바이트/시간으로 제한하는 핸들러.

클래스 이름: io.undertow.server.handlers.ResponseRateLimitingHandler

이름: response-rate-limit

Expand
표 A.15. 매개 변수
이름설명

바이트

다운로드 속도를 제한하는 바이트 수입니다. 이 매개 변수는 필수입니다.

time

다운로드 속도를 제한하는 시간(초)입니다. 이 매개 변수는 필수입니다.

SetHeaderHandler

고정 응답 헤더를 설정하는 핸들러입니다.

클래스 이름: io.undertow.server.handlers.SetHeaderHandler

이름: 헤더

Expand
표 A.16. 매개 변수
이름설명

헤더

헤더 속성의 이름입니다. 이 매개 변수는 필수입니다.

value

헤더 속성 값. 이 매개 변수는 필수입니다.

SSLHeaderHandler

다음 헤더를 기반으로 연결에 대한 SSL 정보를 설정하는 핸들러입니다.

  • SSL_CLIENT_CERT
  • SSL_CIPHER
  • SSL_SESSION_ID

이 핸들러가 체인에 있는 경우 이러한 헤더가 없는 경우에도 SSL 세션 정보를 항상 재정의합니다.

이 핸들러는 역방향 프록시 뒤에 있는 서버에서만 사용해야 합니다. 여기서 역방향 프록시는 모든 요청에 대해 이러한 헤더를 항상 설정하거나 SSL 정보가 없는 경우 이러한 이름으로 기존 헤더를 제거하도록 구성되어 있어야 합니다. 그렇지 않으면 악의적인 클라이언트가 SSL 연결을 스푸핑할 수 있습니다.

클래스 이름: io.undertow.server.handlers.SSLHeaderHandler

이름: ssl-headers

이 핸들러에는 매개 변수가 없습니다.

StuckThreadDetectionHandler

이 핸들러는 처리에 시간이 오래 걸리는 요청을 탐지하여 처리 중인 스레드가 정지되었음을 나타낼 수 있습니다.

클래스 이름: io.undertow.server.handlers.StuckThreadDetectionHandler

이름: stuck-thread-detector

Expand
표 A.17. 매개 변수
이름설명

Threshhold

요청을 처리하는 데 걸리는 시간을 결정하는 정수 값(초)입니다. 기본값은 600 (10분)입니다. 기본 매개변수 입니다.

URLDecodingHandler

지정된 문자 집합에 URL 및 쿼리 매개 변수를 디코딩하는 핸들러입니다. 이 핸들러를 사용하는 경우 UndertowOptions.DECODE_URL 매개변수를 false 로 설정해야 합니다.

이 방법은 구문 분석기가 UTF-8 디코더에 빌드된 사용만큼 효율적이지 않습니다. UTF-8 이외의 것으로 디코딩해야 하는 경우가 아니면 구문 분석기를 대신 사용해야 합니다.

클래스 이름: io.undertow.server.handlers.URLDecodingHandler

이름: url-decoding

Expand
표 A.18. 매개 변수
이름설명

charactersset

디코딩할 charactersset. 기본 매개변수 이므로 필수입니다.

A.2. 지속성 유닛 속성

지속성 유닛 정의는 persistence.xml 파일에서 구성할 수 있는 다음 속성을 지원합니다.

Expand
속성설명

jboss.as.jpa.providerModule

지속성 프로바이더 모듈의 이름입니다. 기본값은 org.hibernate 입니다. 지속성 프로바이더가 애플리케이션과 함께 패키지된 경우 애플리케이션 이름이 되어야 합니다.

jboss.as.jpa.adapterModule

JBoss EAP가 지속성 프로바이더와 함께 작업하는 데 도움이 되는 통합 클래스의 이름입니다.

jboss.as.jpa.adapterClass

통합 어댑터의 클래스 이름입니다.

jboss.as.jpa.managed

컨테이너 관리 자카르타 지속성 액세스를 비활성화하려면 false 로 설정합니다. 기본값은 true입니다.

jboss.as.jpa.classtransformer

지속성 유닛의 클래스 변환기를 비활성화하려면 false 로 설정합니다. 기본값은 true 이며 클래스 변환을 허용합니다.

또한 Hibernate는 클래스 변환이 활성화되려면 지속성 유닛 속성 hibernate.ejb.use_class_enhancer 도 필요합니다.

jboss.as.jpa.scopedname

사용할 정규화된 애플리케이션 범위 지속성 유닛 이름을 지정합니다. 기본적으로 이는 애플리케이션 이름 및 지속성 유닛 이름으로 설정됩니다. hibernate.cache.region_prefix 는 기본적으로 jboss.as.jpa.scopedname 을 로 설정합니다. jboss.as.jpa.scopedname 값을 동일한 애플리케이션 서버 인스턴스에 배포된 다른 애플리케이션에서 아직 사용하지 않는 값으로 설정해야 합니다.

jboss.as.jpa.deferdetach

Jakarta가 아닌 트랜잭션 스레드에 사용되는 트랜잭션 범위 지속성 컨텍스트가 각 EntityManager 호출 후 로드된 엔터티를 분리하는지 또는 지속성 컨텍스트가 종료되면 로드된 엔터티를 분리하는지 여부를 제어합니다. 기본값은 false입니다. true 로 설정하면 컨텍스트가 종료될 때까지 분리가 지연됩니다.

wildfly.jpa.default-unit

애플리케이션에서 기본 지속성 유닛을 선택하려면 true 로 설정합니다. 이는 unitName 을 지정하지 않고 지속성 컨텍스트를 주입하지만 persistence .xml 파일에 여러 개의 지속성 유닛을 지정하는 경우 유용합니다.

wildfly.jpa.twophasebootstrap

지속성 프로바이더는 자카르타 컨텍스트 및 종속성 주입과의 자카르타 지속성 통합을 개선하는 2단계 지속성 유닛 부트스트랩을 허용합니다. wildfly.jpa.twophasebootstrap 값을 false 로 설정하면 값이 포함된 지속성 유닛의 2단계 부트스트랩이 비활성화됩니다.

wildfly.jpa.allowdefaultdatasourceuse

지속성 유닛이 기본 데이터 소스를 사용하지 못하도록 하려면 false 로 설정합니다. 기본값은 true입니다. 이는 데이터 소스를 지정하지 않는 지속성 유닛에만 중요합니다.

wildfly.jpa.hibernate.search.module

클래스 경로에 포함할 Hibernate Search 버전을 제어합니다. 기본값은 auto 입니다. 다른 유효한 값은 대체 버전을 사용하기 위한 전체 모듈 식별자 또는 전체 모듈 식별자입니다.

A.3. 정책 공급자 속성

Expand
표 A.19. 정책 제공 속성
속성설명

custom-policy

사용자 지정 정책 프로바이더 정의.

JACC-policy

Jakarta Authorization 및 관련 서비스를 설정하는 정책 공급자 정의입니다.

Expand
표 A.20. custom-policy 속성
속성설명

class-name

정책 프로바이더를 참조하는 java.security.Policy 구현의 이름입니다.

module

프로바이더를 로드할 모듈의 이름입니다.

Expand
표 A.21. JACC-policy 속성
속성설명

policy

정책 프로바이더를 참조하는 java.security.Policy 구현의 이름입니다.

configuration-factory

정책 구성 팩토리 공급자를 참조하는 javax.security.jacc.PolicyConfigurationFactory 구현의 이름입니다.

module

프로바이더를 로드할 모듈의 이름입니다.

A.4. Jakarta EE 프로필 및 기술 참조

다음 표에는 범주별 Jakarta EE 기술이 나열되어 있으며, 이 기술이 Web Profile 또는 Full Platform 프로필에 포함되는지 여부를 확인합니다.

사양은 Jakarta EE Specification 을 참조하십시오.

Expand
표 A.22. Jakarta EE 웹 애플리케이션 기술
기술웹 프로파일전체 플랫폼

자카르타 웹소켓 1.1

자카르타 JSON 바인딩 1.0

자카르타 JSON 처리 1.1

Jakarta Servlet 4.0

Jakarta Server Faces 2.3

Jakarta Expression Language 3.0

자카르타 서버 페이지 2.3

자카르타 표준 태그 라이브러리 1.2 1

1 추가 자카르타 표준 태그 라이브러리 정보:

참고

JBoss EAP의 알려진 보안 위험은 자카르타 표준 태그 라이브러리에서 신뢰할 수 없는 XML 문서의 외부 엔터티 참조를 처리하여 호스트 시스템의 리소스에 액세스할 수 있고 잠재적으로 임의의 코드 실행을 허용합니다.

이를 방지하려면 일반적으로 빈 문자열을 값으로 사용하여 시스템 속성 org.apache.taglibs.standard.xml.accessExternalEntity 를 사용하여 JBoss EAP 서버를 실행해야 합니다. 이 작업은 두 가지 방법으로 수행할 수 있습니다.

  • 시스템 속성 구성 및 서버 재시작.

    org.apache.taglibs.standard.xml.accessExternalEntity
    Copy to Clipboard Toggle word wrap
  • standalone. sh 또는 domain.sh 스크립트의 인수로 -Dorg.apache.taglibs.standard.xml. accessExternalEntity="" 를 전달합니다.
Expand
표 A.23. Jakarta EE Enterprise Application Technologies
기술웹 프로파일전체 플랫폼

자카르타 배치 1.0

 

자카르타 동시성 1.0

 

자카르타 컨텍스트 및 종속성 주입 2.0

자카르타 컨텍스트 및 종속성 주입 1.0

Jakarta Bean Validation 2.0

Jakarta Managed Beans 1.0

Jakarta Enterprise Beans 3.2

 

Jakarta Interceptors 1.2

Jakarta Connectors 1.7

 

Jakarta Persistence 2.2

자카르타 주석 1.3

 

자카르타 메시징 2.0

 

자카르타 트랜잭션 1.2

자카르타 메일 1.6

 

Expand
표 A.24. Jakarta EE 웹 서비스 기술
기술웹 프로파일전체 플랫폼

Jakarta RESTful Web Services 2.1

 

Jakarta Enterprise Web Services 1.3

 

Web Services Metadata for the Java Platform 2.1

 

Jakarta XML RPC 1.1 (선택 사항)

  

Jakarta XML Registries 1.0 (선택 사항)

  
Expand
표 A.25. Jakarta EE 관리 및 보안 기술
기술웹 프로파일전체 플랫폼

자카르타 보안 1.0

자카르타 인증 1.1

자카르타 권한 1.5

 

Jakarta Deployment 1.2 (선택 사항)

 

자카르타 관리 1.1

 

다른 언어에 대한 자카르타 디버깅 지원 1.0

 





2024-02-09에 최종 업데이트된 문서

법적 공지

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat