개발 가이드
Red Hat JBoss Enterprise Application Platform을 위한 Jakarta EE 애플리케이션 개발 지침.
초록
- 로깅
- 원격 JNDI 조회
- 웹 애플리케이션의 클러스터링
- Jakarta 컨텍스트 및 종속성
- Jakarta EE APIs, such as Jakarta 트랜잭션 and 자카르타 지속성
JBoss EAP 문서에 대한 피드백 제공 링크 복사링크가 클립보드에 복사되었습니다!
오류를 보고하거나 문서를 개선하기 위해 Red Hat Jira 계정에 로그인하여 문제를 제출하십시오. Red Hat Jira 계정이 없는 경우 계정을 생성하라는 메시지가 표시됩니다.
절차
- 티켓을 생성하려면 다음 링크를 클릭하십시오.
- 문서 URL, 섹션 번호 를 포함하고 문제를 설명하십시오.
- 요약 에 문제에 대한 간략한 설명을 입력합니다.
- 설명에서 문제 또는 개선 사항에 대한 자세한 설명을 제공합니다. 문서에서 문제가 발생한 위치에 URL을 포함합니다.
- 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. 개발 환경 설정 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat CodeReady Studio 다운로드 및 설치.
자세한 내용은 Red Hat CodeReady Studio 설치 가이드에서 Installer를 사용하여 CodeReady Studio 독립 실행형 설치 가이드를 참조하십시오.
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 파일에 .activationjdt_apt 값이 있는 m2e. apt
<properties>
<m2e.apt.activation>jdt_apt</m2e.apt.activation>
</properties>
<properties>
<m2e.apt.activation>jdt_apt</m2e.apt.activation>
</properties>
이 기술의 예는 JBoss EAP와 함께 제공되는 용 logging-tools 및 equipmentsink- 빠른 시작pom.xml 파일에서 확인할 수 있습니다.
Red Hat CodeReady Studio에서 전 세계에 주석 처리 활성화
- 창 → 기본 설정을 선택합니다.
- Maven 을 확장하고 Annotation Processing (주석 처리)를 선택합니다.
- Select Annotation Processing Mode (주석 처리 모드 선택) 에서 Automatically configure JDT APT(JDT APT 자동 구성)를 선택합니다(빌드 속도가 더 빠르지만 Maven 빌드와 다를 수 있음)를 선택한 다음 Apply(적용) 및 Close (닫기)를 클릭합니다.
1.4. 기본 시작 웹 애플리케이션 설정 링크 복사링크가 클립보드에 복사되었습니다!
JBoss EAP에는 기본적으로 포트 8080 의 루트 컨텍스트에 표시되는 기본 Welcome 애플리케이션이 포함되어 있습니다.
이 기본 Welcome 애플리케이션은 자체 웹 애플리케이션으로 교체할 수 있습니다. 다음 두 가지 방법 중 하나로 구성할 수 있습니다.
welcome-content 파일 핸들러 변경
기존
welcome-content파일 핸들러의 경로를 새 배포를 가리키도록 수정합니다./subsystem=undertow/configuration=handler/file=welcome-content:write-attribute(name=path,value="/path/to/content")
/subsystem=undertow/configuration=handler/file=welcome-content:write-attribute(name=path,value="/path/to/content")Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고또는 서버의 루트에서 사용할 다른 파일 핸들러를 생성할 수도 있습니다.
/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)
/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 Copied! Toggle word wrap Toggle overflow 변경 사항을 적용하려면 서버를 다시 로드합니다.
reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
default-web-module 변경
배포된 웹 애플리케이션을 서버의 루트에 매핑합니다.
/subsystem=undertow/server=default-server/host=default-host:write-attribute(name=default-web-module,value=hello.war)
/subsystem=undertow/server=default-server/host=default-host:write-attribute(name=default-web-module,value=hello.war)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 변경 사항을 적용하려면 서버를 다시 로드합니다.
reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
기본 시작 웹 애플리케이션 비활성화
default-host의위치항목/를 제거하여 시작 애플리케이션을 비활성화합니다./subsystem=undertow/server=default-server/host=default-host/location=\/:remove
/subsystem=undertow/server=default-server/host=default-host/location=\/:removeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 변경 사항을 적용하려면 서버를 다시 로드합니다.
reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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 파일은 다음과 같을 수 있습니다.
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 설정 파일
settings.xml 파일의 스키마는 http://maven.apache.org/xsd/settings-1.0.0.xsd 에서 찾을 수 있습니다.
2.1.4. Maven 리포지토리 관리자 정보 링크 복사링크가 클립보드에 복사되었습니다!
리포지토리 관리자는 Maven 리포지토리를 쉽게 관리할 수 있는 툴입니다. 리포지토리 관리자는 다음과 같은 여러 가지 방법으로 유용합니다.
- 조직과 원격 Maven 리포지토리 간에 프록시를 구성할 수 있는 기능을 제공합니다. 이는 더욱 빠르고 효율적인 배포를 비롯하여 Maven에서 다운로드한 항목에 대한 보다 나은 제어 수준을 비롯하여 여러 가지 이점을 제공합니다.
- 자체 생성된 아티팩트를 위한 배포 대상을 제공하여 조직 간 다양한 개발 팀 간의 협업이 가능합니다.
Maven 리포지토리 관리자에게 대한 자세한 내용은 모범 사례 - 리포지토리 관리자 사용을 참조하십시오.
일반적으로 사용되는 Maven 리포지토리 관리자
- Sonatype Nexus
- Nexus에 대한 자세한 내용은 Sonatype Nexus 설명서를 참조하십시오.
- Artifactory
- Artifactory에 대한 자세한 내용은 JFrog Artifactory 문서를 참조하십시오.
- Apache Archiva
- Apache Archiva를 참조하십시오. Apache Archiva에 대한 자세한 내용은 Artifact Repository Manager 를 참조하십시오.
리포지토리 관리자가 일반적으로 사용되는 엔터프라이즈 환경에서 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을 다운로드하고 설치해야 합니다.
- Apache Maven 프로젝트로 이동 - Maven 을 다운로드하고 운영 체제에 대한 최신 배포를 다운로드합니다.
- 운영 체제용 Apache Maven을 다운로드하고 설치하는 방법에 대한 자세한 내용은 Maven 문서를 참조하십시오.
2.2.2. JBoss EAP Maven 리포지토리 다운로드 링크 복사링크가 클립보드에 복사되었습니다!
두 방법 중 하나를 사용하여 JBoss EAP Maven 리포지토리를 다운로드할 수 있습니다.
2.2.2.1. JBoss EAP Maven 리포지토리 ZIP 파일 다운로드 링크 복사링크가 클립보드에 복사되었습니다!
다음 단계에 따라 JBoss EAP Maven 리포지토리를 다운로드합니다.
- Red Hat 고객 포털에서 JBoss EAP 다운로드 페이지에 로그인합니다.
- Version(버전) 드롭다운 메뉴에서 7.4 를 선택합니다.
- 목록에서 Red Hat JBoss Enterprise Application Platform 7.4 Maven 리포지토리 항목을 찾고 다운로드를 클릭하여 리포지토리가 포함된 ZIP 파일을 다운로드합니다.
- ZIP 파일을 원하는 디렉토리에 저장합니다.
- ZIP 파일을 추출합니다.
2.2.2.2. Offliner 애플리케이션을 사용하여 JBoss EAP Maven 리포지토리 다운로드 링크 복사링크가 클립보드에 복사되었습니다!
Offliner 애플리케이션은 Red Hat Maven 리포지토리를 사용하여 JBoss EAP 애플리케이션을 개발하기 위한 Maven 아티팩트를 다운로드하는 대체 옵션으로 사용할 수 있습니다.
Offliner 애플리케이션을 사용하여 JBoss EAP Maven 리포지토리를 다운로드하는 프로세스는 기술 프리뷰로만 제공됩니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
기술 프리뷰 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털의 기술 프리뷰 기능 지원 범위를 참조하십시오.
- Red Hat 고객 포털에서 JBoss EAP 다운로드 페이지에 로그인합니다.
- Version(버전) 드롭다운 메뉴에서 7.4 를 선택합니다.
- 목록에서 Red Hat JBoss Enterprise Application Platform 7.4 Maven Repository Offliner Content List 항목을 찾고 다운로드를 클릭합니다.
텍스트 파일을 원하는 디렉터리에 저장합니다.
참고이 파일에는 라이센스 정보가 포함되어 있지 않습니다. Offliner 애플리케이션에서 다운로드한 아티팩트는 JBoss EAP와 함께 배포되는 Maven 리포지토리 ZIP 파일에 지정된 것과 동일한 라이센스를 갖습니다.
- Maven 중앙 리포지토리에서 Offliner 애플리케이션을 다운로드합니다.
다음 명령을 사용하여 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
$ java -jar offliner.jar -r http://repository.redhat.com/ga/ -d DOWNLOAD_FOLDER jboss-eap-7.4.0-maven-repository-content-with-sha256-checksums.txtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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 리포지토리를 사용하거나 나열된 세 가지 방법 중 하나를 사용하여 로컬로 다운로드하여 설치할 수 있습니다.
- 로컬 파일 시스템에 JBoss EAP Maven 리포지토리를 설치합니다. 자세한 내용은 로컬로 JBoss EAP Maven 리포지토리 설치를 참조하십시오.
- Apache Web Server에 JBoss EAP Maven 리포지토리를 설치합니다. 자세한 내용은 Apache httpd에서 사용하기 위해 JBoss EAP Maven 리포지토리 설치에서 참조하십시오.
- Nexus Maven 리포지토리를 사용하여 JBoss EAP Maven 리포지토리를 설치합니다. 자세한 내용은 Nexus Maven Repository Manager를 사용하여 리포지토리 관리를 참조하십시오.
2.2.3.1. JBoss EAP Maven 리포지토리를 로컬에 설치합니다. 링크 복사링크가 클립보드에 복사되었습니다!
이 옵션을 사용하여 JBoss EAP Maven 리포지토리를 로컬 파일 시스템에 설치합니다. 이 기능은 구성하기 쉽고 로컬 시스템에서 신속하게 가동하고 실행할 수 있습니다.
이 방법은 개발에 Maven을 사용하는 방법을 익히는 데 도움이 될 수 있지만 팀 프로덕션 환경에는 권장되지 않습니다.
새 Maven 리포지토리를 다운로드하기 전에 사용을 시도하기 전에 .m2/ 디렉터리에 있는 캐시된 리포지토리/ 하위 디렉터리를 제거합니다.
JBoss EAP Maven 리포지토리를 로컬 파일 시스템에 설치하려면 다음을 수행합니다.
- JBoss EAP Maven 리포지토리 ZIP 파일을 로컬 파일 시스템에 다운로드 했는지 확인합니다.
선택한 로컬 파일 시스템에서 파일의 압축을 풉니다.
그러면
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 설명서를 참조하십시오.
- JBoss EAP Maven 리포지토리 ZIP 파일이 로컬 파일 시스템에 다운로드되었는지 확인합니다.
- Apache 서버에서 웹에 액세스할 수 있는 디렉터리에서 파일의 압축을 풉니다.
생성된 디렉토리에서 읽기 액세스 및 디렉토리 검색을 허용하도록 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 설정 파일 구성
운영 체제에 대한 Maven
settings.xml파일을 찾습니다. 일반적으로${user.home}/.m2/디렉터리에 있습니다.-
Linux 또는 Mac의 경우
~/.m2/입니다. -
Windows의 경우
\Documents 및 Settings\.m2\또는\Users\.m2\입니다.
-
Linux 또는 Mac의 경우
-
settings.xml파일을 찾지 못하는 경우${user.home}/파일을.m2/conf/ 디렉터리에서 settings.xml${user.home}/.m2/디렉터리에 복사합니다. 다음 XML을
settings.xml파일의<profiles>요소에 복사합니다. JBoss EAP 리포지토리의 URL을 확인하고JBOSS_EAP_REPOSITORY_URL을 이 리포지토리로 교체합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음은 온라인 JBoss EAP Maven 리포지토리에 액세스하는 구성의 예입니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 XML을
settings.xml파일의<activeProfiles>요소에 복사합니다.<activeProfile>jboss-enterprise-maven-repository</activeProfile>
<activeProfile>jboss-enterprise-maven-repository</activeProfile>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat CodeReady Studio가 실행되는 동안
settings.xml파일을 수정하면 사용자 설정을 새로 고쳐야 합니다.- 메뉴에서 창 → 기본 설정을 선택합니다.
- Preferences(기본 설정 ) 창에서 Maven 을 확장하고 User Settings (사용자 설정)를 선택합니다.
- 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 파일 구성
-
텍스트 편집기에서 프로젝트의
pom.xml파일을 엽니다. 다음 리포지토리 구성을 추가합니다. 파일에 이미
<repositories>구성이 있는 경우<repository>요소를 추가합니다.<url>을 실제 리포지토리 위치로 변경하십시오.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 플러그인 리포지토리 구성을 추가합니다. 파일에 이미
<pluginRepositories>구성이 있는 경우<pluginRepository>요소를 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 구성
Window → Preferences 를 클릭하고 JBoss Tools 를 확장한 다음 JBoss Maven Integration 을 선택합니다.
그림 2.1. 기본 설정 창의 JBoss Maven Integration Pane
- Configure Maven Repositories(Maven 리포지토리 구성)를 클릭합니다.
Add Repository (리포지토리 추가)를 클릭하여 JBoss Enterprise Maven 리포지토리를 구성합니다. 다음과 같이 Add Maven Repository(Maven 리포지토리 추가) 대화 상자를 완료합니다.
-
Profile ID,Repository ID, Repository Name (리포지토리 이름 ) 값을
jboss-ga-repository로 설정합니다. -
리포지토리 URL 값을
http://maven.repository.redhat.com/ga로 설정합니다. - Active by default (기본적으로 활성화) 확인란을 클릭하여 Maven 리포지토리를 활성화합니다.
OK(확인)를 클릭합니다.
그림 2.2. Maven 리포지토리 추가
-
Profile ID,Repository ID, Repository Name (리포지토리 이름 ) 값을
- 리포지토리를 검토하고 Finish (완료)를 클릭합니다.
-
"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> 및 요소 값을 지정하여 BOM을 사용합니다.
<type>pom</type>
대부분의 경우 프로젝트 POM 파일의 종속 항목은 제공된 범위를 사용합니다. 이러한 클래스는 런타임 시 애플리케이션 서버에서 제공하며 사용자 애플리케이션으로 패키징할 필요가 없기 때문입니다.
지원되는 Maven Artifacts
제품 빌드 프로세스의 일환으로 JBoss EAP의 모든 런타임 구성 요소는 제어된 환경의 소스에서 빌드됩니다. 이렇게 하면 바이너리 아티팩트에 악성 코드가 포함되어 있지 않으며 제품 수명 동안 지원할 수 있습니다. 이러한 아티팩트는 -redhat 버전 한정자(예: 로 쉽게 식별할 수 있습니다.
1.0.0-redhat -1)
지원되는 아티팩트를 빌드 구성 pom.xml 파일에 추가하면 빌드에서 로컬 빌드 및 테스트에 올바른 바이너리 아티팩트를 사용하고 있는지 확인합니다. -redhat 버전이 있는 아티팩트는 지원되는 공용 API의 일부인 것은 아니며 향후 개정판에서는 변경될 수 있습니다. 지원되는 공개 API에 대한 자세한 내용은 릴리스에 포함된 Javadoc 설명서 를 참조하십시오.
예를 들어 지원되는 Hibernate 버전을 사용하려면 다음과 유사한 버전을 빌드 구성에 추가합니다.
위의 예에는 <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 릴리스 버전과 일치합니다.
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에 대한 종속성을 추가하고 groupId 에 org.jboss.spec 을 지정한 다음 애플리케이션에 필요한 특정 API에 대한 종속성을 추가합니다. API가 jboss-jakartaee-8.0 BOM에 포함되어 있기 때문에 이러한 종속성에는 버전이 필요하지 않으며 제공된 범위를 사용합니다.
다음 예제에서는 jboss-jakartaee-8.0 BOM의 1.0.0.Alpha1 버전을 사용하여 서블릿 및 Jakarta Server Pages API에 대한 종속성을 추가합니다.
JBoss EAP는 대부분의 제품 구성 요소의 API에 BOM을 패키징하고 제공합니다. 이러한 BOM 중 상당수는 org.jboss.bom 이라는 groupId 가 있는 더 큰 jboss-eap-jakartaee8 BOM로 편리하게 패키징됩니다. groupId 가 org.jboss.spec 인 jboss-jakartaee-8.0 BOM이 이 대형 BOM에 포함됩니다. 즉, 이 BOM에 패키지된 추가 JBoss EAP 종속성을 사용하는 경우 jboss-jakartaee BOM만 추가하면 됩니다.
-8.0 및 기타 BOM 종속성을 별도로 추가하지 않고 프로젝트의 POM 파일에 하나의 jboss-eap-jakartaee 8
애플리케이션 개발에 사용 가능한 JBoss EAP BOM
다음 표에는 애플리케이션 개발에 사용할 수 있는 Maven BOM이 나열되어 있습니다.
| 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 6의 이러한 BOM은 대부분의 사용 사례에서 더 간단하게 사용할 수 있도록 BOM이 더 적은 수로 통합되었습니다. 이제 Hibernate, 로깅, 트랜잭션, 메시징 및 기타 공용 API JAR이 각 사례에 별도의 BOM이 아닌 jboss-eap-jakartaee8 BOM에 포함됩니다.
다음 예제에서는 jboss-eap-jakartaee8 BOM의 7.4.0.GA 버전을 사용합니다.
JBoss EAP 클라이언트 BOM
클라이언트 BOM은 종속성 관리 섹션을 생성하거나 종속성을 정의하지 않습니다. 대신, 다른 BOM의 집계이며 원격 클라이언트 사용 사례에 필요한 종속성 집합을 패키징하는 데 사용됩니다.
The wildfly-ejb-client-bom,wildfly-jms-client-bom, and wildfly-jaxws-client-bom 은 jboss-eap-jakartaee8 BOM에서 관리하므로 프로젝트 종속 항목에서 버전을 관리할 필요가 없습니다.
다음은 프로젝트에 wildfly-ejb-client-bom, 종속성을 추가하는 방법의 예입니다.
wildfly- jms-client-bom 및 wildfly- jaxws-client-bom
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 배포는 두 개 이상의 모듈로 구성되며 다음 규칙에 의해 정의됩니다.
-
EAR의
lib/디렉터리는 상위 모듈이라는 단일 모듈입니다. - EAR 내의 각 WAR 배포는 단일 모듈입니다.
- EAR 내의 각 Jakarta Enterprise Beans JAR 배포는 단일 모듈입니다.
-
EAR의
하위 배포 모듈(예: EAR 내에 WAR 및 JAR 배포)에는 상위 모듈에 대한 자동 종속성이 있습니다. 그러나 서로에 대한 자동 종속성은 없습니다. 이는 하위 배포 격리라고 하며 배포당 또는 전체 애플리케이션 서버에 대해 비활성화할 수 있습니다.
하위 배포 모듈 간의 명시적 종속성은 다른 모듈과 동일한 방법으로 추가할 수 있습니다.
3.1.3. 클래스 로드 우선 순위 링크 복사링크가 클립보드에 복사되었습니다!
JBoss EAP 모듈식 클래스 로더는 우선 순위 시스템을 사용하여 클래스 로드 충돌을 방지합니다.
배포하는 동안 각 배포 및 각 종속 항목에 대해 전체 패키지 및 클래스 목록이 생성됩니다. 목록은 클래스 로드 우선 순위 규칙에 따라 정렬됩니다. 런타임 시 클래스를 로드할 때 클래스 로더가 이 목록을 검색하고 첫 번째 일치 항목을 로드합니다. 이렇게 하면 배포 클래스 경로 내의 동일한 클래스 및 패키지가 서로 충돌하지 않도록 합니다.
클래스 로더는 가장 높은 순서에서 가장 낮은 순서로 클래스를 로드합니다.
암시적 종속성: 이러한 종속성은 자카르타 EE API와 같은 JBoss EAP에서 자동으로 추가합니다. 이러한 종속성은 JBoss EAP에서 제공하는 공통 기능과 API를 포함하므로 가장 높은 수준의 로더 우선 순위를 가집니다.
암시적 종속성에 대한 자세한 내용은 암시적 모듈 종속성을 참조하십시오.
명시적 종속성: 이러한 종속성은 애플리케이션의
MANIFEST.MF파일 또는 새로운 선택적 JBoss 배포 설명자jboss-deployment-structure.xml파일을 사용하여 애플리케이션 구성에 수동으로 추가됩니다.명시적 종속성을 추가하는 방법에 대해서는 Add an Explicit Module Dependency to a Deployment 를 참조하십시오.
-
로컬 리소스: 배포 자체에 패키지된 클래스 파일입니다(예: WAR 파일의
WEB-INF/classes또는WEB-INF/lib디렉토리). -
배포 간 종속성: 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는 배포에 몇 가지 종속성을 자동으로 추가합니다. 자세한 내용은 암시적 모듈 종속성을 참조하십시오.
사전 요구 사항
종속성은 다음 두 가지 방법을 사용하여 구성할 수 있습니다.
-
배포의
MANIFEST.MF파일에 항목 추가. -
jboss-deployment-structure.xml배포 설명자에 항목 추가.
MANIFEST.MF에 종속성 설정 추가
MANIFEST.MF 파일에 필요한 종속성 항목을 생성하도록 Maven 프로젝트를 구성할 수 있습니다.
-
프로젝트에 없는 경우
MANIFEST.MF라는 파일을 생성합니다. 웹 애플리케이션(WAR)의 경우 이 파일을META-INF/디렉터리에 추가합니다. Jakarta Enterprise Beans 아카이브(JAR)의 경우META-INF/디렉터리에 추가합니다. 종속성 모듈 이름의 쉼표로 구분된 목록을 사용하여
MANIFEST.MF파일에 dependencies 항목을 추가합니다.Dependencies: org.javassist, org.apache.velocity, org.antlr
Dependencies: org.javassist, org.apache.velocity, org.antlrCopy to Clipboard Copied! Toggle word wrap Toggle overflow 종속성을 선택으로 만들려면 종속성 항목의 모듈 이름에
optional를 추가합니다.Dependencies: org.javassist optional, org.apache.velocity
Dependencies: org.javassist optional, org.apache.velocityCopy to Clipboard Copied! Toggle word wrap Toggle overflow 종속성은 종속성 항목에서 모듈 이름에
내보내기를 추가하여 내보낼수 있습니다.Dependencies: org.javassist, org.apache.velocity export
Dependencies: org.javassist, org.apache.velocity exportCopy to Clipboard Copied! Toggle word wrap Toggle overflow 주석플래그는 모듈 종속성에 Jakarta Enterprise Beans 인터셉터를 선언하는 경우와 같이 주석 스캔 중에 처리해야 하는 주석이 포함된 경우 필요합니다. 이 기능이 없으면 모듈에 선언된 Jakarta Enterprise Beans 인터셉터는 배포에 사용할 수 없습니다. 이 작업도 필요할 때 주석 검사와 관련된 다른 상황이 있습니다.Dependencies: org.javassist, test.module annotations
Dependencies: org.javassist, test.module annotationsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 종속성의
META-INF에 있는 기본 항목은 액세스할 수 없습니다.서비스종속성을 사용하면META-INF/서비스의 항목에액세스하여 모듈의서비스를로드할 수 있습니다.Dependencies: org.javassist, org.hibernate services
Dependencies: org.javassist, org.hibernate servicesCopy to Clipboard Copied! Toggle word wrap Toggle overflow beans.xml파일을 스캔하고 결과 빈을 애플리케이션에서 사용할 수 있도록 하려면meta-inf종속성을 사용할 수 있습니다.Dependencies: org.javassist, test.module meta-inf
Dependencies: org.javassist, test.module meta-infCopy to Clipboard Copied! Toggle word wrap Toggle overflow
jboss-deployment-structure.xml에 종속성 구성 추가
애플리케이션에 없는 경우
jboss-deployment-structure.xml이라는 새 파일을 생성하여 프로젝트에 추가합니다. 이 파일은<jboss-deployment-structure>의 루트 요소가 있는 XML 파일입니다.<jboss-deployment-structure> </jboss-deployment-structure>
<jboss-deployment-structure> </jboss-deployment-structure>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 웹 애플리케이션(WAR)의 경우 이 파일을
WEB-INF/디렉토리에 추가합니다. Jakarta Enterprise Beans 아카이브(JAR)의 경우META-INF/디렉터리에 추가합니다.-
문서 루트 및
<요소를 만듭니다.dependencies> 요소 내에 <deployment> <dependencies>노드 내에 각 모듈 종속성에 대한 모듈 요소를 추가합니다.name속성을 모듈의 이름으로 설정합니다.<module name="org.javassist" />
<module name="org.javassist" />Copy to Clipboard Copied! Toggle word wrap Toggle overflow 값
true를 사용하여 모듈 항목에선택적속성을 추가하여 종속성을 선택 사항으로 만들 수 있습니다. 이 속성의 기본값은false입니다.<module name="org.javassist" optional="true" />
<module name="org.javassist" optional="true" />Copy to Clipboard Copied! Toggle word wrap Toggle overflow 종속 항목은 값이
true인 모듈 항목에export특성을 추가하여 내보낼 수 있습니다. 이 속성의 기본값은false입니다.<module name="org.javassist" export="true" />
<module name="org.javassist" export="true" />Copy to Clipboard Copied! Toggle word wrap Toggle overflow 모듈 종속성에 주석 스캔 중에 처리해야 하는 주석이 포함된 경우
주석플래그가 사용됩니다.<module name="test.module" annotations="true" />
<module name="test.module" annotations="true" />Copy to Clipboard Copied! Toggle word wrap Toggle overflow services종속성은 이 종속성에서 발견되는서비스가사용되는지 여부와 방법을 지정합니다. 기본값은none입니다. 이 속성에 대한가져오기값을 지정하는 것은 dependency 모듈의META-INF/services경로를 포함하는 가져오기 필터 목록의 끝에 필터를 추가하는 것과 동일합니다. 이 속성에 대한export값을 설정하는 것은 내보내기 필터 목록에서 동일한 작업과 동일합니다.<module name="org.hibernate" services="import" />
<module name="org.hibernate" services="import" />Copy to Clipboard Copied! Toggle word wrap Toggle overflow META-INF종속성은 이 종속성의META-INF항목이 사용되는지 여부와 방법을 지정합니다. 기본값은none입니다. 이 속성에 대한가져오기값을 지정하는 것은 종속성 모듈의META-INF/**경로를 포함하는 가져오기 필터 목록의 끝에 필터를 추가하는 것과 동일합니다. 이 속성에 대한export값을 설정하는 것은 내보내기 필터 목록에서 동일한 작업과 동일합니다.<module name="test.module" meta-inf="import" />
<module name="test.module" meta-inf="import" />Copy to Clipboard Copied! Toggle word wrap Toggle overflow
예: 두 개의 종속성이 있는 jboss-deployment-structure.xml 파일
JBoss EAP는 지정된 모듈의 클래스를 배포할 때 애플리케이션의 클래스 경로에 추가합니다.
Jandex 인덱스 생성
annotations 플래그를 사용하려면 모듈에 Jandex 인덱스가 포함되어야 합니다. JBoss EAP 7.4에서는 자동으로 생성됩니다. 그러나 자동 검사는 CPU를 사용하고 배포 시간을 늘리는 긴 프로세스일 수 있으므로 성능상의 이유로 인덱스를 수동으로 추가하는 것이 좋습니다.
인덱스를 수동으로 추가하려면 새 "index JAR"을 생성하여 모듈에 추가합니다. Jandex JAR을 사용하여 인덱스를 빌드한 다음 새 JAR 파일에 삽입합니다. 현재 구현에서는 모듈 내의 JAR 파일에 인덱스가 추가되면 검사가 실행되지 않습니다.
Jandex 인덱스 생성::
인덱스를 생성합니다.
java -jar modules/system/layers/base/org/jboss/jandex/main/jandex-jandex-2.0.0.Final-redhat-1.jar $JAR_FILE
java -jar modules/system/layers/base/org/jboss/jandex/main/jandex-jandex-2.0.0.Final-redhat-1.jar $JAR_FILECopy to Clipboard Copied! Toggle word wrap Toggle overflow 임시 작업 공간을 생성합니다.
mkdir /tmp/META-INF
mkdir /tmp/META-INFCopy to Clipboard Copied! Toggle word wrap Toggle overflow 인덱스 파일을 작업 디렉터리로 이동합니다.
mv $JAR_FILE.ifx /tmp/META-INF/jandex.idx
mv $JAR_FILE.ifx /tmp/META-INF/jandex.idxCopy to Clipboard Copied! Toggle word wrap Toggle overflow 옵션 1: 새 JAR 파일에 인덱스 포함
jar cf index.jar -C /tmp META-INF/jandex.idx
jar cf index.jar -C /tmp META-INF/jandex.idxCopy to Clipboard Copied! Toggle word wrap Toggle overflow 그런 다음 모듈 디렉터리에 JAR을 배치하고
module.xml을 편집하여 리소스 루트에 추가합니다.옵션 2: 기존 JAR에 인덱스 추가
java -jar /modules/org/jboss/jandex/main/jandex-1.0.3.Final-redhat-1.jar -m $JAR_FILE
java -jar /modules/org/jboss/jandex/main/jandex-1.0.3.Final-redhat-1.jar -m $JAR_FILECopy to Clipboard Copied! Toggle word wrap Toggle overflow
주석 스캔에서 주석을 찾을 수 있도록 모듈 가져오기에 주석 색인을 활용하도록 지시합니다.
옵션 1:
MANIFEST.MF를 사용하여 모듈 종속성을 추가하는 경우 모듈 이름 뒤에주석을추가합니다. 예를 들면 다음과 같습니다.Dependencies: test.module, other.module
Dependencies: test.module, other.moduleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음으로 변경
Dependencies: test.module annotations, other.module
Dependencies: test.module annotations, other.moduleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 옵션 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 항목을 생성하기 전에 다음을 수행해야 합니다.
모듈 종속성을 포함하는 MANIFEST.MF 파일 생성
프로젝트의
pom.xml파일에서 패키징 플러그인 구성에 다음 구성을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 모듈 종속성 목록을
<Dependencies>요소에 추가합니다.MANIFEST.MF 파일에 종속성을 추가할 때 사용되는 것과 동일한 형식을 사용합니다.<Dependencies>org.javassist, org.apache.velocity</Dependencies>
<Dependencies>org.javassist, org.apache.velocity</Dependencies>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항및내보내기속성도 여기에 사용할 수 있습니다.<Dependencies>org.javassist optional, org.apache.velocity export</Dependencies>
<Dependencies>org.javassist optional, org.apache.velocity export</Dependencies>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Maven 어셈블리 목표를 사용하여 프로젝트를 빌드합니다.
mvn assembly:single
[Localhost ]$ mvn assembly:singleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 어셈블리 목표를 사용하여 프로젝트를 빌드하면 최종 아카이브에 지정된 모듈 종속성이 있는
MANIFEST.MF파일이 포함되어 있습니다.예제:
pom.xml에서 구성된 모듈 종속성참고예제는 WAR 플러그인을 나타내지만 JAR 및 Jakarta Enterprise Beans 플러그인(maven-jar-plugin 및 maven-ejb-plugin)에서도 작동합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. 암시적으로 로드되는 모듈 방지 링크 복사링크가 클립보드에 복사되었습니다!
암시적 종속성이 로드되지 않도록 배포 가능한 애플리케이션을 구성할 수 있습니다. 이는 애플리케이션에 암시적 종속성으로 애플리케이션 서버에서 제공하는 라이브러리 또는 프레임워크와 다른 버전의 라이브러리 또는 프레임워크를 포함하는 경우 유용할 수 있습니다.
사전 요구 사항
- 암시적 종속성을 제외하려는 작업 중인 소프트웨어 프로젝트.
- 제외할 모듈의 이름을 알아야 합니다. 암시적 종속성 목록 및 해당 조건은 암시적 모듈 종속성을 참조하십시오.
jboss-deployment-structure.xml에 종속성 제외 구성 추가
애플리케이션에 없는 경우
jboss-deployment-structure.xml이라는 새 파일을 생성하여 프로젝트에 추가합니다.<jboss-deployment-structure>의 루트 요소가 있는 XML 파일입니다.<jboss-deployment-structure> </jboss-deployment-structure>
<jboss-deployment-structure> </jboss-deployment-structure>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 웹 애플리케이션(WAR)의 경우 이 파일을
WEB-INF/디렉토리에 추가합니다. Jakarta Enterprise Beans 아카이브(JAR)의 경우META-INF/디렉터리에 추가합니다.문서 루트에
<deployment>요소와 그 안에<exclusions>요소를 만듭니다.<deployment> <exclusions> </exclusions> </deployment>
<deployment> <exclusions> </exclusions> </deployment>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 제외 요소 내에 제외할 각 모듈에 대해
<module>요소를 추가합니다.name속성을 모듈의 이름으로 설정합니다.<module name="org.javassist" />
<module name="org.javassist" />Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예제: 두 개의 모듈 제외
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5. 배포에서 하위 시스템 제외 링크 복사링크가 클립보드에 복사되었습니다!
하위 시스템을 제외하면 하위 시스템을 제거하는 것과 동일한 효과가 있지만 단일 배포에만 적용됩니다. jboss-deployment-structure.xml 구성 파일을 편집하여 배포에서 하위 시스템을 제외할 수 있습니다.
하위 시스템 제외
-
jboss-deployment-structure.xml파일을 편집합니다. <deployment>태그 내에 다음 XML을 추가합니다.<exclude-subsystems> <subsystem name="SUBSYSTEM_NAME" /> </exclude-subsystems>
<exclude-subsystems> <subsystem name="SUBSYSTEM_NAME" /> </exclude-subsystems>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
jboss-deployment-structure.xml파일을 저장합니다.
하위 시스템의 배포 장치 프로세서는 더 이상 배포에 실행되지 않습니다.
예: jboss-deployment-structure.xml 파일
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());
Class<?> targetClass = Class.forName("com.myorg.util.TargetClass", true, CurrentClass.class.getClassLoader());
지정된 이름으로 모든 리소스 찾기
리소스의 이름과 경로를 알고 있는 경우 직접 로드하는 가장 좋은 방법은 표준 JDK(Java Development Kit) Class 또는 Class Loader API를 사용하는 것입니다.
단일 리소스 로드.
배포에서 클래스 또는 다른 클래스와 동일한 디렉터리에 있는 단일 리소스를 로드하려면
Class.getResourceAsStream()메서드를 사용할 수 있습니다.InputStream inputStream = CurrentClass.class.getResourceAsStream("targetResourceName");InputStream inputStream = CurrentClass.class.getResourceAsStream("targetResourceName");Copy to Clipboard Copied! Toggle word wrap Toggle overflow 단일 리소스의 모든 인스턴스를 로드합니다.
배포의 클래스 로더에 표시되는 단일 리소스의 모든 인스턴스를 로드하려면
Class.getClassLoader().getResources(String resourceName)메서드를 사용합니다. 여기서resourceName은 리소스의 정규화된 경로입니다. 이 메서드는 지정된 이름으로 클래스 로더에서 액세스할 수 있는 리소스에 대한 모든URL오브젝트의 Enumeration을 반환합니다. 그런 다음,openStream()메서드를 사용하여 각 스트림을 열도록 URL 배열을 반복할 수 있습니다.다음 예제에서는 리소스의 모든 인스턴스를 로드하고 결과를 반복합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고URL 인스턴스는 로컬 스토리지에서 로드되므로
openConnection()또는 기타 관련 방법을 사용할 필요가 없습니다. 스트림은 코드의 복잡성을 최소화하고 훨씬 더 간단하게 사용할 수 있습니다.클래스 로더에서 클래스 파일을 로드합니다.
클래스가 이미 로드된 경우 다음 구문을 사용하여 해당 클래스에 해당하는 클래스 파일을 로드할 수 있습니다.
InputStream inputStream = CurrentClass.class.getResourceAsStream(TargetClass.class.getSimpleName() + ".class");
InputStream inputStream = CurrentClass.class.getResourceAsStream(TargetClass.class.getSimpleName() + ".class");Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클래스가 아직 로드되지 않은 경우 클래스 로더를 사용하고 경로를 변환해야 합니다.
String className = "com.myorg.util.TargetClass" InputStream inputStream = CurrentClass.class.getClassLoader().getResourceAsStream(className.replace('.', '/') + ".class");String className = "com.myorg.util.TargetClass" InputStream inputStream = CurrentClass.class.getClassLoader().getResourceAsStream(className.replace('.', '/') + ".class");Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
Dependencies: org.jboss.modules
이러한 API는 유연성을 향상하지만 직접 경로 조회보다 훨씬 느리게 실행됩니다.
이 섹션에서는 애플리케이션 코드의 리소스를 프로그래밍 방식으로 반복할 수 있는 몇 가지 방법에 대해 설명합니다.
배포 내 및 모든 가져오기 내에서 리소스를 나열합니다.
리소스를 정확한 경로로 검색할 수 없는 경우가 있습니다. 예를 들어 정확한 경로는 알 수 없거나 지정된 경로에서 둘 이상의 파일을 검사해야 할 수 있습니다. 이 경우 JBoss 모듈 라이브러리는 모든 배포 리소스를 반복하기 위한 여러 API를 제공합니다. 두 가지 방법 중 하나를 사용하여 배포의 리소스를 반복할 수 있습니다.
단일 모듈에 있는 모든 리소스를 반복합니다.
ModuleClassLoader.iterateResources()메서드는 이 모듈 클래스 로더 내의 모든 리소스를 반복합니다. 이 메서드에는 검색할 시작 디렉토리 이름과 부울이 있습니다. 이 인수는 하위 디렉토리로 재귀해야 하는지 여부를 지정합니다.다음 예제에서는 ModuleClassLoader를 가져와
bin/디렉토리의 리소스에 대한 반복자를 가져와 하위 디렉터리로 재귀하는 방법을 보여줍니다.ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader(); Iterator<Resource> mclResources = moduleClassLoader.iterateResources("bin",true);ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader(); Iterator<Resource> mclResources = moduleClassLoader.iterateResources("bin",true);Copy to Clipboard Copied! Toggle word wrap Toggle overflow 결과 반복자를 사용하여 일치하는 각 리소스를 검사하고 이름 및 크기(사용 가능한 경우)를 쿼리하거나 읽을 수 있는 스트림을 열거나 리소스의 URL을 획득할 수 있습니다.
단일 모듈과 가져온 리소스에 있는 모든 리소스를 반복합니다.
Module.iterateResources()메서드는 모듈로 가져온 리소스를 포함하여 이 모듈 클래스 로더 내의 모든 리소스를 반복합니다. 이 메서드는 이전 메서드보다 훨씬 큰 집합을 반환합니다. 이 메서드에는 결과를 특정 패턴으로 좁히는 필터인 인수가 필요합니다. 또는 전체 세트를 반환하도록 PathFilters.acceptAll()을 제공할 수 있습니다.다음 예제에서는 가져오기를 포함하여 이 모듈에서 전체 리소스 세트를 찾는 방법을 보여줍니다.
ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader(); Module module = moduleClassLoader.getModule(); Iterator<Resource> moduleResources = module.iterateResources(PathFilters.acceptAll());
ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader(); Module module = moduleClassLoader.getModule(); Iterator<Resource> moduleResources = module.iterateResources(PathFilters.acceptAll());Copy to Clipboard Copied! Toggle word wrap Toggle overflow
패턴과 일치하는 모든 리소스를 찾습니다.
배포 내에서 또는 배포의 전체 가져오기 세트 내에서 특정 리소스만 찾아야 하는 경우 리소스 반복을 필터링해야 합니다. API를 필터링하는 JBoss 모듈은 이 작업을 수행할 수 있는 몇 가지 툴을 제공합니다.
전체 종속성 세트를 검사합니다.
전체 종속성 세트를 검사해야 하는 경우
Module.iterateResources()메서드의PathFilter매개변수를 사용하여 일치하는 각 리소스의 이름을 확인할 수 있습니다.배포 종속성 검사.
배포 내에서만 확인해야 하는 경우
ModuleClassLoader.iterateResources()메서드를 사용합니다. 그러나 추가 방법을 사용하여 결과 반복자를 필터링해야 합니다.PathFilters.filtered()메서드는 이 경우 리소스 반복자의 필터링된 보기를 제공할 수 있습니다.PathFilters클래스에는 하위 경로 검색 또는 정확한 일치 또는 Ant 스타일 "glob" 패턴 일치를 포함하여 다양한 기능을 수행하는 필터를 생성하고 구성하는 많은 정적 방법이 포함되어 있습니다.
리소스를 필터링하기 위한 추가 코드 예제.
다음 예제에서는 다양한 기준에 따라 리소스를 필터링하는 방법을 보여줍니다.
예제: 배치에서 이름이
지정된 모든 파일 찾기.propertiesModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader(); Iterator<Resource> mclResources = PathFilters.filtered(PathFilters.match("**/messages.properties"), moduleClassLoader.iterateResources("", true));ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader(); Iterator<Resource> mclResources = PathFilters.filtered(PathFilters.match("**/messages.properties"), moduleClassLoader.iterateResources("", true));Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예제: 배치 및 가져오기에서 이름이 지정된 모든 파일 찾기
.propertiesModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader(); Module module = moduleClassLoader.getModule(); Iterator<Resource> moduleResources = module.iterateResources(PathFilters.match("**/message.properties"));ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader(); Module module = moduleClassLoader.getModule(); Iterator<Resource> moduleResources = module.iterateResources(PathFilters.match("**/message.properties"));Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예제: 배포의
my-resources라는 모든 디렉토리 내에서 모든 파일 찾기ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader(); Iterator<Resource> mclResources = PathFilters.filtered(PathFilters.match("**/my-resources/**"), moduleClassLoader.iterateResources("", true));ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader(); Iterator<Resource> mclResources = PathFilters.filtered(PathFilters.match("**/my-resources/**"), moduleClassLoader.iterateResources("", true));Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예제: 배치 및 가져오기에서 이름이 지정된 모든 파일 검색
또는오류ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader(); Module module = moduleClassLoader.getModule(); Iterator<Resource> moduleResources = module.iterateResources(PathFilters.any(PathFilters.match("**/messages"), PathFilters.match("**/errors"));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 Copied! Toggle word wrap Toggle overflow 예제: 배포의 특정 패키지에서 모든 파일 찾기
ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader(); Iterator<Resource> mclResources = moduleClassLoader.iterateResources("path/form/of/packagename", false);ModuleClassLoader moduleClassLoader = (ModuleClassLoader) TargetClass.class.getClassLoader(); Iterator<Resource> mclResources = moduleClassLoader.iterateResources("path/form/of/packagename", false);Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 배포를 종속성으로 추가할 수 없습니다.
배포 설명자 파일을 추가합니다.
jboss-deployment-structure.xml배포 설명자 파일을 EAR의META-INF디렉토리에 추가하고 다음 내용을 추가합니다.<jboss-deployment-structure> </jboss-deployment-structure>
<jboss-deployment-structure> </jboss-deployment-structure>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <ear-subdeployments-isolated>요소를 추가합니다.true내용과 함께 아직 없는 경우<ear-sub파일에 추가합니다.deployments-isolated>요소를 jboss-deployment-structure.xml<ear-subdeployments-isolated>true</ear-subdeployments-isolated>
<ear-subdeployments-isolated>true</ear-subdeployments-isolated>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
이 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
shared-session-config 요소는 EAR 내의 모든 WAR에 대해 공유 세션 관리자를 구성하는 데 사용됩니다. shared-session-config 요소가 있으면 EAR 내의 모든 WAR가 동일한 세션 관리자를 공유합니다. 여기에서 변경한 내용은 EAR에 포함된 모든 WAR에 영향을 미칩니다.
3.8. 사용자 정의 모듈에 태그 라이브러리 설명자 (TLD) 배포 링크 복사링크가 클립보드에 복사되었습니다!
TLD(Common Tag Library Descriptors)를 사용하는 여러 애플리케이션이 있는 경우 애플리케이션이 하나의 중앙 위치에 있고 고유한 위치에 있도록 애플리케이션에서 TLD를 구분하는 것이 유용할 수 있습니다. 이를 통해 사용하는 개별 애플리케이션을 업데이트할 필요 없이 TLD에 쉽게 추가하고 업데이트할 수 있습니다.
이는 TLD JAR을 포함하는 사용자 지정 JBoss EAP 모듈을 생성하고 애플리케이션에서 해당 모듈에 대한 종속성을 선언하여 수행할 수 있습니다. 자세한 내용은 모듈 및 종속성을 참조하십시오.
하나 이상의 JAR에 TLD가 포함되어 있고 TLD가 META-INF 에 설정되어 있는지 확인합니다.
사용자 지정 모듈에 TLD 배포
관리 CLI를 사용하여 JBoss EAP 인스턴스에 연결하고 다음 명령을 실행하여 TLD JAR을 포함하는 사용자 지정 모듈을 생성합니다.
module add --name=MyTagLibs --resources=/path/to/TLDarchive.jar
module add --name=MyTagLibs --resources=/path/to/TLDarchive.jarCopy to Clipboard Copied! Toggle word wrap Toggle overflow 중요모듈관리 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
명령을사용할 수 있습니다.
-
linux의 경우 -
- 애플리케이션에서 배포에 명시적 모듈 종속성 추가에 설명된 방법 중 하나를 사용하여 새로운 MyTagLibs 사용자 지정 모듈에 대한 종속성을 선언합니다.
종속성을 선언할 때 META-INF 도 가져와야 합니다. 예를 들어 MANIFEST.MF 의 경우 :
Dependencies: com.MyTagLibs meta-inf
Dependencies: com.MyTagLibs meta-inf
또는 jboss-deployment-structure.xml 의 경우 meta-inf 특성을 사용합니다.
3.9. 배포로 모듈 표시 링크 복사링크가 클립보드에 복사되었습니다!
배포로 모듈 표시
list-modules 관리 작업을 사용하여 각 배포에 따라 모듈 목록을 표시할 수 있습니다.
:list-modules
:list-modules
예제: 독립 실행형 서버에 대한 배포로 모듈 표시
/deployment=ejb-in-ear.ear:list-modules
/deployment=ejb-in-ear.ear:list-modules
/deployment=ejb-in-ear.ear/subdeployment=ejb-in-ear-web.war:list-modules
/deployment=ejb-in-ear.ear/subdeployment=ejb-in-ear-web.war:list-modules
예제: 관리형 도메인의 배포를 통해 모듈 표시
/host=master/server=server-one/deployment=ejb-in-ear.ear:list-modules
/host=master/server=server-one/deployment=ejb-in-ear.ear:list-modules
/host=master/server=server-one/deployment=ejb-in-ear.ear/subdeployment=ejb-in-ear-web.war:list-modules
/host=master/server=server-one/deployment=ejb-in-ear.ear/subdeployment=ejb-in-ear-web.war:list-modules
이 작업은 목록이 간결한 보기에 표시됩니다.
예제: 표준 목록 출력
verbose=[false*|true] 특성을 사용하면 보다 자세한 목록이 생성됩니다.
예제: 상세 목록 출력
다음 표에서는 출력에 제공된 정보의 범주를 설명합니다.
| 카테고리 | 설명 |
| system-dependencies | 서버에 의해 암시적으로 추가됨. |
| 로컬 종속성 | 배포의 다른 부분에 의해 추가됨. |
| user-dependencies |
|
3.10. 클래스 로드 참조 링크 복사링크가 클립보드에 복사되었습니다!
3.10.1. 암시적 모듈 종속성 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에는 종속성 및 종속성을 트리거하는 조건으로 배포에 자동으로 추가되는 모듈이 나열되어 있습니다.
| 종속성 추가를 위한 하위 시스템 응답 | 항상 추가된 패키지 종속성 | 조건부로 추가된 패키지 종속성 | 종속성 추가를 트리거하는 조건 |
|---|---|---|---|
| 애플리케이션 클라이언트 |
| ||
| 배치 |
| ||
| Jakarta Bean Validation |
| ||
| 코어 서버 |
| ||
| DriverDependenciesProcessor |
| ||
| EE |
| ||
| Jakarta Enterprise Beans 3 |
|
| |
| IIOP |
| ||
| Jakarta RESTful Web Services(RESTEasy) |
|
| 배포에 Jakarta RESTful Web Services 주석이 있습니다. |
| 자카르타 커넥터 |
|
| RR(리소스 어댑터) 아카이브 배포. |
| Jakarta Persistence (Hibernate) |
|
|
배포 설명자에
JBoss EAP는 지속성 프로바이더 이름을 모듈 이름에 매핑합니다. |
| Jakarta Server Faces |
| EAR 애플리케이션에 추가됨.
| |
| JSR-77 |
| ||
| 로깅 |
| ||
| 메일 |
| ||
| 메시징 |
|
| |
| PicketLink Federation |
| ||
| POJO |
| ||
| SAR |
|
| |
| Seam2 |
| . | |
| 보안 |
| ||
| ServiceActivator |
| ||
| 트랜잭션 |
|
| |
| Undertow |
|
| |
| 웹 서비스 |
|
| 애플리케이션 클라이언트 유형이 아닌 경우 조건부 종속성을 추가합니다. |
| weld (Jakarta 컨텍스트 및 종속성 주입) |
|
|
배포에 |
3.10.2. 포함된 모듈 링크 복사링크가 클립보드에 복사되었습니다!
포함된 모듈의 전체 목록 및 지원 여부는 Red Hat 고객 포털에서 Red Hat JBoss Enterprise Application Platform 7에 포함된 모듈을 참조하십시오.
4장. 로깅 링크 복사링크가 클립보드에 복사되었습니다!
4.1. 로깅 정보 링크 복사링크가 클립보드에 복사되었습니다!
로깅은 애플리케이션 활동의 레코드 또는 로그를 제공하는 애플리케이션에서 일련의 메시지를 기록하는 방법입니다.
로그 메시지는 애플리케이션을 디버깅할 때 개발자와 프로덕션에서 애플리케이션을 유지 관리하는 시스템 관리자에게 중요한 정보를 제공합니다.
대부분의 최신 Java 로깅 프레임워크에는 정확한 시간 및 메시지 출처와 같은 세부 정보도 포함되어 있습니다.
4.1.1. 지원되는 애플리케이션 로깅 프레임워크 링크 복사링크가 클립보드에 복사되었습니다!
JBoss LogManager는 다음과 같은 로깅 프레임워크를 지원합니다.
- JBoss Logging(JBoss EAP에 포함)
- Apache Commons Logging
- SLF4J(Simple Logging Facade for Java)
- Apache log4j
- Java SE Logging(java.util.logging)
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를 참조하십시오.
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종속성을 추가해야 합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow jboss-eap-jakartaee8 BOM은
jboss-logging버전을 관리합니다. 자세한 내용은 프로젝트 종속성 관리를 참조하십시오. 애플리케이션에서로깅의 작업 예는 JBoss EAP와 함께 제공되는 로깅 빠른 시작을 참조하십시오.
JBoss EAP가 배포된 애플리케이션에 JAR을 제공하므로 빌드된 애플리케이션에 JAR을 포함할 필요가 없습니다.
로깅을 추가할 각 클래스에 대해 다음을 수행합니다.
사용할 JBoss Logging 클래스 네임스페이스에 대한 import 문을 추가합니다. 최소한 다음 가져오기가 필요합니다.
import org.jboss.logging.Logger;
import org.jboss.logging.Logger;Copy to Clipboard Copied! Toggle word wrap Toggle overflow org.jboss.logging.Logger인스턴스를 생성하고 정적 메서드Logger.getLogger(Class)를 호출하여 초기화합니다. 각 클래스에 대해 단일 인스턴스 변수로 생성하는 것이 좋습니다.private static final Logger LOGGER = Logger.getLogger(HelloWorld.class);
private static final Logger LOGGER = Logger.getLogger(HelloWorld.class);Copy to Clipboard Copied! Toggle word wrap Toggle overflow
로그 메시지를 보내려는 코드에서
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.");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 Copied! Toggle word wrap Toggle overflow JBoss Logging 방법의 전체 목록은 Logging API 설명서를 참조하십시오.
다음 예제에서는 속성 파일에서 애플리케이션에 대한 사용자 지정 구성을 로드합니다. 지정된 파일을 찾을 수 없는 경우 ERROR 수준 로그 메시지가 기록됩니다.
예제: JBoss Logging으로 애플리케이션 로깅
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 또는 해당 구성 파일은 지원하지 않습니다.
절차
org.apache.logging.log4j:log4j-api를 프로젝트pom.xml파일에 대한 종속성으로 추가합니다.org.apache.logging.log4j:log4j-api를pom.xml파일에 추가하는 예입니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고log4j-apiMaven 종속성은 Apache Log4j2 API를 나타냅니다.log4jMaven 종속성은 Apache Log4j API를 나타냅니다.애플리케이션 메시지를 기록하면 해당 메시지를 JBoss Log Manager 구현으로 보냅니다.
-
선택 사항:
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 버전을 포함해야 합니다.
절차
-
jboss-deployment-structure.xml파일에서org.apache.logging.log4j.api모듈 종속성을 제외하여 Log4j로깅종속성을 비활성화합니다. log4j-api종속성과log4j2종속성을 프로젝트pom.xml파일에 추가합니다.log4j-api종속성 및log4j2종속성을pom.xml파일에 추가하는 예.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고log4j-apiMaven 종속성은 Apache Log4j2 API를 나타냅니다.log4jMaven 종속성은 Apache Log4j API를 나타냅니다.애플리케이션 메시지를 기록하면 해당 메시지를 Log4j2 LogManager 구현으로 보냅니다.
선택 사항:
org.apache.logging.log4j.api 모듈을제외하려면jboss-deployment-structure.xml파일에서 모듈을 제외하거나add-logging-api-dependencies특성을false로 설정해야 합니다. 그런 다음log4j2-api및log4j2-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.PeriodicSizeRotatingFileHandlersyslogorg.jboss.logmanager.handlers.SyslogHandlerasyncorg.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 구성
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
Manifest-Version: 1.0 Logging-Profile: LOGGING_PROFILE_NAMECopy to Clipboard Copied! Toggle word wrap Toggle overflow 애플리케이션에 이미
MANIFEST.MF파일이 있는 경우 다음 행을 추가하여 로깅 프로필 이름을 지정합니다.Logging-Profile: LOGGING_PROFILE_NAME
Logging-Profile: LOGGING_PROFILE_NAMECopy to Clipboard Copied! Toggle word wrap Toggle overflow
Maven 및 maven-war-plugin 을 사용하는 경우 MANIFEST.MF 파일을 src/main/resources/META-INF/ 에 배치하고 pom.xml 파일에 다음 구성을 추가합니다.
애플리케이션이 배포되면 지정된 로깅 프로필의 로그 메시지에 구성을 사용합니다.
로깅 프로필 및 애플리케이션을 구성하는 방법의 예는 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 인터페이스를 생성하여 국제화된 로그 메시지를 생성할 수 있습니다.
이 섹션에서는 모든 선택적 기능이나 로그 메시지의 로컬화를 다루지는 않습니다.
아직 완료하지 않은 경우 JBoss EAP Maven 리포지토리를 사용하도록 Maven 설정을 구성합니다.
자세한 내용은 Configure the JBoss EAP Maven Repository using the Maven Settings 에서 참조하십시오.
JBoss Logging Tools를 사용하도록 프로젝트의
pom.xml파일을 구성합니다.자세한 내용은 JBoss Logging Tools Maven Configuration을 참조하십시오.
로그 메시지 정의를 포함하도록 프로젝트에 Java 인터페이스를 추가하여 메시지 로거 인터페이스를 만듭니다.
정의할 로그 메시지를 설명하도록 인터페이스의 이름을 지정합니다. 로그 메시지 인터페이스에는 다음 요구 사항이 있습니다.
-
@org.jboss.logging.annotations.MessageLogger에 주석을 달아야 합니다. -
선택적으로
org.jboss.logging.BasicLogger를 확장할 수 있습니다. 인터페이스는 인터페이스와 동일한 유형의 메시지 로거인 필드를 정의해야 합니다. 이를
@org.jboss.logging.메서드로 수행합니다.Logger의 getMessageLogger()예제: 메시지 로거 생성
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
각 로그 메시지의 인터페이스에 메서드 정의를 추가합니다.
각 메서드가 나타내는 로그 메시지에 대해 설명적으로 이름을 지정합니다. 각 방법에는 다음 요구 사항이 있습니다.
-
메서드는
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();
@LogMessage @Message(value = "Customer query failed, Database not available.") void customerQueryFailDBClosed();Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
메서드는
메시지가 로깅되어야 하는 코드의 인터페이스 메서드에 호출을 추가하여 메서드를 호출합니다.
인터페이스 구현을 생성할 필요가 없으며, 프로젝트를 컴파일할 때 주석 프로세서가 이 작업을 수행합니다.
AccountsLogger.LOGGER.customerQueryFailDBClosed();
AccountsLogger.LOGGER.customerQueryFailDBClosed();Copy to Clipboard Copied! Toggle word wrap Toggle overflow 사용자 지정 로거는
BasicLogger에서 하위 분류되므로BasicLogger의 로깅 방법도 사용할 수 있습니다. 비 국제화 메시지를 기록하기 위해 다른 로거를 생성할 필요는 없습니다.AccountsLogger.LOGGER.error("Invalid query syntax.");AccountsLogger.LOGGER.error("Invalid query syntax.");Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 이 프로젝트는 이제 지역화할 수 있는 하나 이상의 국제화된 로거를 지원합니다.
JBoss EAP와 함께 제공되는 logging-tools 빠른 시작은 JBoss Logging Tools 사용 방법에 대한 작업 예제를 제공하는 간단한 Maven 프로젝트입니다.
4.5.3.2. 국제화된 메시지 생성 및 사용 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 국제화된 메시지를 만들고 사용하는 방법을 설명합니다.
이 섹션에서는 모든 선택적 기능이나 해당 메시지를 로컬화하는 프로세스에 대해서는 다루지 않습니다.
- 아직 완료하지 않은 경우 JBoss EAP Maven 리포지토리를 사용하도록 Maven 설정을 구성합니다. 자세한 내용은 Configure the JBoss EAP Maven Repository using the Maven Settings 에서 참조하십시오.
-
JBoss Logging Tools를 사용하도록 프로젝트의
pom.xml파일을 구성합니다. 자세한 내용은 JBoss Logging Tools Maven Configuration을 참조하십시오. 예외에 대한 인터페이스를 만듭니다. JBoss Logging Tools는 인터페이스에서 국제화된 메시지를 정의합니다. 포함된 메시지에 대해 각 인터페이스를 설명적으로 지정합니다. 인터페이스에는 다음 요구 사항이 있습니다.
-
공용으로 선언해야 합니다. -
@org.jboss.logging.annotations.MessageBundle으로 주석을 달아야 합니다. 인터페이스는 인터페이스와 동일한 유형의 메시지 번들인 필드를 정의해야 합니다.
예제:
MessageBundle인터페이스 만들기@MessageBundle(projectCode="") public interface GreetingMessageBundle { GreetingMessageBundle MESSAGES = Messages.getBundle(GreetingMessageBundle.class); }@MessageBundle(projectCode="") public interface GreetingMessageBundle { GreetingMessageBundle MESSAGES = Messages.getBundle(GreetingMessageBundle.class); }Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고Messages.getBundle(GreetingMessagesBundle.class)호출은Messages.getBundle(GreetingMessagesBundle.class, Locale.getDefault())을 호출하는 것과 같습니다.locale
.getDefault()는 Java 가상 머신의 이 인스턴스에 대한 기본 로케일의 현재 값을 가져옵니다. Java Virtual Machine은 호스트 환경에 따라 시작 중에 기본 로케일을 설정합니다. 로케일이 명시적으로 지정되지 않은 경우 로케일이 중요한 여러 메서드에서 사용됩니다.setDefault방법을 사용하여 변경할 수 있습니다.자세한 내용은 JBoss EAP 구성 가이드에서 서버의 기본 로케일 설정을 참조하십시오.
-
각 메시지의 인터페이스에 메서드 정의를 추가합니다. 각 메서드가 나타내는 메시지에 대해 설명적으로 이름을 지정합니다. 각 방법에는 다음 요구 사항이 있습니다.
-
String유형의 오브젝트를 반환해야 합니다. -
@org.jboss.logging.annotations.Message 주석을 사용하여 주석을 달아야합니다. @org.jboss.logging.annotations.Message의 value 특성은 기본 메시지로 설정해야 합니다. 이 메시지는 번역을 사용할 수 없는 경우 사용됩니다.@Message(value = "Hello world.") String helloworldString();
@Message(value = "Hello world.") String helloworldString();Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
메시지를 가져와야 하는 애플리케이션에서 인터페이스 메서드를 호출합니다.
System.out.println(helloworldString());
System.out.println(helloworldString());Copy to Clipboard Copied! Toggle word wrap Toggle overflow
이 프로젝트는 이제 지역화할 수 있는 국제화된 메시지 문자열을 지원합니다.
전체 작업 예는 JBoss EAP와 함께 제공되는 logging-tools 빠른 시작을 참조하십시오.
4.5.3.3. 국제화된 예외 만들기 링크 복사링크가 클립보드에 복사되었습니다!
JBoss Logging Tools를 사용하여 국제화된 예외를 생성하고 사용할 수 있습니다.
다음 지침에서는 Red Hat CodeReady Studio 또는 Maven을 사용하여 빌드된 기존 소프트웨어 프로젝트에 국제화된 예외를 추가하려고 한다고 가정합니다.
이 섹션에서는 일부 선택적 기능이나 이러한 예외를 지역화하는 과정을 다루지는 않습니다.
-
JBoss Logging Tools를 사용하도록 프로젝트의
pom.xml파일을 구성합니다. 자세한 내용은 JBoss Logging Tools Maven Configuration을 참조하십시오. 예외에 대한 인터페이스를 만듭니다. JBoss Logging Tools는 인터페이스에서 국제화된 예외를 정의합니다. 정의하는 예외에 대해 각 인터페이스를 설명하여 이름을 지정합니다. 인터페이스에는 다음 요구 사항이 있습니다.
-
공용으로 선언해야 합니다. -
@MessageBundle으로 주석을 달아야 합니다. 인터페이스는 인터페이스와 동일한 유형의 메시지 번들인 필드를 정의해야 합니다.
예제:
예외Bundle인터페이스 만들기@MessageBundle(projectCode="") public interface ExceptionBundle { ExceptionBundle EXCEPTIONS = Messages.getBundle(ExceptionBundle.class); }@MessageBundle(projectCode="") public interface ExceptionBundle { ExceptionBundle EXCEPTIONS = Messages.getBundle(ExceptionBundle.class); }Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
각 예외에 대해 인터페이스에 메서드 정의를 추가합니다. 각 메서드가 나타내는 예외에 대해 설명적으로 이름을 지정합니다. 각 방법에는 다음 요구 사항이 있습니다.
-
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);
@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 Copied! Toggle word wrap Toggle overflow
-
예외 중 하나를 가져와야 하는 코드에서 인터페이스 메서드를 호출합니다. 메서드에서 예외를 발행하지 않고 예외 오브젝트를 반환하여 트리거할 수 있습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
이 프로젝트는 이제 지역화할 수 있는 국제화된 예외를 지원합니다.
전체 작업 예는 JBoss EAP와 함께 제공되는 logging-tools 빠른 시작을 참조하십시오.
4.5.4. 국제화된 로거, 메시지 및 예외 로컬화 링크 복사링크가 클립보드에 복사되었습니다!
4.5.4.1. Maven으로 새 번역 속성 파일 생성 링크 복사링크가 클립보드에 복사되었습니다!
Maven을 사용하여 빌드된 프로젝트는 포함된 각 MessageLogger 및 Message Bundle 에 대한 빈 번역 속성 파일을 생성할 수 있습니다. 이러한 파일을 새로운 번역 속성 파일로 사용할 수 있습니다.
다음 절차에서는 Maven 프로젝트를 구성하여 새 번역 속성 파일을 생성하는 방법을 보여줍니다.
사전 요구 사항
- 이미 작동 중인 Maven 프로젝트가 있어야 합니다.
- 프로젝트는 JBoss Logging Tools용으로 이미 구성되어 있어야 합니다.
- 프로젝트에는 국제화된 로그 메시지 또는 예외를 정의하는 하나 이상의 인터페이스가 포함되어야 합니다.
번역 속성 파일 생성
Maven 컴파일러 플러그인 구성에
-AgenereatedTranslationFilePath컴파일러 인수를 추가하여 Maven 구성을 추가하고 새 파일이 생성될 경로를 할당합니다.이 구성은 Maven 프로젝트의
target/generated-translation-files디렉터리에 새 파일을 생성합니다.예제: 변환 파일 경로 정의
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Maven을 사용하여 프로젝트를 빌드합니다.
mvn compile
$ mvn compileCopy to Clipboard Copied! Toggle word wrap Toggle overflow @MessageBundle 또는로 주석이 추가된 각 인터페이스에 대해 하나의 속성 파일이 생성됩니다.@MessageLogger- 새 파일은 각 인터페이스가 선언되는 Java 패키지에 해당하는 하위 디렉터리에 생성됩니다.
각 새 파일은 파일을 생성하는 데 사용되는 인터페이스의
이름인다음 패턴을 사용하여 이름이 지정됩니다.INTERFACE_NAME.i18n_locale_COUNTRY_VARIANT.properties
INTERFACE_NAME.i18n_locale_COUNTRY_VARIANT.propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
이제 결과 파일을 새로운 번역의 기반으로 프로젝트에 복사할 수 있습니다.
전체 작업 예는 JBoss EAP와 함께 제공되는 logging-tools 빠른 시작을 참조하십시오.
4.5.4.2. 국제화된 로거, 예외 또는 메시지 변환 링크 복사링크가 클립보드에 복사되었습니다!
속성 파일은 JBoss Logging Tools를 사용하여 인터페이스에 정의된 로깅 및 예외 메시지를 변환하는 데 사용할 수 있습니다.
다음 절차에서는 번역 속성 파일을 생성 및 사용하는 방법을 보여주며 국제화된 예외 또는 로그 메시지에 대해 정의된 하나 이상의 인터페이스가 있는 프로젝트가 이미 있다고 가정합니다.
사전 요구 사항
- 이미 작동 중인 Maven 프로젝트가 있어야 합니다.
- 프로젝트는 JBoss Logging Tools용으로 이미 구성되어 있어야 합니다.
- 프로젝트에는 국제화된 로그 메시지 또는 예외를 정의하는 하나 이상의 인터페이스가 포함되어야 합니다.
- 템플릿 번역 속성 파일을 생성하도록 프로젝트를 구성해야 합니다.
국제화된 로거, 예외 또는 메시지 변환
다음 명령을 실행하여 템플릿 변환 속성 파일을 생성합니다.
mvn compile
$ mvn compileCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
생성된 디렉터리에서 프로젝트의
src/main/resources디렉터리로 변환하려는 인터페이스의 템플릿을 복사합니다. 속성 파일은 변환 중인 인터페이스와 동일한 패키지에 있어야 합니다. -
복사한 템플릿 파일의 이름을 변경하여 포함할 언어를 나타냅니다. 예를 들면 다음과 같습니다.
GreeterLogger.i18n_fr_FR.properties. 적절한 번역을 포함하도록 새로운 번역 속성 파일의 내용을 편집합니다.
# Level: Logger.Level.INFO # Message: Hello message sent. logHelloMessageSent=Bonjour message envoyé.
# Level: Logger.Level.INFO # Message: Hello message sent. logHelloMessageSent=Bonjour message envoyé.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 템플릿을 복사하고 번들의 각 변환에 대해 수정하는 과정을 반복합니다.
이제 프로젝트에는 하나 이상의 메시지 또는 로거 번들에 대한 변환이 포함됩니다. 프로젝트를 구축하면 제공된 번역이 포함된 메시지를 로깅하는 적절한 클래스가 생성됩니다. 특정 언어의 메서드 또는 매개 변수를 명시적으로 호출할 필요는 없으며, JBoss Logging Tools는 애플리케이션 서버의 현재 로케일에 대해 올바른 클래스를 자동으로 사용합니다.
생성된 클래스의 소스 코드는 target/generated-sources/annotations/ 에서 볼 수 있습니다.
4.5.5. 국제화된 로그 메시지 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
4.5.5.1. 로그 메시지에 메시지 ID 및 프로젝트 코드 추가 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 JBoss Logging Tools를 사용하여 생성된 국제화된 로그 메시지에 메시지 ID 및 프로젝트 코드를 추가하는 방법을 설명합니다. 로그 메시지에는 로그에 표시할 프로젝트 코드와 메시지 ID가 모두 있어야 합니다. 메시지에 프로젝트 코드와 메시지 ID가 모두 없는 경우 둘 다 표시되지 않습니다.
사전 요구 사항
- 국제화된 로그 메시지가 있는 프로젝트가 이미 있어야 합니다. 자세한 내용은 국제화된 로그 메시지 생성을 참조하십시오.
- 사용할 프로젝트 코드를 알아야 합니다. 단일 프로젝트 코드를 사용하거나 각 인터페이스에 대해 다른 코드를 정의할 수 있습니다.
로그 메시지에 메시지 ID 및 프로젝트 코드 추가
사용자 지정 로거 인터페이스에 연결된
@MessageLogger주석의 projectCode 특성을 사용하여 인터페이스에 대한 프로젝트 코드를 지정합니다. 인터페이스에서 정의된 모든 메시지는 해당 프로젝트 코드를 사용합니다.@MessageLogger(projectCode="ACCNTS") interface AccountsLogger extends BasicLogger { }@MessageLogger(projectCode="ACCNTS") interface AccountsLogger extends BasicLogger { }Copy to Clipboard Copied! Toggle word wrap Toggle overflow 메시지를 정의하는 메서드에 연결된
@Message주석의id특성을 사용하여 각 메시지의 메시지 ID를 지정합니다.@LogMessage @Message(id=43, value = "Customer query failed, Database not available.") void customerQueryFailDBClosed();
@LogMessage @Message(id=43, value = "Customer query failed, Database not available.") void customerQueryFailDBClosed();Copy to Clipboard Copied! Toggle word wrap Toggle overflow 메시지 ID와 프로젝트 코드가 연결된 로그 메시지 앞에는 로그 메시지가 기록된 메시지 앞에 추가됩니다.
10:55:50,638 INFO [com.company.accounts.ejb] (MSC service thread 1-4) ACCNTS000043: Customer query failed, Database not available.
10:55:50,638 INFO [com.company.accounts.ejb] (MSC service thread 1-4) ACCNTS000043: Customer query failed, Database not available.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.5.2. 메시지의 로그 수준을 지정합니다 링크 복사링크가 클립보드에 복사되었습니다!
JBoss Logging Tools의 인터페이스에서 정의한 메시지의 기본 로그 수준은 INFO(정보) 입니다. 로깅 메서드에 연결된 @LogMessage 주석의 level 특성을 사용하여 다른 로그 수준을 지정할 수 있습니다. 다음 절차에 따라 다른 로그 수준을 지정합니다.
-
로그 메시지 메서드 정의의
@LogMessage주석에level속성을 추가합니다. 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();
import org.jboss.logging.Logger.Level; @LogMessage(level=Level.ERROR) @Message(value = "Customer query failed, Database not available.") void customerQueryFailDBClosed();Copy to Clipboard Copied! Toggle word wrap Toggle overflow
위 예제에서 로깅 메서드를 호출하면 ERROR (오류) 수준에서 로그 메시지가 생성됩니다.
10:55:50,638 ERROR [com.company.app.Main] (MSC service thread 1-4) Customer query failed, Database not available.
10:55:50,638 ERROR [com.company.app.Main] (MSC service thread 1-4)
Customer query failed, Database not available.
4.5.5.3. 매개 변수를 사용하여 로그 메시지 사용자 지정 링크 복사링크가 클립보드에 복사되었습니다!
사용자 지정 로깅 방법은 매개 변수를 정의할 수 있습니다. 이러한 매개 변수는 로그 메시지에 표시할 추가 정보를 전달하는 데 사용됩니다. 로그 메시지에 매개 변수가 표시되는 위치는 명시적 또는 일반 인덱싱을 사용하여 메시지 자체에 지정됩니다.
매개 변수를 사용하여 로그 메시지 사용자 지정
- 모든 유형의 매개 변수를 메서드 정의에 추가합니다. 유형에 관계없이 매개 변수의 String 표시는 메시지에 표시됩니다.
로그 메시지에 매개 변수 참조를 추가합니다. 참조는 명시적 또는 일반 인덱스를 사용할 수 있습니다.
-
일반 인덱스를 사용하려면 각 매개 변수를 표시하려는 메시지 문자열에
%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);
@LogMessage(level=Logger.Level.DEBUG)
@Message(id=2, value="Customer query failed, customerid:%s, user:%s")
void customerLookupFailed(Long customerid, String username);
다음은 명시적 인덱스를 사용하는 메시지 매개변수의 예입니다.
@LogMessage(level=Logger.Level.DEBUG) @Message(id=2, value="Customer query failed, user:%2$s, customerid:%1$s") void customerLookupFailed(Long customerid, String username);
@LogMessage(level=Logger.Level.DEBUG)
@Message(id=2, value="Customer query failed, user:%2$s, customerid:%1$s")
void customerLookupFailed(Long customerid, String username);
4.5.5.4. 로그 메시지의 원인으로 예외를 지정합니다. 링크 복사링크가 클립보드에 복사되었습니다!
JBoss Logging Tools를 사용하면 메시지의 원인으로 사용자 지정 로깅 방법 매개 변수를 하나 정의할 수 있습니다. 이 매개 변수는 Throwable 유형 또는 하위 클래스 중 하나여야 하며 @cause 주석으로 표시됩니다. 이 매개변수는 다른 매개변수와 마찬가지로 로그 메시지에서 참조할 수 없으며 로그 메시지 뒤에 표시됩니다.
다음 절차에서는 @ causes 매개 변수를 사용하여 "causing" 예외를 나타내는 로깅 방법을 업데이트하는 방법을 보여줍니다. 이 기능을 추가하려는 국제화된 로깅 메시지가 이미 생성되었다고 가정합니다.
로그 메시지의 원인으로 예외를 지정합니다.
Throwable또는 하위 클래스 유형의 매개 변수를 메서드에 추가합니다.@LogMessage @Message(id=404, value="Loading configuration failed. Config file:%s") void loadConfigFailed(Exception ex, File file);
@LogMessage @Message(id=404, value="Loading configuration failed. Config file:%s") void loadConfigFailed(Exception ex, File file);Copy to Clipboard Copied! Toggle word wrap Toggle overflow @ causes 주석을매개 변수에 추가합니다.import org.jboss.logging.annotations.Cause @LogMessage @Message(value = "Loading configuration failed. Config file: %s") void loadConfigFailed(@Cause Exception ex, File file);
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 Copied! Toggle word wrap Toggle overflow 메서드를 호출합니다. 코드에서 메서드를 호출하면 올바른 유형의 오브젝트를 전달해야 하며 로그 메시지 뒤에 표시됩니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음은 코드에서 유형 FileNotFoundException 을 제외하고 발생하는 경우 위 코드 예제의 출력입니다.
4.5.6. 국제화된 예외 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
4.5.6.1. 예외 메시지에 메시지 ID 및 프로젝트 코드 추가 링크 복사링크가 클립보드에 복사되었습니다!
메시지 ID와 프로젝트 코드는 국제화된 예외에 의해 표시되는 각 메시지 앞에 오는 고유한 식별자입니다. 이러한 식별 코드를 통해 애플리케이션의 모든 예외 메시지에 대한 참조를 생성할 수 있습니다. 이를 통해 사람이 이해할 수 없는 언어로 작성된 예외 메시지의 의미를 조회할 수 있습니다.
다음 절차에서는 JBoss Logging Tools를 사용하여 생성된 국제화된 예외 메시지에 메시지 ID 및 프로젝트 코드를 추가하는 방법을 설명합니다.
사전 요구 사항
- 국제화된 예외가 있는 프로젝트가 이미 있어야 합니다. 자세한 내용은 Create Internationalized Exceptions를 참조하십시오.
- 사용할 프로젝트 코드를 알아야 합니다. 단일 프로젝트 코드를 사용하거나 각 인터페이스에 대해 다른 코드를 정의할 수 있습니다.
예외 메시지에 메시지 ID 및 프로젝트 코드 추가
예외 번들 인터페이스에 연결된
@MessageBundle주석의projectCode특성을 사용하여 프로젝트 코드를 지정합니다. 인터페이스에서 정의된 모든 메시지는 해당 프로젝트 코드를 사용합니다.@MessageBundle(projectCode="ACCTS") interface ExceptionBundle { ExceptionBundle EXCEPTIONS = Messages.getBundle(ExceptionBundle.class); }@MessageBundle(projectCode="ACCTS") interface ExceptionBundle { ExceptionBundle EXCEPTIONS = Messages.getBundle(ExceptionBundle.class); }Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예외를 정의하는 메서드에 연결된
@Message주석의id특성을 사용하여 각 예외에 대해 메시지 ID를 지정합니다.@Message(id=143, value = "The config file could not be opened.") IOException configFileAccessError();
@Message(id=143, value = "The config file could not be opened.") IOException configFileAccessError();Copy to Clipboard Copied! Toggle word wrap Toggle overflow
프로젝트 코드와 메시지 ID가 모두 있는 메시지는 메시지 앞에 표시됩니다. 메시지에 프로젝트 코드와 메시지 ID가 모두 없는 경우 둘 다 표시됩니다.
예제: 국제화 예외
이 예외 번들 인터페이스 예제에서는 "ACCTS"의 프로젝트 코드를 사용합니다. ID가 "143"인 단일 예외 메서드가 포함됩니다.
다음 코드를 사용하여 예외 오브젝트를 가져오고 throw할 수 있습니다.
throw ExceptionBundle.EXCEPTIONS.configFileAccessError();
throw ExceptionBundle.EXCEPTIONS.configFileAccessError();
다음과 같은 예외 메시지가 표시됩니다.
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)
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)
4.5.6.2. 매개 변수를 사용하여 예외 메시지 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
예외 번들 메서드는 예외 메시지에 표시할 추가 정보를 전달하도록 매개 변수를 지정할 수 있습니다. 예외 메시지에서 매개 변수의 정확한 위치는 명시적 또는 일반 색인을 사용하여 메시지 자체에 지정됩니다.
매개 변수를 사용하여 예외 메시지 사용자 정의
- 모든 유형의 매개 변수를 메서드 정의에 추가합니다. 유형에 관계없이 매개 변수의 String 표시는 메시지에 표시됩니다.
매개 변수 참조를 예외 메시지에 추가합니다. 참조는 명시적 또는 일반 인덱스를 사용할 수 있습니다.
-
일반 인덱스를 사용하려면 각 매개 변수를 표시하려는 메시지 문자열에
%s문자를 삽입합니다.%s의 첫 번째 인스턴스는 첫 번째 매개 변수를 삽입하고, 두 번째 인스턴스는 두 번째 매개 변수를 삽입합니다. -
명시적 인덱스를 사용하려면 메시지에
%#$s문자를 삽입합니다. 여기서 #은 표시하려는 매개 변수 수를 나타냅니다.
-
일반 인덱스를 사용하려면 각 매개 변수를 표시하려는 메시지 문자열에
명시적 인덱스를 사용하면 메시지의 매개 변수 참조가 메서드에 정의된 것과 다른 순서로 표시됩니다. 매개 변수 순서가 다를 수 있는 번역 메시지에는 중요합니다.
매개 변수 수는 지정된 메시지의 매개 변수에 대한 참조 수와 일치해야 합니다. 그렇지 않으면 코드가 컴파일되지 않습니다. @ cause 주석 으로 표시된 매개 변수는 매개변수 수에 포함되지 않습니다.
예제: 일반 인덱스 사용
@Message(id=2, value="Customer query failed, customerid:%s, user:%s") void customerLookupFailed(Long customerid, String username);
@Message(id=2, value="Customer query failed, customerid:%s, user:%s")
void customerLookupFailed(Long customerid, String username);
예제: 명시적 색인 사용
@Message(id=2, value="Customer query failed, user:%2$s, customerid:%1$s") void customerLookupFailed(Long customerid, String username);
@Message(id=2, value="Customer query failed, user:%2$s, customerid:%1$s")
void customerLookupFailed(Long customerid, String username);
4.5.6.3. 다른 예외의 원인으로 One Exception을 지정합니다. 링크 복사링크가 클립보드에 복사되었습니다!
예외 번들 메서드에서 반환된 예외는 기본 원인으로 지정된 또 다른 예외를 가질 수 있습니다. 이 작업은 메서드에 매개 변수를 추가하고 @cause를 사용하여 매개 변수에 주석을 달아 수행됩니다. 이 매개변수는 원인 예외를 전달하는 데 사용되며 예외 메시지에서는 참조할 수 없습니다.
다음 절차에서는 원인인 예외를 나타내도록 @ causes 매개변수를 사용하여 예외 번들에서 메서드를 업데이트하는 방법을 보여줍니다. 이 기능을 추가하려는 예외 번들이 이미 생성되었다고 가정합니다.
Throwable또는 하위 클래스 유형의 매개 변수를 메서드에 추가합니다.@Message(id=328, value = "Error calculating: %s.") ArithmeticException calculationError(Throwable cause, String msg);
@Message(id=328, value = "Error calculating: %s.") ArithmeticException calculationError(Throwable cause, String msg);Copy to Clipboard Copied! Toggle word wrap Toggle overflow @ causes 주석을매개 변수에 추가합니다.import org.jboss.logging.annotations.Cause @Message(id=328, value = "Error calculating: %s.") ArithmeticException calculationError(@Cause Throwable cause, String msg);
import org.jboss.logging.annotations.Cause @Message(id=328, value = "Error calculating: %s.") ArithmeticException calculationError(@Cause Throwable cause, String msg);Copy to Clipboard Copied! Toggle word wrap Toggle overflow interface 메서드를 호출하여 예외 오브젝트를 가져옵니다. 가장 일반적인 사용 사례는 캡처된 예외를 원인으로 지정하여
캐치블록에서 새로운 예외를 생성하는 것입니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음은 다른 예외의 원인으로 예외를 지정하는 예입니다. 이 예외 번들은 typeth meticException 의 예외를 반환하는 단일 메서드를 정의합니다.
다음 예제에서는 정수를 0으로 분할하려고 하므로 예외가 발생하는 작업을 보여줍니다. 예외가 해결되고 첫 번째 예외를 원인으로 사용하여 새로운 예외가 생성됩니다.
다음은 이전 예제에서 생성된 예외 메시지입니다.
4.5.7. JBoss Logging Tools 참조 링크 복사링크가 클립보드에 복사되었습니다!
4.5.7.1. JBoss Logging Tools Maven 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 국제화를 위해 JBoss Logging 및 JBoss Logging Tools를 사용하도록 Maven 프로젝트를 구성합니다.
아직 완료하지 않은 경우 JBoss EAP 리포지토리를 사용하도록 Maven 설정을 구성합니다. 자세한 내용은 Configure the JBoss EAP Maven Repository using the Maven Settings 에서 참조하십시오.
프로젝트의
pom.xml파일의<dependencyManagement>섹션에jboss-eap-jakartaee8BOM을 포함합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 프로젝트의
pom.xml 파일에 Maven 종속성을 추가합니다.-
JBoss Logging 프레임워크에 액세스하려면
jboss-logging종속성을 추가합니다. JBoss Logging Tools를 사용하려는 경우
jboss-logging-processor종속성도 추가합니다.이러한 종속성은 이전 단계에서 추가한 JBoss EAP BOM에서 사용 가능하므로 각각의 범위 요소를 표시된 대로
provided로 설정할 수 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
JBoss Logging 프레임워크에 액세스하려면
maven-compiler-plugin은 버전
3.1이상이어야 하며1.8의 대상 및 생성된 소스에 맞게 구성해야 합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
InterfaceName.i18n_locale_COUNTRY_VARIANT.properties
-
interfacename은 변환이 적용되는 인터페이스의 이름입니다. -
로케일,COUNTRY및VARIANT는 변환이 적용되는 지역 설정을 식별합니다. -
로케일및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é.
# Level: Logger.Level.INFO
# Message: Hello message sent.
logHelloMessageSent=Bonjour message envoyé.
4.5.7.3. JBoss Logging Tools 주석 참조 링크 복사링크가 클립보드에 복사되었습니다!
다음 주석은 로그 메시지, 문자열 및 예외의 국제화 및 현지화와 함께 사용할 수 있도록 JBoss Logging에 정의됩니다.
| 주석 | 대상 | 설명 | 속성 |
|---|---|---|---|
| @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 모듈이 나열되어 있습니다.
| 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에서 큐 구성
5.2. 원격 JNDI 구성 링크 복사링크가 클립보드에 복사되었습니다!
원격 JNDI 클라이언트는 JNDI에서 이름으로 개체를 연결하고 조회할 수 있습니다. 원격 JNDI 클라이언트를 사용하여 개체를 찾으려면 클래스 경로에 jboss-client.jar 가 있어야 합니다. jboss-client.jar 는 EAP_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");
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");
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>
<dependency>
<groupId>org.wildfly.wildfly-http-client</groupId>
<artifactId>wildfly-http-naming-client</artifactId>
</dependency>
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")
/subsystem=undertow/server=default-server/host=default-host/setting=http-invoker:add(http-authentication-factory=myfactory, path="/wildfly-services")
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(고가용성) 기능을 활용하고 웹 애플리케이션의 클러스터링을 활성화하려면 애플리케이션을 배포 가능하도록 구성해야 합니다. 애플리케이션이 배포 가능으로 표시되지 않으면 해당 세션은 배포되지 않습니다.
애플리케이션 배포 가능
애플리케이션
web.xml 설명자 파일의<> 요소를 추가합니다.web-app> 태그 내에 <distributable/예제: 배포 가능한 애플리케이션의 최소 구성
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음으로 필요한 경우 기본 복제 동작을 수정합니다. 세션 복제에 영향을 미치는 값을 변경하려면 애플리케이션의
WEB-INF/jboss-web.xml 파일에서요소 내에서 이를 재정의할 수 있습니다. 지정된 요소에 대해 기본값을 재정의하려는 경우에만 포함합니다.<>jboss-web> 요소 내의 <replication-config예:
<replication-config>값Copy to Clipboard Copied! Toggle word wrap Toggle overflow
<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,기간,인스턴트,LocalDateTime,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를 구현하지 않는 세션에 오브젝트를 저장할 수 있도록 합니다. 해당 상태와 함께 오브젝트의 클래스 설명자를 직렬화할 필요가 없습니다.
예제
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
서비스 로더 메커니즘은 배포 중에 외부라이저를 동적으로 로드합니다. 구현 작업은 /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.xml 및 META-INF/jboss-web.xml 파일에 구성됩니다.
예: jboss-web.xml 파일
<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;
@Resource(lookup = "java:jboss/clustering/group/channel-name") private Group channelGroup;Copy to Clipboard Copied! Toggle word wrap Toggle overflow org.wildfly.clustering.dispatcher.CommandDispatchercommand
DispatcherFactory서비스는 클러스터의 노드에서 명령을 실행하기 위한 디스패처를 생성하는 메커니즘을 제공합니다. 결과CommandDispatcher는 이전 JBoss EAP 릴리스의 그림 기반GroupRpcDispatcher에 대한 명령-패턴 아날로그입니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 의 사용법을 보여줍니다.
HA Singleton 서비스 애플리케이션 생성
다음은 애플리케이션을 클러스터 전체 Singleton 서비스로 생성하고 배포하는 데 필요한 단계의 축약된 예입니다. 이 예제에서는 Singleton 서비스를 정기적으로 쿼리하여 실행 중인 노드의 이름을 가져오는 쿼리 서비스를 보여줍니다.
Singleton 동작을 보려면 애플리케이션을 두 개 이상의 서버에 배포해야 합니다. Singleton 서비스가 동일한 노드에서 실행 중인지 또는 값을 원격으로 가져올지 여부는 명확합니다.
SingletonService클래스를 만듭니다. 쿼리 서비스에서 호출하는getValue()메서드는 실행 중인 노드에 대한 정보를 제공합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 쿼리 서비스를 생성합니다. Singleton 서비스의
getValue()메서드를 호출하여 실행 중인 노드의 이름을 가져온 다음 결과를 서버 로그에 씁니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow SingletonServiceActivator클래스를 구현하여 Singleton 서비스와 쿼리 서비스를 모두 빌드하고 설치합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
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구성으로 Jakarta EE 8 Full Platform 프로파일을 지원합니다.-full.xml 구성을 지원하는standalone.xml -
domain.xml구성 - 기본 도메인 프로필 또는 전체 도메인 프로필로 구성됩니다.
-
Jakarta EE 8 Web Profile 또는
비 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-deploymentMETA-INF디렉터리의 최상위 레벨로 이동합니다.예제: Singleton 배포 설명자
<?xml version="1.0" encoding="UTF-8"?> <singleton-deployment xmlns="urn:jboss:singleton-deployment:1.0"/>
<?xml version="1.0" encoding="UTF-8"?> <singleton-deployment xmlns="urn:jboss:singleton-deployment:1.0"/>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 애플리케이션 배포를 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"/>
<?xml version="1.0" encoding="UTF-8"?> <singleton-deployment policy="my-new-policy" xmlns="urn:jboss:singleton-deployment:1.0"/>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항:
jboss을 정의하려면-all.xml 파일에서 singleton-deploymentjboss-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><?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 Copied! Toggle word wrap Toggle overflow 선택 사항: singleton 정책을 사용하여
jboss을 정의합니다.-all.xml 파일에서 singleton-deploymentjboss-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><?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 Copied! Toggle word wrap Toggle overflow
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
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-batchCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고새로 생성된 정책
my-new-policy를 기본값으로 설정하려면 다음 명령을 실행합니다./subsystem=singleton:write-attribute(name=default, value=my-new-policy)
/subsystem=singleton:write-attribute(name=default, value=my-new-policy)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예제:
standalone구성-ha.xml을 사용하여 위치가policy-1로 설정된 simple-election-Copy to Clipboard Copied! Toggle word wrap Toggle overflow 임의 선택 정책
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
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-batchCopy to Clipboard Copied! Toggle word wrap Toggle overflow 예제:
standalone구성-ha.xml을 사용하여 random-election-policyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고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)
/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)
예제: 관리 CLI를 사용하여 단순election-policy 및 를 사용하여 새 Singleton 정책 생성name- preferences
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
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
새로 생성된 정책 my-new-policy 를 기본값으로 설정하려면 다음 명령을 실행합니다.
/subsystem=singleton:write-attribute(name=default, value=my-new-policy)
/subsystem=singleton:write-attribute(name=default, value=my-new-policy)
예제: standalone 구성-ha.xml을 사용하여 election-policysocket-binding-preferences 를 사용하여 random-
쿼럼 정의
네트워크 파티션은 동일한 배포에 대해 여러 Singleton 프로바이더를 트리거하여 동시에 실행될 수 있으므로 Singleton 배포에 특히 문제가 있습니다. 이 시나리오에 대해 보호하기 위해 Singleton 정책은 Singleton 공급자 선택을 수행하기 전에 최소 노드 수가 있어야 하는 쿼럼을 정의할 수 있습니다. 일반적인 배포 시나리오에서는 N/2 + 1의 쿼럼을 사용합니다. 여기서 N은 예상되는 클러스터 크기입니다. 이 값은 런타임 시 업데이트할 수 있으며 해당 Singleton 정책을 사용하여 Singleton 배포에 즉시 영향을 미칩니다.
예제: standalone-ha.xml 파일의 쿼럼 선언
예제: 관리 CLI를 사용한 쿼럼 선언
/subsystem=singleton/singleton-policy=foo:write-attribute(name=quorum, value=3)
/subsystem=singleton/singleton-policy=foo:write-attribute(name=quorum, value=3)
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"
}
/subsystem=singleton/singleton-policy=default/deployment=singleton.jar:read-attribute(name=primary-provider)
{
"outcome" => "success",
"result" => "node1"
}
Singleton 배포 또는 서비스가 설치된 노드의 이름을 볼 수도 있습니다. 예를 들면 다음과 같습니다.
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 관리 웹 페이지
- [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.
-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 Copied! Toggle word wrap Toggle overflow
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"
}
[standalone@embedded /] /subsystem=distributable-web:read-attribute(name=default-session-management)
{
"outcome" => "success",
"result" => "default"
}
기본 세션 관리는 다음 예제와 같이 Infinispan 캐시 내에 웹 세션 데이터를 저장합니다.
이 예제에서 사용되는 속성과 가능한 값은 다음과 같습니다.
-
캐시: 연결된 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"
}
[standalone@embedded /]/subsystem=distributable-web/hotrod-session-management=ExampleRemoteSessionStore:add(remote-cache-container=datagrid, cache-configuration=__REMOTE_CACHE_CONFIG_NAME__, granularity=ATTRIBUTE)
{
"outcome" => "success"
}
이 예제에서 사용되는 속성과 가능한 값은 다음과 같습니다.
-
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의 양을 줄입니다.
- 컨텍스트를 통해 라이프사이클 관리 제공. 요청, 세션, 대화 또는 사용자 지정 컨텍스트에 삽입을 연결할 수 있습니다.
- 안전한 타입 종속성 주입을 제공하여 문자열 기반 주입보다 더 안전하고 디버깅하기 쉽습니다.
- 빈에서 인터셉터 분리.
- 복잡한 이벤트 알림 제공.
7.2. 자카르타 컨텍스트 및 종속성 주입을 사용하여 애플리케이션 개발 링크 복사링크가 클립보드에 복사되었습니다!
Jakarta Contexts and Dependency Injection을 사용하면 애플리케이션 개발, 코드 재사용, 배포 또는 런타임 시 코드 조정, 장치 테스트 등의 상당한 유연성을 확보할 수 있습니다.
애플리케이션 개발을 위한 특수 모드가 함께 제공됩니다. 활성화된 경우 Jakarta Contexts 및 Dependency Injection 애플리케이션의 개발을 용이하게 하는 특정 기본 제공 툴을 사용할 수 있습니다.
개발 모드는 애플리케이션 성능에 부정적인 영향을 줄 수 있으므로 프로덕션에서 사용해서는 안 됩니다. 프로덕션에 배포하기 전에 개발 모드를 비활성화해야 합니다.
웹 애플리케이션의 개발 모드 활성화:
웹 애플리케이션의 경우 서블릿 초기화 매개 변수 org.jboss.firmd.development 를 true로 설정합니다.
관리 CLI를 사용하여 JBoss EAP에 대한 개발 모드 활성화:
development -mode 특성을 모드를 전역적으로 활성화할 수 있습니다.
true 로 설정하여 배포된 모든 애플리케이션에 대해 Weld 개발
/subsystem=weld:write-attribute(name=development-mode,value=true)
/subsystem=weld:write-attribute(name=development-mode,value=true)
7.2.1. 기본 빈 검색 모드 링크 복사링크가 클립보드에 복사되었습니다!
빈 아카이브의 기본 빈 검색 모드는 주석이 추가됩니다. 이러한 빈 아카이브는 암시적 빈 아카이브 라고 합니다.
빈 검색 모드에 주석이 추가되면 다음을 수행합니다.
-
주석 정의가 없고 세션 빈의 빈 클래스가 아닌 빈 클래스는 검색되지 않습니다. - 세션 빈에 없고 빈 클래스에 빈 정의 주석이 없는 생산자 메서드는 검색되지 않습니다.
- 세션 빈에 없고 빈 클래스에 빈 정의 주석이 없는 생산자 필드가 검색되지 않습니다.
- 세션 빈에 없고 빈 클래스에 빈 정의 주석이 없는 Disposer 메서드는 검색되지 않습니다.
- 세션 빈에 없고 빈 클래스에 빈 정의 주석이 없는 관찰자 메서드는 검색되지 않습니다.
Contexts 및 Dependency Injection 섹션의 모든 예제는 검색 모드가 all 으로 설정된 경우에만 유효합니다.
주석 정의 빈
빈 클래스에는 빈을 정의하여 빈 아카이브에 정의된 대로 애플리케이션의 모든 위치에 배치할 수 있습니다. 주석을 정의하는 빈 클래스는 암시적 빈 빈이라고 합니다.
주석을 정의하는 빈 세트에는 다음이 포함됩니다.
-
@ApplicationScoped,@SessionScoped,@ConversationScoped및@RequestScoped주석. - 기타 모든 일반 범위 유형.
-
@interceptor및@Decorator주석. -
모든 주석, 즉
@Stereotype으로 주석이 달립니다. -
@Dependent범위 주석입니다.
이러한 주석 중 하나가 빈 클래스에 선언되면 빈 클래스에 빈이 주석이 있다고 합니다.
예제: 빈에서 주석 정의
다른 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 파일
- 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 클래스에 정상적인 빈을 주입합니다.
7.3. 모호하거나 불만족스러운 종속성 링크 복사링크가 클립보드에 복사되었습니다!
모호한 종속성은 컨테이너가 정확히 하나의 빈에 주입을 확인할 수 없는 경우 존재합니다.
컨테이너에서 빈에 대한 주입을 확인할 수 없는 경우 불만족한 종속성이 있습니다.
컨테이너는 종속성을 해결하기 위해 다음 단계를 수행합니다.
- 주입 지점의 빈 유형을 구현하는 모든 빈의 한정자 주석을 확인합니다.
-
비활성화된 빈을 필터링합니다. 비활성화된 빈은 명시적으로 활성화되지 않은
@Alternative빈입니다.
모호한 종속성 또는 불만족스러운 종속성이 있는 경우 컨테이너는 배포를 중단하고 예외가 발생합니다.
모호한 종속성을 수정하려면 Qualifier를 사용하여 모호한 주입 해결을 참조하십시오.
7.3.1. 한정자 링크 복사링크가 클립보드에 복사되었습니다!
한정자는 컨테이너가 주입 지점에 맞는 여러 빈을 확인할 수 있는 경우 모호한 종속성을 방지하는 데 사용되는 주석입니다. 주입 지점에 선언된 한정자는 동일한 한정자를 선언하는 적격 빈 세트를 제공합니다.
한정자는 아래 예와 같이 보존 및 대상을 사용하여 선언해야 합니다.
예제: @Synchronous 및 @ Asynchronous 한정자를 정의합니다.
@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface Synchronous {}
@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface Synchronous {}
@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface Asynchronous {}
@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface Asynchronous {}
예제: @Synchronous 및 @Asynchronous 한정자 사용
@Synchronous
public class SynchronousPaymentProcessor implements PaymentProcessor {
public void process(Payment payment) { ... }
}
@Synchronous
public class SynchronousPaymentProcessor implements PaymentProcessor {
public void process(Payment payment) { ... }
}
@Asynchronous
public class AsynchronousPaymentProcessor implements PaymentProcessor {
public void process(Payment payment) { ... }
}
@Asynchronous
public class AsynchronousPaymentProcessor implements PaymentProcessor {
public void process(Payment payment) { ... }
}
'@Any'
빈 또는 주입 지점에서 한정자를 명시적으로 선언하지 않을 때마다 컨테이너에서 한정자 @Default 를 가정합니다. 한정자를 지정하지 않고 주입 지점을 선언해야 하는 경우도 있습니다. 이에 대한 한정자가 있습니다. 모든 빈에는 한정자 @Any 가 있습니다. 따라서 주입 지점에 @Any 를 명시적으로 지정하여 주입할 수 있는 빈을 제한하지 않고 기본 한정자를 억제합니다.
이 기능은 특정 빈 유형의 모든 빈을 반복하려는 경우 특히 유용합니다.
모든 빈에는 이 한정자를 명시적으로 선언하지 않더라도 한정자 @Any 가 있습니다.
또한 모든 이벤트에는 이 한정자를 명시적으로 선언하지 않고 제기된 한정자 @Any 가 있습니다.
@Inject @Any Event<User> anyUserEvent;
@Inject @Any Event<User> anyUserEvent;
@Any 한정자를 사용하면 주입 지점에서 모든 빈 또는 특정 빈 유형의 모든 이벤트를 참조할 수 있습니다.
@Inject @Delegate @Any Logger logger;
@Inject @Delegate @Any Logger logger;
7.3.2. 한정자를 사용하여 모호한 주입 해결 링크 복사링크가 클립보드에 복사되었습니다!
한정자를 사용하여 모호한 주입을 해결할 수 있습니다. 모호한 또는 불만족스러운 종속성에서 모호한 주입에 대해 자세히 알아보십시오.
다음 예제는 모호한 예이며 두 개의 Welcome 구현이 있습니다. 하나는 변환되고 그렇지 않은 것입니다. Welcome(환영)을 사용하려면 삽입을 지정해야 합니다.
예제: 모호한 주입
한정자를 사용하여 모호한 주입 해결
모호한 주입을 해결하려면
@Translating:@Qualifier @Retention(RUNTIME) @Target({TYPE,METHOD,FIELD,PARAMETERS}) public @interface Translating{}@Qualifier @Retention(RUNTIME) @Target({TYPE,METHOD,FIELD,PARAMETERS}) public @interface Translating{}Copy to Clipboard Copied! Toggle word wrap Toggle overflow @Translating주석을 사용하여 TranslationWelcome에 주석을 답니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 삽입에
환영을요청하십시오. 팩토리 방법 패턴과 유사하게 정규화된 구현을 명시적으로 요청해야 합니다. 주입 지점에서 모호성이 해결됩니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 {
...
}
@Vetoed
public class SimpleGreeting implements Greeting {
...
}
이 코드에서 SimpleGreeting 빈은 주입을 위해 고려되지 않습니다.
패키지의 모든 빈은 주입되지 않도록 할 수 있습니다.
@Vetoed package org.sample.beans; import javax.enterprise.inject.Vetoed;
@Vetoed
package org.sample.beans;
import javax.enterprise.inject.Vetoed;
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 공급자가 중단될 수 있는 작업을 수행하지 못하도록 하기 때문입니다.
7.4.2. 컨텍스트 및 종속성 주입을 사용하여 객체 삽입을 빈에 주입합니다. 링크 복사링크가 클립보드에 복사되었습니다!
애플리케이션에서 컨텍스트 및 종속성 주입 구성 요소가 탐지되면 컨텍스트 및 종속성 주입 구성 요소가 자동으로 활성화됩니다. 구성을 기본값과 다르게 사용자 지정하려면 배포 아카이브에 META-INF/beans.xml 파일 또는 WEB-INF/beans.xml 파일을 포함할 수 있습니다.
다른 오브젝트에 오브젝트 삽입
클래스 인스턴스를 가져오려면 빈 내에서
@Inject로 필드에 주석을 추가합니다.public class TranslateController { @Inject TextTranslator textTranslator; ...public class TranslateController { @Inject TextTranslator textTranslator; ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 삽입된 오브젝트의 메서드를 직접 사용합니다.
TextTranslator에변환방법이 있다고 가정합니다.// in TranslateController class public void translate() { translation = textTranslator.translate(inputText); }// in TranslateController class public void translate() { translation = textTranslator.translate(inputText); }Copy to Clipboard Copied! Toggle word wrap Toggle overflow 빈 생성자에 주입을 사용합니다. 다음과 같이 팩토리 또는 서비스 검색 도구를 사용하는 대신 빈 생성자에 오브젝트를 삽입하여 생성할 수 있습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Instance(<T>)인터페이스를 사용하여 프로그래밍 방식으로 인스턴스를 가져옵니다. 빈 유형으로 매개 변수를 지정하면인스턴스인터페이스에서TextTranslator의 인스턴스를 반환할 수 있습니다.@Inject Instance<TextTranslator> textTranslatorInstance; ... public void translate() { textTranslatorInstance.get().translate(inputText); }@Inject Instance<TextTranslator> textTranslatorInstance; ... public void translate() { textTranslatorInstance.get().translate(inputText); }Copy to Clipboard Copied! Toggle word wrap Toggle overflow
빈에 오브젝트를 삽입하면 빈에서 모든 오브젝트 메서드 및 속성을 사용할 수 있습니다. 주입이 이미 존재하는 인스턴스를 참조하지 않는 한 빈의 생성자에 주입하는 경우 빈의 생성자를 호출할 때 주입된 오브젝트의 인스턴스가 생성됩니다. 예를 들어 세션 수명 동안 세션 범위 빈을 삽입하면 새 인스턴스가 생성되지 않습니다.
7.5. 컨텍스트 및 범위 링크 복사링크가 클립보드에 복사되었습니다!
컨텍스트(Contexts and Dependency Injection)는 특정 범위와 연결된 빈 인스턴스를 보유하는 스토리지 영역입니다.
범위는 빈과 컨텍스트 간의 링크입니다. 범위/컨텍스트 조합은 특정 라이프사이클을 가질 수 있습니다. 몇 가지 사전 정의된 범위가 존재하며 고유한 범위를 만들 수 있습니다. 미리 정의된 범위의 예로는 @RequestScoped,@SessionScoped, @ConversationScope 가 있습니다.
| 범위 | 설명 |
|---|---|
|
|
빈은 참조를 포함하는 빈의 라이프사이클에 바인딩됩니다. 주입된 빈의 기본 범위는 |
|
| 빈은 애플리케이션의 라이프사이클에 바인딩됩니다. |
|
| 빈은 요청의 라이프사이클에 바인딩됩니다. |
|
| 빈은 세션의 라이프사이클에 바인딩됩니다. |
|
| 빈은 대화의 라이프사이클에 바인딩됩니다. 대화 범위는 요청과 세션 길이 사이의이며 애플리케이션에 의해 제어됩니다. |
| 사용자 지정 범위 | 위의 컨텍스트가 요구 사항을 충족하지 않으면 사용자 지정 범위를 정의할 수 있습니다. |
7.6. 명명된 빈 링크 복사링크가 클립보드에 복사되었습니다!
@Named 주석을 사용하여 빈의 이름을 지정할 수 있습니다. 빈을 지정하면 Jakarta Server Faces 및 Jakarta Expression Language에서 직접 사용할 수 있습니다.
@Named 주석은 빈 이름인 선택적 매개 변수를 사용합니다. 이 매개 변수가 생략된 경우 빈 이름은 기본적으로 빈의 클래스 이름으로, 첫 번째 문자가 소문자로 변환됩니다.
7.6.1. 이름이 지정된 빈 사용 링크 복사링크가 클립보드에 복사되었습니다!
@Named 주석을 사용하여 빈 이름 구성
@Named주석을 사용하여 빈에 이름을 할당합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 위의 예에서 이름이 지정되지 않은 경우 기본 이름은 be
greeterBean입니다.Jakarta Server Faces 뷰에서 명명된 빈을 사용합니다.
<h:form> <h:commandButton value="Welcome visitors" action="#{greeter.welcomeVisitors}"/> </h:form><h:form> <h:commandButton value="Welcome visitors" action="#{greeter.welcomeVisitors}"/> </h:form>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.7. 빈 라이프 사이클 링크 복사링크가 클립보드에 복사되었습니다!
이 작업은 요청 수명 동안 빈을 저장하는 방법을 보여줍니다.
주입된 빈의 기본 범위는 @Dependent 입니다. 즉, 빈의 라이프사이클은 참조가 포함된 빈의 라이프사이클에 따라 달라집니다. 다른 여러 범위가 존재하며 고유한 범위를 정의할 수 있습니다. 자세한 내용은 컨텍스트 및 범위를 참조하십시오.
빈 라이프사이클 관리
빈에 원하는 범위를 주석을 답니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 빈은 Jakarta Server Faces 뷰에서 사용될 때 상태를 유지합니다.
<h:form> <h:inputText value="#{greeter.city}"/> <h:commandButton value="Welcome visitors" action="#{greeter.welcomeVisitors}"/> </h:form><h:form> <h:inputText value="#{greeter.city}"/> <h:commandButton value="Welcome visitors" action="#{greeter.welcomeVisitors}"/> </h:form>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
빈은 지정한 범위와 관련된 컨텍스트에 저장되며 범위가 적용되는 한 지속됩니다.
7.7.1. 생산자 방법 사용 링크 복사링크가 클립보드에 복사되었습니다!
생산자 메서드 는 빈 인스턴스의 소스 역할을 하는 메서드입니다. 지정된 컨텍스트에 인스턴스가 없으면 메서드 선언 자체에서 빈을 설명하고 컨테이너에서 메서드를 호출하여 빈의 인스턴스를 가져옵니다. 생산자 메서드를 사용하면 애플리케이션에서 빈 인스턴스화 프로세스를 완전히 제어할 수 있습니다.
이 섹션에서는 생산자 메서드를 사용하여 주입을 위해 빈이 아닌 다양한 오브젝트를 생성하는 방법을 보여줍니다.
예제: 생산자 방법 사용
대체 대신 생산자 방법을 사용하면 배포 후 다형성이 허용됩니다.
예제의 @Preferred 주석은 한정자 주석입니다. 한정자에 대한 자세한 내용은 한정자를 참조하십시오.
다음 주입 지점에는 생산자 메서드와 동일한 유형 및 한정자 주석이 있으므로 일반적인 Contexts 및 Dependency Injection 주입 규칙을 사용하여 생산자 메서드로 확인됩니다. 생산자 메서드는 컨테이너에서 호출하여 이 주입 지점에 서비스를 제공할 인스턴스를 가져옵니다.
@Inject @Preferred PaymentStrategy paymentStrategy;
@Inject @Preferred PaymentStrategy paymentStrategy;
예제: 생산자 메서드에 범위 할당
생산자 메서드의 기본 범위는 @Dependent 입니다. 빈에 범위를 할당하면 적절한 컨텍스트에 바인딩됩니다. 이 예제의 제작자 메서드는 세션당 한 번만 호출됩니다.
@Produces @Preferred @SessionScoped
public PaymentStrategy getPaymentStrategy() {
...
}
@Produces @Preferred @SessionScoped
public PaymentStrategy getPaymentStrategy() {
...
}
예제: 생산자 방법 내에서 주입 사용
애플리케이션에서 직접 인스턴스화된 오브젝트는 종속성 주입을 활용할 수 없으며 인터셉터가 없습니다. 그러나 생산자 메서드에 종속성 주입을 사용하여 빈 인스턴스를 가져올 수 있습니다.
요청 범위 빈을 세션 범위 생산자에 삽입하는 경우 제작자 메서드는 현재 요청 범위 인스턴스를 세션 범위로 승격합니다. 이 방법은 바람직한 동작이 아니므로 이러한 방식으로 생산자 메서드를 사용할 때는 주의해야 합니다.
생산자 메서드의 범위는 제작자 메서드를 선언하는 빈에서 상속되지 않습니다.
생산자 메서드를 사용하면 빈이 아닌 오브젝트를 주입하고 코드를 동적으로 변경할 수 있습니다.
7.8. 대체 빈 링크 복사링크가 클립보드에 복사되었습니다!
대안은 구현이 특정 클라이언트 모듈 또는 배포 시나리오에 고유한 빈입니다.
기본적으로 @Alternative 빈은 비활성화되어 있습니다. bean. xml 파일을 편집하여 특정 빈 아카이브에 대해 활성화됩니다. 그러나 이 활성화는 해당 아카이브의 빈에만 적용됩니다. @Priority 주석을 사용하여 전체 애플리케이션에 대한 대안을 활성화할 수 있습니다.
예제: 대체 옵션 정의
이 대안은 @Synchronous 및 @ Asynchronous 대안을 둘 다 사용하여 PaymentProcessor 클래스 구현을 정의합니다.
예제: beans.xml을 사용하여 @Alternative 활성화
선택한 대안 선언
@Priority 주석을 사용하면 전체 애플리케이션에 대한 대안을 활성화할 수 있습니다. 대안은 애플리케이션의 우선 순위를 지정할 수 있습니다.
-
관리 빈 또는 세션 빈의 빈 클래스에
@Priority주석을 배치하거나 -
제작자 메서드, 필드 또는 리소스를 선언하는 빈 클래스에
@Priority주석을 배치합니다.
7.8.1. 삽입을 대체로 덮어쓰기 링크 복사링크가 클립보드에 복사되었습니다!
대체 빈을 사용하여 기존 빈을 재정의할 수 있습니다. 동일한 역할을 채우지만 다른 기능을 채우는 클래스를 연결하는 방법으로 간주할 수 있습니다. 기본적으로 비활성화되어 있습니다.
이 작업은 대안을 지정하고 활성화하는 방법을 보여줍니다.
삽입 덮어쓰기
이 작업에서는 프로젝트에 TranslatingWelcome 클래스가 이미 있다고 가정하지만 "mock" TranslatingWelcome 클래스로 재정의하려고 합니다. 실제 빈 을 사용할 수 없는 테스트 배포의 사례입니다.
대안을 정의합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow META-INF/beans.xml 또는파일에 정규화된 클래스 이름을 추가하여 대체 구현을 활성화합니다.WEB-INF/beans.xml<beans> <alternatives> <class>com.acme.MockTranslatingWelcome</class> </alternatives> </beans><beans> <alternatives> <class>com.acme.MockTranslatingWelcome</class> </alternatives> </beans>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
이제 원래 구현 대신 대체 구현이 사용됩니다.
7.9. 확대/축소 링크 복사링크가 클립보드에 복사되었습니다!
많은 시스템에서 아키텍처 패턴을 사용하면 반복되는 빈 역할이 생성됩니다. 종료 유형을 사용하면 이러한 역할을 식별하고 중앙 위치에서 해당 역할이 있는 빈의 일반적인 메타데이터를 선언할 수 있습니다.
프로토타이핑 유형은 다음과 같은 조합을 캡슐화합니다.
- 기본 범위.
- 인터셉터 바인딩 세트입니다.
매개변수 유형에서는 다음 중 하나를 지정할 수도 있습니다.
- 백유형이 기본값인 빈 EL 이름이 있는 모든 빈.
- 대체 유형이 있는 모든 빈.
빈은 0, 1 또는 여러 개의 백유형을 선언할 수 있습니다. trailtype은 다른 여러 주석을 패키징하는 @Stereotype 주석입니다. digtype 주석은 빈 클래스, 생산자 메서드 또는 필드에 적용할 수 있습니다.
사전 유형에서 범위를 상속하는 클래스는 해당 사전 유형을 재정의하고 빈에서 직접 범위를 지정할 수 있습니다.
또한 entitytype에 @Named 주석이 있는 경우 해당 빈에 기본 빈 이름이 있습니다. 빈에 @Named 주석이 직접 지정된 경우 빈이 이 이름을 재정의할 수 있습니다. 명명된 빈에 대한 자세한 내용은 Named Beans 를 참조하십시오.
7.9.1. pvcreotypes 사용 링크 복사링크가 클립보드에 복사되었습니다!
피사유형이 없으면 주석이 복잡해질 수 있습니다. 이 작업에서는 난형을 사용하여 복잡성을 줄이고 코드를 간소화하는 방법을 보여 줍니다.
예제: 주석 복제
osreotypes 정의 및 사용
tooltype을 정의합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 철자 유형을 사용합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.10. 관찰자 방법 링크 복사링크가 클립보드에 복사되었습니다!
관찰자 메서드는 이벤트가 발생하면 알림을 받습니다.
컨텍스트 및 종속성 주입은 트랜잭션 관찰기 메서드를 제공하여 이벤트가 실행된 트랜잭션의 완료 단계 또는 트랜잭션 완료 단계 이후에 이벤트 알림을 수신합니다.
7.10.1. 이벤트 실행 및 관찰 링크 복사링크가 클립보드에 복사되었습니다!
예제: 이벤트 실행
다음 코드는 메서드에서 주입 및 사용되는 이벤트를 보여줍니다.
예제: 한정자를 사용하여 이벤트 실행
이벤트 삽입에 한정자를 추가하여 보다 구체화할 수 있습니다. 한정자에 대한 자세한 내용은 한정자를 참조하십시오.
예제: 이벤트 관찰
이벤트를 관찰하려면 @Observes 주석을 사용합니다.
public class AccountObserver {
void checkTran(@Observes Withdrawal w) {
...
}
}
public class AccountObserver {
void checkTran(@Observes Withdrawal w) {
...
}
}
한정자를 사용하여 특정 유형의 이벤트만 관찰할 수 있습니다.
public class AccountObserver {
void checkTran(@Observes @Suspicious Withdrawal w) {
...
}
}
public class AccountObserver {
void checkTran(@Observes @Suspicious Withdrawal w) {
...
}
}
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) { ... }
public void refreshCategoryTree(@Observes(during = AFTER_SUCCESS) CategoryUpdateEvent event) { ... }
다음 예와 같이 애플리케이션 범위에 설정된 Jakarta Persistence 쿼리 결과를 캐시했다고 가정합니다.
경우에 따라 제품이 생성 또는 삭제 되는 경우도 있습니다. 이 경우 제품 카탈로그를 새로 고쳐야 합니다. 그러나 이 업데이트를 수행하기 전에 트랜잭션이 성공적으로 완료될 때까지 기다려야 합니다.
다음은 Products triggers 이벤트를 생성하고 삭제하는 빈의 예입니다.
이제 Catalog 에서 트랜잭션이 완료되면 이벤트를 관찰할 수 있습니다.
7.11. 인터셉터 링크 복사링크가 클립보드에 복사되었습니다!
인터셉터를 사용하면 빈의 방법을 직접 수정하지 않고도 빈의 비즈니스 메서드에 기능을 추가할 수 있습니다. 인터셉터는 빈의 비즈니스 방법보다 먼저 실행됩니다. 인터셉터는 Jakarta Enterprise Beans 사양의 일부로 정의됩니다.
Jakarta Contexts and Dependency Injection은 주석을 사용하여 인터셉터를 bean에 바인딩할 수 있어 이 기능을 향상시킵니다.
인터셉션 포인트
- 비즈니스 방법 가로채기: 비즈니스 메서드 인터셉터는 빈의 클라이언트가 빈 메서드 호출에 적용됩니다.
- 라이프 사이클 콜백 인터셉션: 라이프사이클 콜백 인터셉터는 컨테이너에서 라이프사이클 콜백 호출에 적용됩니다.
- timeout 메서드 인터셉션: timeout 메서드 인터셉터는 컨테이너에서 Jakarta Enterprise Beans 시간 제한 메서드를 호출하는 데 적용됩니다.
인터셉터 활성화
기본적으로 모든 인터셉터는 비활성화됩니다. 빈 아카이브의 bean.xml 설명자를 사용하여 인터셉터를 활성화할 수 있습니다. 그러나 이 활성화는 해당 아카이브의 빈에만 적용됩니다.
@Priority 주석을 사용하여 전체 애플리케이션에 대한 인터셉터를 활성화할 수 있습니다.
예제: bean.xml에서 인터셉터 활성화
XML 선언을 사용하면 두 가지 문제가 해결됩니다.
- 이를 통해 시스템의 인터셉터 순서를 지정하여 결정적인 동작을 보장할 수 있습니다.
- 배포 시 인터셉터 클래스를 활성화하거나 비활성화할 수 있습니다.
@Priority 를 사용하여 활성화된 인터셉터는 beans.xml 파일을 사용하여 인터셉터를 활성화하기 전에 호출됩니다.
인터셉터를 @Priority 에서 활성화하고 동시에 beans.xml 파일에서 호출하면 포팅할 수 없는 동작이 발생합니다. 따라서 다양한 Jakarta Contexts 및 Dependency Injection 구현에서 일관된 동작을 유지하려면 활성화의 조합을 피해야 합니다.
7.11.1. 자카르타 컨텍스트 및 종속성 주입과 인터셉터 사용 링크 복사링크가 클립보드에 복사되었습니다!
Jakarta Contexts and Dependency Injection을 사용하면 인터셉터 코드를 단순화하고 비즈니스 코드에 더 쉽게 적용할 수 있습니다.
자카르타 컨텍스트 및 종속성 주입이 없으면 인터셉터에는 두 가지 문제가 있습니다.
- 빈은 인터셉터 구현을 직접 지정해야 합니다.
- 애플리케이션의 모든 빈은 올바른 순서로 전체 인터셉터 세트를 지정해야 합니다. 이로 인해 애플리케이션 전체에서 인터셉터를 추가하거나 제거할 수 있으며 오류가 발생하기 쉽습니다.
자카르타 컨텍스트 및 종속성 주입과 인터셉터 사용
인터셉터 바인딩 유형을 정의합니다.
@InterceptorBinding @Retention(RUNTIME) @Target({TYPE, METHOD}) public @interface Secure {}@InterceptorBinding @Retention(RUNTIME) @Target({TYPE, METHOD}) public @interface Secure {}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 인터셉터 구현을 표시합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 사용자의 개발 환경에서 인터셉터를 사용합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow META-INF/beans.xml 또는파일에 추가하여 배포에서 인터셉터를 활성화합니다.WEB-INF/beans.xmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
인터셉터는 나열된 순서대로 적용됩니다.
7.12. 데코레이터 링크 복사링크가 클립보드에 복사되었습니다!
데코레이터는 특정 Java 인터페이스에서 호출을 가로채며 해당 인터페이스에 연결된 모든 의미 체계를 인식합니다. 데코레이터는 일부 유형의 비즈니스 문제를 모델링하는 데 유용하지만 인터셉터는 일반적으로 없습니다. 데코레이터는 빈 또는 추상 클래스로, 패키징하는 유형을 구현하고 @Decorator 로 주석이 추가됩니다. Jakarta Contexts 및 Dependency Injection 애플리케이션에서 데코레이터를 호출하려면 bean.xml 파일에 지정해야 합니다.
예제: bean.xml을 통해 액셀러레이터 호출
이 선언은 다음 두 가지 주요 목적을 제공합니다.
- 이를 통해 시스템에서 데코레이터의 순서를 지정하여 결정적인 동작을 보장할 수 있습니다.
- 배포 시 데코레이터 클래스를 활성화하거나 비활성화할 수 있습니다.
데코레이터에 정확히 하나의 @Delegate 주입 지점이 있어야 하므로 이 오브젝트에 대한 참조를 얻을 수 있습니다.
예제: 데코레이터 클래스
@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() 메서드를 호출합니다.
예제: 프록시 삽입
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 인터페이스와클래스를 확장할 수 있습니다.ServiceMBeanSupportServiceMBeanSupport클래스는 생성, 시작 및 중지와 같은 서비스 라이프사이클 방법을 구현합니다.start()이벤트와 같은 특정 이벤트를 처리하려면ServiceMBeanSupport클래스에서 제공하는startService()메서드를 재정의해야 합니다.
8.1.1. 표준 MBean 예 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 서비스 아카이브(. sar)에 함께 패키지로 제공되는 MBean 서비스 예제를 개발합니다.
ConfigServiceMBean 인터페이스는 JBoss 특정 클래스를 사용하지 않고 MBean을 올바르게 시작,보유 및 중지하는 start,getTimeout 및 stop 메서드와 같은 특정 메서드를 선언합니다. ConfigService 클래스는 ConfigServiceMBean 인터페이스를 구현하고 그 결과 해당 인터페이스 내에서 사용되는 메서드를 구현합니다.
PlainThread 클래스는 ServiceMBeanSupport 클래스를 확장하고 PlainThreadMBean 인터페이스를 구현합니다. PlainThread 는 스레드를 시작하고 ConfigServiceMBean.getTimeout() 을 사용하여 스레드를 유휴 상태로 설정하는 시간을 결정합니다.
예제: MBean 서비스 클래스
jboss-service.xml 설명자는 inject 태그를 사용하여 ConfigService 클래스가 PlainThread 클래스에 삽입되는 방법을 보여줍니다. inject 태그는 PlainThreadMBean과 ConfigServiceMBean 사이에 종속성을 설정하므로PlainThreadMBean이 을 쉽게 사용할 수 있습니다.
ConfigServiceMBean
예: jboss-service.xml 서비스 설명자
MBeans 예제를 작성한 후에는 서비스 아카이브( .
sar)의 설명자를 패키징할 수 있습니다.META-INF/ 폴더에 클래스 및 jboss- service.xml
8.2. JBoss MBean 서비스 배포 링크 복사링크가 클립보드에 복사되었습니다!
예제: 관리형 도메인에서 MBean 배포 및 테스트
다음 명령을 사용하여 관리형 도메인에 MBeans(ServiceMBeanTest.sar) 예제를 배포합니다.
deploy ~/Desktop/ServiceMBeanTest.sar --all-server-groups
deploy ~/Desktop/ServiceMBeanTest.sar --all-server-groups
예제: 독립 실행형 서버에 MBean 배포 및 테스트
다음 명령을 사용하여 독립 실행형 서버에서 MBean(ServiceMBeanTest.sar) 예제를 빌드하고 배포합니다.
deploy ~/Desktop/ServiceMBeanTest.sar
deploy ~/Desktop/ServiceMBeanTest.sar
예제: MBeans 아카이브 배포 취소
다음 명령을 사용하여 MBean 예제 배포를 취소합니다.
undeploy ServiceMBeanTest.sar
undeploy ServiceMBeanTest.sar
9장. 자카르타 동시성 링크 복사링크가 클립보드에 복사되었습니다!
Jakarta Concurrency는 자카르타 EE 애플리케이션 환경 사양에 Java SE 동시성 유틸리티를 수용하는 API입니다. 자카르타 동시성 사양에 정의되어 있습니다. JBoss EAP를 사용하면 자카르타 동시성 인스턴스를 생성, 편집 및 삭제할 수 있으므로 이러한 인스턴스를 애플리케이션에서 사용할 수 있습니다.
Jakarta Concurrency는 기존 컨텍스트의 애플리케이션 스레드를 가져와 자체 스레드에서 이를 사용하여 호출 컨텍스트를 확장하는 데 도움이 됩니다. 호출 컨텍스트 확장에는 기본적으로 클래스 로드, JNDI 및 보안 컨텍스트가 포함됩니다.
자카르타 동시성 유형은 다음과 같습니다.
- 컨텍스트 서비스
- 관리 스레드 팩토리
- 관리형 실행자 서비스
- 관리된 예약 실행자 서비스
예제: standalone.xml의 자카르타 동시성
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)
/subsystem=ee/context-service=newContextService:add(jndi-name=java:jboss/ee/concurrency/contextservice/newContextService)
예제: 컨텍스트 서비스 변경
/subsystem=ee/context-service=newContextService:write-attribute(name=jndi-name, value=java:jboss/ee/concurrency/contextservice/changedContextService)
/subsystem=ee/context-service=newContextService:write-attribute(name=jndi-name, value=java:jboss/ee/concurrency/contextservice/changedContextService)
이 작업을 수행하려면 다시 로드해야 합니다.
예제: 컨텍스트 서비스 제거
/subsystem=ee/context-service=newContextService:remove()
/subsystem=ee/context-service=newContextService:remove()
이 작업을 수행하려면 다시 로드해야 합니다.
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)
/subsystem=ee/managed-thread-factory=newManagedTF:add(context-service=newContextService, jndi-name=java:jboss/ee/concurrency/threadfactory/newManagedTF, priority=2)
예제: 관리 스레드 팩토리 변경
/subsystem=ee/managed-thread-factory=newManagedTF:write-attribute(name=jndi-name, value=java:jboss/ee/concurrency/threadfactory/changedManagedTF)
/subsystem=ee/managed-thread-factory=newManagedTF:write-attribute(name=jndi-name, value=java:jboss/ee/concurrency/threadfactory/changedManagedTF)
이 작업을 수행하려면 다시 로드해야 합니다. 마찬가지로 다른 속성도 변경할 수 있습니다.
예제: 관리 스레드 팩토리 제거
/subsystem=ee/managed-thread-factory=newManagedTF:remove()
/subsystem=ee/managed-thread-factory=newManagedTF:remove()
이 작업을 수행하려면 다시 로드해야 합니다.
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)
/subsystem=ee/managed-executor-service=newManagedExecutorService:add(jndi-name=java:jboss/ee/concurrency/executor/newManagedExecutorService, core-threads=7, thread-factory=default)
예제: Managed Executor 서비스 변경
/subsystem=ee/managed-executor-service=newManagedExecutorService:write-attribute(name=core-threads,value=10)
/subsystem=ee/managed-executor-service=newManagedExecutorService:write-attribute(name=core-threads,value=10)
이 작업을 수행하려면 다시 로드해야 합니다. 마찬가지로 다른 속성도 변경할 수 있습니다.
예제: Managed Executor 서비스 제거
/subsystem=ee/managed-executor-service=newManagedExecutorService:remove()
/subsystem=ee/managed-executor-service=newManagedExecutorService:remove()
이 작업을 수행하려면 다시 로드해야 합니다.
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)
/subsystem=ee/managed-scheduled-executor-service=newManagedScheduledExecutorService:add(jndi-name=java:jboss/ee/concurrency/scheduledexecutor/newManagedScheduledExecutorService, core-threads=7, context-service=default)
이 작업을 수행하려면 다시 로드해야 합니다.
예제: 관리형 예약 실행자 서비스 변경
/subsystem=ee/managed-scheduled-executor-service=newManagedScheduledExecutorService:write-attribute(name=core-threads, value=10)
/subsystem=ee/managed-scheduled-executor-service=newManagedScheduledExecutorService:write-attribute(name=core-threads, value=10)
이 작업을 수행하려면 다시 로드해야 합니다. 마찬가지로 다른 특성을 변경할 수 있습니다.
예제: 관리형 예약 실행자 서비스 제거
/subsystem=ee/managed-scheduled-executor-service=newManagedScheduledExecutorService:remove()
/subsystem=ee/managed-scheduled-executor-service=newManagedScheduledExecutorService:remove()
이 작업을 수행하려면 다시 로드해야 합니다.
9.5. 관리되는 실행자 서비스 및 관리된 예약된 실행자 서비스에 대한 런타임 통계 링크 복사링크가 클립보드에 복사되었습니다!
관리 CLI 특성으로 생성된 런타임 통계를 확인하여 관리되는 실행자 서비스의 성능을 모니터링하고 예약된 실행자 서비스의 성능을 모니터링할 수 있습니다. 독립 실행형 서버 또는 호스트에 매핑된 개별 서버에 대한 런타임 통계를 볼 수 있습니다.
domain.xml 구성에는 런타임 통계 관리 CLI 속성에 대한 리소스가 포함되지 않으므로 관리 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)
[standalone@localhost:9990 /] /subsystem=ee/managed-executor-service=default:read-resource(include-runtime=true,recursive=true)
독립 실행형 서버에서 실행 중인 관리 예약된 executor 서비스에 대한 런타임 통계의 예.
[standalone@localhost:9990 /] /subsystem=ee/managed-scheduled-executor-service=default:read-resource(include-runtime=true,recursive=true)
[standalone@localhost:9990 /] /subsystem=ee/managed-scheduled-executor-service=default:read-resource(include-runtime=true,recursive=true)
호스트에 매핑된 서버에서 실행 중인 관리 실행자 서비스에 대한 런타임 통계를 보는 예.
[domain@localhost:9990 /] /host=<host_name>/server=<server_name>/subsystem=ee/managed-executor-service=default:read-resource(include-runtime=true,recursive=true)
[domain@localhost:9990 /] /host=<host_name>/server=<server_name>/subsystem=ee/managed-executor-service=default:read-resource(include-runtime=true,recursive=true)
호스트에 매핑된 서버에서 실행 중인 관리 예약 실행자 서비스에 대한 런타임 통계의 예.
[domain@localhost:9990 /] /host=<host_name>/server=<server_name>/subsystem=ee/managed-scheduled-executor-service=default:read-resource(include-runtime=true,recursive=true)
[domain@localhost:9990 /] /host=<host_name>/server=<server_name>/subsystem=ee/managed-scheduled-executor-service=default:read-resource(include-runtime=true,recursive=true)
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 스레드에서 실행을 차단할 수 있는 작업자 스레드로 이동하는 것입니다.
예제: 작업자 스레드로 디스패치
호출 스택이 반환될 때까지 교환이 실제로 디스패치되지 않으므로 한 번에 둘 이상의 스레드가 교환에서 활성화되지 않도록 할 수 있습니다. 교환은 안전한 스레드가 아닙니다. 그러나 두 스레드가 한 번에 수정하지 않는 한 여러 스레드 간에 전달할 수 있습니다.
교환 종료
교환을 종료하는 방법에는 요청 채널을 완전히 읽고 응답 채널에서 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')
allowed-methods(methods='GET')
모든 핸들러는 특정 경우에 해당 핸들러를 적용하기 위해 선택적 서술자를 사용할 수도 있습니다.
예제: 선택적 서술자를 사용한 WEB-INF/undertow-handlers.conf 파일
path('/my-path') -> allowed-methods(methods='GET')
path('/my-path') -> allowed-methods(methods='GET')
위의 예제에서는 allowed-methods 핸들러만 경로 /my-path 에 적용합니다.
Undertow 핸들러 기본 매개변수
일부 핸들러에는 기본 매개 변수가 있습니다. 이 매개 변수는 이름을 사용하지 않고 핸들러 정의에서 해당 매개 변수의 값을 지정할 수 있습니다.
예제: 기본 매개 변수를 사용하여 WEB-INF/undertow-handlers.conf 파일
path('/a') -> redirect('/b')
path('/a') -> redirect('/b')
하나 이상의 핸들러의 정의를 포함하도록 WEB-INF/jboss-web.xml 파일을 업데이트할 수도 있지만 WEB-INF/undertow-handlers.conf 를 사용하는 것이 좋습니다.
예제: WEB-INF/jboss-web.xml File
제공된 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>
<jboss-web>
<http-handler>
<class-name>org.jboss.example.MyHttpHandler</class-name>
</http-handler>
</jboss-web>
예제: HttpHandler Class
WEB-INF/jboss-web.xml 파일을 사용하여 사용자 지정 핸들러에 대한 매개 변수를 설정할 수도 있습니다.
예제: WEB-INF/jboss-web.xml에서 매개 변수 정의
이러한 매개 변수가 작동하려면 핸들러 클래스에 해당 setter가 있어야 합니다.
예제: 핸들러에서 Setter 방법 정의
WEB-INF/undertow-handlers.conf 파일에서 사용자 지정 핸들러 정의
핸들러를 정의하는 데 WEB-INF/jboss-web.xml 을 사용하는 대신 WEB-INF/undertow-handlers.conf 파일에 정의할 수도 있습니다.
myHttpHandler(myParam='foobar')
myHttpHandler(myParam='foobar')
WEB-INF/undertow-handlers.conf 에 정의된 핸들러가 작동하려면 다음 두 가지를 만들어야 합니다.
해당 구문 비트 for
undertow-handlers.conf를 정의하는HandlerBuilder구현으로HandlerWrapper로 래핑된HttpHandler를 생성합니다.예제:
HandlerBuilder클래스Copy to Clipboard Copied! Toggle word wrap Toggle overflow 파일의 항목.
META-INF/services/io.undertow.server.handlers.builder.HandlerBuilder. 이 파일은WEB-INF/classes와 같은 클래스 경로에 있어야 합니다.org.jboss.example.MyHandlerBuilder
org.jboss.example.MyHandlerBuilderCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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
module add --name=org.wildfly.security.examples.custom-http --resources=/path/to/custom-http-mechanism.jar --dependencies=org.wildfly.security.elytron,javax.api
사용자 지정 HTTP 메커니즘 사용
사용자 지정 모듈을 추가합니다.
/subsystem=elytron/service-loader-http-server-mechanism-factory=custom-factory:add(module=org.wildfly.security.examples.custom-http)
/subsystem=elytron/service-loader-http-server-mechanism-factory=custom-factory:add(module=org.wildfly.security.examples.custom-http)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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}])/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 Copied! Toggle word wrap Toggle overflow 새
http리소스를 업데이트합니다.-authentication-factory를 사용하도록 application-security-domain참고애플리케이션이 배포되면 기본적으로
other보안 도메인을 사용합니다. 따라서 애플리케이션에 매핑을 추가하여 Elytron HTTP 인증 팩토리에 매핑해야 합니다./subsystem=undertow/application-security-domain=other:add(http-authentication-factory=application-http-authentication)
/subsystem=undertow/application-security-domain=other:add(http-authentication-factory=application-http-authentication)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이제 새
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)
/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 Copied! Toggle word wrap Toggle overflow 위의 명령은 배포 구성을 덮어씁니다. 즉, 배포가 다른 메커니즘을 사용하도록 구성된 경우에도
http-authentication-factory의 메커니즘이 사용됩니다. 따라서 배포 자체를 수정할 필요 없이 사용자 지정 메커니즘을 사용하도록 배포 내의 구성을 재정의할 수 있습니다.서버를 다시 로드합니다
reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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라는 용어는 다음 두 가지를 나타냅니다.
- Jakarta Transactions - Jakarta EE 사양에 의해 정의됩니다.
- 이 값은 일반적으로 트랜잭션을 처리하는 방식을 나타냅니다.
복습은 자카르타 트랜잭션 모드에서 작동하고, 메모리에서 데이터를 공유하며, 트랜잭션 컨텍스트는 원격 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. 원자적 트랜잭션 프로세스 링크 복사링크가 클립보드에 복사되었습니다!
- 클라이언트 애플리케이션은 AT를 시작하기 위해 먼저 WS-T를 지원하는 WS-C Activation Coordinator 웹 서비스를 찾습니다.
-
클라이언트는 WS-C
CreateCoordinationContext메시지를 서비스에 전송하여 http://schemas.xmlsoap.org/ws/2004/10/wsat 를 조정 유형으로 지정합니다. - 클라이언트는 활성화 서비스에서 적절한 WS-T 컨텍스트를 받습니다.
-
CreateCoordinationContext메시지에 대한 응답인 트랜잭션 컨텍스트의CoordinationType요소에는 WS-AT 네임스페이스 http://schemas.xmlsoap.org/ws/2004/10/wsat 설정된 CoordinationType 요소가 있습니다. 또한 참가자를 등록할 수 있는 원자 트랜잭션 코디네이터 엔드포인트인 WS-C Registration Service에 대한 참조가 포함되어 있습니다. - 일반적으로 클라이언트는 웹 서비스를 호출하고 웹 서비스의 모든 변경 사항을 커밋하거나 다시 롤백하여 트랜잭션을 완료합니다. 이 완료를 촉진하기 위해 클라이언트는 조정 컨텍스트에서 엔드포인트가 반환된 등록 서비스에 레지스터 메시지를 전송하여 완료 프로토콜의 참가자로 등록해야 합니다.
- 완료를 위해 등록한 다음 클라이언트 애플리케이션은 웹 서비스와 상호 작용하여 비즈니스 수준 작업을 수행합니다. 비즈니스 웹 서비스를 호출할 때마다 클라이언트는 트랜잭션 컨텍스트를 SOAP 헤더 블록에 삽입하여 각 호출의 범위를 암시적으로 트랜잭션으로 지정합니다. WS-AT 인식 웹 서비스를 지원하는 툴킷은 SOAP 헤더 블록에 있는 컨텍스트와 백엔드 작업을 연결하는 기능을 제공합니다. 이렇게 하면 웹 서비스에서 수정한 내용이 클라이언트와 동일한 트랜잭션 범위 내에서 수행되고 트랜잭션 코디네이터가 커밋 또는 롤백할 수 있습니다.
- 필요한 모든 애플리케이션 작업이 완료되면 클라이언트는 서비스 상태를 영구적으로 변경하기 위해 트랜잭션을 종료할 수 있습니다. 완료 참가자는 코디네이터에 트랜잭션을 커밋하거나 롤백하도록 지시합니다. 커밋 또는 롤백 작업이 완료되면 상태가 참가자에게 반환되어 트랜잭션 결과를 나타냅니다.
자세한 내용은 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)
/subsystem=xts:write-attribute(name=async-registration, value=true)
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 프로세스 링크 복사링크가 클립보드에 복사되었습니다!
- 작업을 수행하기 위해 서비스가 요청됩니다.
-
이러한 서비스에는 작업을 실행 취소할 수 있는 기능이 있는 경우 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
ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecordCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이는 복구 시 JBoss Transaction Manager(TM)가 로그에서 트랜잭션 참가자를 확인하고 커밋을 다시 시도하기 때문입니다. 결국 JBoss는 리소스가 커밋되어 더 이상 커밋을 다시 시도하지 않는다고 가정합니다. 이 경우 트랜잭션이 커밋되고 데이터가 손실되지 않으므로 이 경고를 무시해도 됩니다.
경고를 방지하려면
com.arspringa.ats.jta.xaAssume rescueyComplete속성 값을true로 설정합니다. 이 속성은 새XAResource 인스턴스가 등록된XAResourcerecoveryy 인스턴스에서 찾을 수 없을 때마다 확인됩니다.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
ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_NOTA: javax.transaction.xa.XAExceptionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 부하가 많으면 트랜잭션에서 수행한 처리 시간이 주기적인 복구 프로세스 활동 시간과 겹칠 수 있습니다. 주기적인 복구 프로세스는 여전히 트랜잭션이 진행 중인 것을 감지하고 롤백을 시작하려고 시도하지만 실제로 트랜잭션이 계속 완료됩니다. 현재 주기적인 복구 시도는 시도하지만 롤백에 실패하여 서버 로그에 롤백 실패를 기록합니다. 이 문제의 근본적인 원인은 향후 릴리스에서 해결될 예정이지만 당분간 해결방법을 사용할 수 있습니다.
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 서버 간에 분산된 자카르타 트랜잭션을 지원합니다.
여러 벤더의 서버 간 트랜잭션 배포는 지원되지 않습니다.
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 리소스를 추가하는 절차는 다음과 같습니다.
- XA 트랜잭션을 준비합니다.
- LRCO 커밋.
- 트랜잭션 로그를 작성합니다.
- 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을 구성하려면 다음을 수행해야 합니다.
- 데이터베이스에 테이블 만들기.
- 연결할 수 있도록 데이터 소스를 활성화합니다.
-
트랜잭션하위 시스템에 참조를 추가합니다.
데이터베이스에서 테이블 만들기
트랜잭션에는 하나의 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[])
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[])
다음은 다양한 데이터베이스 관리 시스템의 테이블을 생성하는 SQL 구문의 예입니다.
예제: Sybase 테이블 구문 생성
CREATE TABLE xids (xid varbinary(144), transactionManagerID varchar(64), actionuid varbinary(28))
CREATE TABLE xids (xid varbinary(144), transactionManagerID varchar(64), actionuid varbinary(28))
예제: Oracle Create Table Syntax
CREATE TABLE xids (xid RAW(144), transactionManagerID varchar(64), actionuid RAW(28)) CREATE UNIQUE INDEX index_xid ON xids (xid)
CREATE TABLE xids (xid RAW(144), transactionManagerID varchar(64), actionuid RAW(28))
CREATE UNIQUE INDEX index_xid ON xids (xid)
예제: 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)
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)
예제: 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)
CREATE TABLE xids (xid varbinary(144), transactionManagerID varchar(64), actionuid varbinary(28))
CREATE UNIQUE INDEX index_xid ON xids (xid)
예제: PostgreSQL Create Table Syntax
CREATE TABLE xids (xid bytea, transactionManagerID varchar(64), actionuid bytea) CREATE UNIQUE INDEX index_xid ON xids (xid)
CREATE TABLE xids (xid bytea, transactionManagerID varchar(64), actionuid bytea)
CREATE UNIQUE INDEX index_xid ON xids (xid)
예제: MariaDB 테이블 구문 생성
CREATE TABLE xids (xid BINARY(144), transactionManagerID varchar(64), actionuid BINARY(28)) CREATE UNIQUE INDEX index_xid ON xids (xid)
CREATE TABLE xids (xid BINARY(144), transactionManagerID varchar(64), actionuid BINARY(28))
CREATE UNIQUE INDEX index_xid ON xids (xid)
예제: MySQL Create Table Syntax
CREATE TABLE xids (xid VARCHAR(255), transactionManagerID varchar(64), actionuid VARCHAR(255)) CREATE UNIQUE INDEX index_xid ON xids (xid)
CREATE TABLE xids (xid VARCHAR(255), transactionManagerID varchar(64), actionuid VARCHAR(255))
CREATE UNIQUE INDEX index_xid ON xids (xid)
연결할 수 있는 데이터 소스 활성화
기본적으로 데이터 소스에 대해 CMR 기능이 비활성화되어 있습니다. 이를 활성화하려면 데이터 소스 구성을 생성하거나 수정하고 연결 가능한 특성이 true 로 설정되어 있는지 확인해야 합니다. 다음은 서버 XML 구성 파일의 데이터 소스 섹션의 예입니다.
<datasource enabled="true" jndi-name="java:jboss/datasources/ConnectableDS" pool-name="ConnectableDS" jta="true" use-java-context="true" connectable="true"/>
<datasource enabled="true" jndi-name="java:jboss/datasources/ConnectableDS" pool-name="ConnectableDS" jta="true" use-java-context="true" connectable="true"/>
이 기능은 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")
/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")
이 명령은 서버 구성 파일의 데이터 소스 섹션에 다음 XML을 생성합니다.
데이터 소스에 유효한 드라이버가 정의되어 있어야 합니다. 위의 예제에서는 mssql 을 driver-name 으로 사용하지만 mssql 드라이버는 존재하지 않습니다. 자세한 내용은 JBoss EAP 구성 가이드 의 MySQL 데이터 소스 예제 를 참조하십시오.
데이터 소스 구성에서 exception-sorter-class-name 매개변수를 사용합니다. 자세한 내용은 JBoss EAP 구성 가이드의 데이터 소스 구성 예제 를 참조하십시오.
새로운 CMR 기능을 사용하도록 기존 리소스 업데이트
CMR 기능을 사용하도록 기존 데이터 소스만 업데이트해야 하는 경우 연결 가능한 속성을 수정하면 됩니다.
/subsystem=datasources/data-source=ConnectableDS:write-attribute(name=connectable,value=true)
/subsystem=datasources/data-source=ConnectableDS:write-attribute(name=connectable,value=true)
Transactions 하위 시스템에 참조 추가
트랜잭션 하위 시스템은 아래와 같이 트랜잭션 하위 시스템 구성 섹션의 항목을 통해 CMR이 가능한 데이터 소스를 식별합니다.
관리 CLI를 사용하여 동일한 결과를 얻을 수 있습니다.
/subsystem=transactions/commit-markable-resource=java\:jboss\/datasources\/ConnectableDS/:add(batch-size=100,immediate-cleanup=false,name=xids)
/subsystem=transactions/commit-markable-resource=java\:jboss\/datasources\/ConnectableDS/:add(batch-size=100,immediate-cleanup=false,name=xids)
트랜잭션 하위 시스템에서 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 연결입니다.
애플리케이션이 새 트랜잭션을 시작합니다.
트랜잭션을 시작하기 위해 애플리케이션은 Java Naming and Directory Interface에서 또는 주석에서 Jakarta Enterprise Bean인 경우
UserTransaction클래스 인스턴스를 가져옵니다.UserTransaction인터페이스에는 최상위 트랜잭션을 시작, 커밋 및 롤백하는 방법이 포함되어 있습니다. 새로 생성된 트랜잭션은 호출 스레드와 자동으로 연결됩니다. 자카르타 트랜잭션에서는 중첩 트랜잭션이 지원되지 않으므로 모든 트랜잭션은 최상위 트랜잭션입니다.Jakarta Enterprise Bean은
UserTransaction.begin()메서드가 호출될 때 트랜잭션을 시작합니다. 이 트랜잭션의 기본 동작은TransactionAttribute주석 또는ejb.xml설명자를 사용하여 영향을 받을 수 있습니다. 해당 지점 다음에 사용되는 모든 리소스는 트랜잭션과 연결됩니다. 둘 이상의 리소스가 등록되면 트랜잭션이 XA 트랜잭션이 되고 커밋 시 2단계 커밋 프로토콜에 참여합니다.참고기본적으로 트랜잭션은 자카르타 엔터프라이즈 빈의 애플리케이션 컨테이너에 의해 구동됩니다. 이를 CMT (컨테이너 관리 트랜잭션)라고 합니다. 트랜잭션 사용자가 구동되도록 하려면
트랜잭션 관리를 BMT(빈 관리 트랜잭션)로변경합니다. BMT에서는 사용자가 트랜잭션을 관리하는 데UserTransaction개체를 사용할 수 있습니다.애플리케이션은 상태를 수정합니다.
다음 단계에서는 애플리케이션이 작업을 수행하고 등록한 리소스에서만 해당 상태를 변경합니다.
애플리케이션에서 커밋 또는 롤백을 결정합니다.
애플리케이션에서 상태 변경을 완료하면 커밋 또는 롤백 여부를 결정합니다.
UserTransaction.commit() 또는중 하나를 적절한 메서드를 호출합니다. CMT의 경우 이 프로세스는 자동으로 구동되는 반면 BMT의 경우UserTransaction.rollback()UserTransaction의 메서드 커밋 또는 롤백은 명시적으로 호출해야 합니다.©는 해당 레코드에서 트랜잭션을 제거합니다.
커밋 또는 롤백이 완료된 후 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가 동일합니다.
UserTransaction인스턴스 가져오기.Jakarta Enterprise Beans가
@TransactionManagement(TransactionManagementType.BEAN)주석을 통해 빈 관리 트랜잭션을 사용하는 경우 Java Naming 및 Directory Interface, injection 또는 Jakarta Enterprise Beans 컨텍스트를 사용하여 인스턴스를 가져올 수 있습니다.Java 네이밍 및 디렉터리 인터페이스를 사용하여 인스턴스를 가져옵니다.
new InitialContext().lookup("java:comp/UserTransaction")new InitialContext().lookup("java:comp/UserTransaction")Copy to Clipboard Copied! Toggle word wrap Toggle overflow 삽입을 사용하여 인스턴스를 가져옵니다.
@Resource UserTransaction userTransaction;
@Resource UserTransaction userTransaction;Copy to Clipboard Copied! Toggle word wrap Toggle overflow Jakarta Enterprise Beans 컨텍스트를 사용하여 인스턴스를 가져옵니다.
상태 비저장/상태 저장 빈에서 다음을 수행합니다.
@Resource SessionContext ctx; ctx.getUserTransaction();
@Resource SessionContext ctx; ctx.getUserTransaction();Copy to Clipboard Copied! Toggle word wrap Toggle overflow 메시지 기반 빈에서:
@Resource MessageDrivenContext ctx; ctx.getUserTransaction()
@Resource MessageDrivenContext ctx; ctx.getUserTransaction()Copy to Clipboard Copied! Toggle word wrap Toggle overflow
데이터 소스에 연결한 후
UserTransaction.begin()을 호출합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
결과
트랜잭션이 시작됩니다. 데이터 소스의 모든 용도는 트랜잭션을 커밋하거나 롤백할 때까지 트랜잭션입니다.
전체 예는 Jakarta Transactions 트랜잭션 예제 를 참조하십시오.
Jakarta Enterprise Beans(CMT 또는 BMT와 함께 사용됨)의 이점 중 하나는 컨테이너가 트랜잭션 처리의 모든 내부를 관리한다는 것입니다. 즉, JBoss EAP 컨테이너 간에 XA 트랜잭션 또는 트랜잭션 배포의 일부인 트랜잭션을 관리할 수 있다는 것입니다.
11.7.2.1.1. 중첩 트랜잭션 링크 복사링크가 클립보드에 복사되었습니다!
중첩 트랜잭션을 사용하면 애플리케이션에서 기존 트랜잭션에 포함된 트랜잭션을 생성할 수 있습니다. 이 모델에서는 여러 하위 트랜잭션을 트랜잭션에 반복적으로 포함할 수 있습니다. 하위 트랜잭션은 상위 트랜잭션을 커밋하거나 롤백하지 않고 커밋하거나 롤백할 수 있습니다. 그러나 커밋 작업의 결과는 모든 트랜잭션의 상위에 대한 약속에 따릅니다.
구현 관련 정보는 Narayana 프로젝트 설명서 를 참조하십시오.
중첩 트랜잭션은 JTS 사양과 함께 사용하는 경우에만 사용할 수 있습니다. 중첩 트랜잭션은 JBoss EAP 애플리케이션 서버의 지원 기능이 아닙니다. 또한 많은 데이터베이스 벤더가 중첩 트랜잭션을 지원하지 않으므로 중첩 트랜잭션을 추가하기 전에 데이터베이스 벤더에게 문의하십시오.
11.7.2.2. 트랜잭션 커밋 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 자카르타 트랜잭션을 사용하여 트랜잭션을 커밋하는 방법을 설명합니다.
사전 요구 사항
트랜잭션을 커밋하려면 먼저 트랜잭션을 시작해야 합니다. 트랜잭션을 시작하는 방법에 대한 자세한 내용은 트랜잭션 시작을 참조하십시오.
UserTransaction에서commit()메서드를 호출합니다.UserTransaction에서 commit() 메서드를 호출하면 ->에서 트랜잭션을 커밋합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow CMT(컨테이너 관리 트랜잭션)를 사용하는 경우 수동으로 커밋할 필요가 없습니다.
컨테이너 관리 트랜잭션을 사용하도록 빈을 구성하는 경우 컨테이너는 코드에서 구성하는 주석을 기반으로 사용자의 트랜잭션 라이프사이클을 관리합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
결과
데이터 소스 커밋 및 트랜잭션이 종료되거나 예외가 발생합니다.
전체 예는 Jakarta Transactions 트랜잭션 예제 를 참조하십시오.
11.7.2.3. 트랜잭션 롤백 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 자카르타 트랜잭션을 사용하여 트랜잭션을 롤백하는 방법을 설명합니다.
사전 요구 사항
트랜잭션을 롤백하려면 먼저 트랜잭션을 시작해야 합니다. 트랜잭션을 시작하는 방법에 대한 자세한 내용은 트랜잭션 시작을 참조하십시오.
UserTransaction에서rollback()메서드를 호출합니다.UserTransaction에서rollback()메서드를 호출할 때 4.6은 트랜잭션을 롤백하고 데이터를 이전 상태로 되돌립니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow CMT(컨테이너 관리 트랜잭션)를 사용하는 경우 트랜잭션을 수동으로 롤백할 필요가 없습니다.
컨테이너 관리 트랜잭션을 사용하도록 빈을 구성하는 경우 컨테이너는 코드에서 구성하는 주석을 기반으로 사용자의 트랜잭션 라이프사이클을 관리합니다.
RuntimeException이 throw되면 CMT의 롤백이 발생합니다. setRollbackOnly 메서드를 명시적으로 호출하여 롤백을 얻을 수도 있습니다. 또는 롤백하려면 애플리케이션 예외에 @ApplicationException(rollback=true)을 사용합니다.
결과
귀하의 트랜잭션이 자동으로 롤백됩니다.
전체 예는 Jakarta Transactions 트랜잭션 예제 를 참조하십시오.
11.7.3. 트랜잭션에서 Heuristic Outcome 처리 링크 복사링크가 클립보드에 복사되었습니다!
추론적 트랜잭션 결과는 드물지만 일반적으로 특별한 원인을 갖습니다. 추론적이라는 단어는 "직접"을 의미하며, 일반적으로 이러한 결과를 처리해야 하는 방식입니다. 추론적 거래 결과에 대한 자세한 내용은 Heuristic Outcomes 를 참조하십시오.
다음 절차에서는 Jakarta 트랜잭션을 사용하여 트랜잭션의 복구 결과를 처리하는 방법을 설명합니다.
트랜잭션 결과의 원인은 리소스 관리자가 커밋하거나 롤백할 수 있다고 약속한 다음 약속을 이행하지 못하기 때문입니다. 이는 타사 구성 요소, 타사 구성 요소와 JBoss EAP 간의 통합 계층 문제 또는 JBoss EAP 자체에 문제가 될 수 있습니다.
지금까지 가장 일반적인 복구 오류의 원인은 환경에 일시적인 오류와 리소스 관리자를 처리하는 코딩 오류입니다.
일반적으로 환경에 일시적인 오류가 있는 경우 복구 오류를 확인하기 전에 이를 알 수 있습니다. 이는 네트워크 중단, 하드웨어 오류, 데이터베이스 장애, 정전 또는 기타 여러 가지 문제로 인해 발생할 수 있습니다.
스트레스 테스트 중에 테스트 환경에서 복구 결과가 나오면 테스트 환경의 약점이 있음을 의미합니다.
주의JBoss EAP는 장애 발생 시 복구되지 않은 상태인 트랜잭션을 자동으로 복구하지만 복구 트랜잭션은 복구하지 않습니다.
환경에 분명한 오류가 없거나 복구 결과를 쉽게 재현할 수 있는 경우 코딩 오류 때문일 수 있습니다. 솔루션을 사용하려면 타사 벤더에 문의해야 합니다.
JBoss EAP의 트랜잭션 관리자에 문제가 있다고 생각되는 경우 지원 티켓을 작성해야 합니다.
- 관리 CLI를 사용하여 수동으로 트랜잭션 복구를 시도할 수 있습니다. 자세한 내용은 JBoss EAP 에서 트랜잭션 관리의 트랜잭션 참가자 복구 섹션을 참조하십시오.
트랜잭션 결과를 수동으로 확인하는 프로세스는 오류의 정확한 상황에 따라 달라집니다. 환경에 적용할 수 있는 다음 단계를 수행합니다.
- 관련된 리소스 관리자를 식별합니다.
- 트랜잭션 관리자 및 리소스 관리자의 상태를 검사합니다.
- 관련된 구성 요소 중 하나 이상에서 로그 정리 및 데이터 조정을 수동으로 강제 적용합니다.
테스트 환경에서 또는 데이터의 무결성에 관심이 없는 경우 트랜잭션 로그를 삭제하고 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 및매개변수에 설정된 값에 따라 달라집니다. 파일 시스템 로그(예: 표준 섀도우 및 Apache ActiveMQ Artemis 로그)의 경우 기본 디렉터리 위치가 사용되지만 JDBC 오브젝트 저장소를 사용하는 경우 트랜잭션 로그가 데이터베이스에 저장됩니다.object-store-path
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 매개 변수를 조정하고 데이터베이스에 테스트 테이블을 두 개 설정해야 합니다.
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 애플리케이션을 만듭니다.
절차
Red Hat CodeReady Studio에서 JPA 프로젝트를 만듭니다.
Red Hat CodeReady Studio에서 파일 → 새 → 프로젝트를 클릭합니다. 목록에서 JPA 를 찾아 확장한 다음 JPA 프로젝트를 선택합니다. 다음 대화 상자가 표시됩니다.
그림 12.1. 새 JPA 프로젝트 대화 상자
- 프로젝트 이름을 입력합니다.
대상 런타임 을 선택합니다. 대상 런타임을 사용할 수 없는 경우 다음 지침에 따라 새 서버 및 런타임을 정의합니다. CodeReady Studio Tools 가이드 의 IDE 내에서 JBoss EAP 다운로드, 설치 및 설정.
참고Red Hat CodeReady Studio에서 Target 런타임 을 7.4 또는 이후 런타임 버전으로 설정하면 프로젝트가 Jakarta EE 8 사양과 호환됩니다.
- JPA 버전에서 2.1 이 선택되었는지 확인합니다.
- Configuration(구성) 에서 Basic JPA Configuration(기본 JPA 구성)을 선택합니다.
- 완료를 클릭합니다.
- 메시지가 표시되면 이 프로젝트 유형과 JPA 관점 창을 연결할지 여부를 선택합니다.
새 지속성 설정 파일을 만들고 구성합니다.
- Red Hat CodeReady Studio에서 EJB 3.x 프로젝트를 엽니다.
- Project Explorer 패널에서 프로젝트 루트 디렉터리를 마우스 오른쪽 버튼으로 클릭합니다.
- 새 → 기타...를 선택합니다..
- XML 폴더에서 XML File 을 선택하고 Next (다음)를 클릭합니다.
-
ejbModule/META-INF/폴더를 상위 디렉터리로 선택합니다. -
파일 이름을
persistence.xml로 지정하고 Next 를 클릭합니다. - XML 스키마 파일에서 Create XML file을 선택하고 Next (다음)를 클릭합니다.
Select XML Catalog(XML 카탈로그 선택) 항목 목록에서
http://java.sun.com/xml/ns/persistence/persistence_2.0.xsd를 선택하고 Next (다음)를 클릭합니다.그림 12.2. 지속성 XML 스키마
Finish( 완료 )를 클릭하여 파일을 만듭니다.
persistence.xml은META-INF/폴더에 생성되었으며 구성할 준비가 되었습니다.예제: 지속성 설정 파일
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 인스턴스는 다음과 같이 삽입할 수 있습니다.
예제: 엔터티 관리자 주입
12.5.1. Application-Managed EntityManager 링크 복사링크가 클립보드에 복사되었습니다!
애플리케이션 관리 엔터티 관리자는 기본 지속성 프로바이더인 org.hibernate.jpa.HibernatePersistenceProvider 에 직접 액세스할 수 있습니다. 애플리케이션 관리 엔터티 관리자의 범위는 애플리케이션이 생성되고 애플리케이션에서 종료될 때까지 지속될 때의 범위입니다. @PersistenceUnit 주석을 사용하여 애플리케이션 관리 엔터티 관리자를 반환하는 javax.persistence.EntityManagerFactory 인터페이스에 지속성 유닛을 삽입할 수 있습니다.
애플리케이션이 특정 지속성 유닛의 EntityManager 인스턴스 전체에 분산되지 않은 지속성 컨텍스트에 액세스해야 하는 경우 애플리케이션 관리 엔터티 관리자를 사용할 수 있습니다. 이 경우 각 EntityManager 인스턴스는 격리된 새 지속성 컨텍스트를 생성합니다. EntityManager 인스턴스 및 관련 PersistenceContext 는 애플리케이션에서 명시적으로 생성 및 제거됩니다. EntityManager 인스턴스가 스레드 보안이 아니므로 EntityManager 인스턴스를 직접 주입할 수 없는 경우에도 애플리케이션 관리 엔터티 관리자를 사용할 수 있습니다. EntityManagerFactory 인스턴스는 스레드 보안입니다.
예제: 애플리케이션 관리 엔터티 관리자
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 또는 를 부트스트랩하는 경우 지원되지 않습니다. 보안 관리자에게 대한 자세한 내용은 How to Configure Server Security (서버 보안 구성 방법)에서 Java Security Manager 를 참조하십시오.
SessionFactory
12.6.1. EntityManager를 JNDI에 바인딩 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 JBoss EAP는 EntityManagerFactory 를 JNDI에 바인딩하지 않습니다. jboss.entity.manager.factory 파일에서 이를 명시적으로 구성할 수 있습니다. 이 속성의 값은 .jndi.name 속성을 설정하여 애플리케이션의 persistence. xmlEntityManagerFactory 를 바인딩하려는 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"/>
<property name="jboss.entity.manager.jndi.name" value="java:/MyEntityManager"/>
<property name="jboss.entity.manager.factory.jndi.name" value="java:/MyEntityManagerFactory"/>
예제: EntityManager를 사용하여 엔터티 저장
public User createUser(User user) {
entityManager.persist(user);
return user;
}
public User createUser(User user) {
entityManager.persist(user);
return user;
}
예제: EntityManager를 사용하여 엔터티 업데이트
public void updateUser(User user) {
entityManager.merge(user);
}
public void updateUser(User user) {
entityManager.merge(user);
}
예제: EntityManager를 사용하여 엔터티 제거
public void deleteUser(String user) {
User user = findUser(username);
if (user != null)
entityManager.remove(user);
}
public void deleteUser(String user) {
User user = findUser(username);
if (user != null)
entityManager.remove(user);
}
예제: EntityManager를 사용하여 엔터티 쿼리
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 파일
예제: 지속성 설정 파일
12.8. 두 번째 수준 캐시 링크 복사링크가 클립보드에 복사되었습니다!
12.8.1. 두 번째 수준 캐시 정보 링크 복사링크가 클립보드에 복사되었습니다!
두 번째 수준 캐시는 애플리케이션 세션 외부에서 지속되는 정보를 보관하는 로컬 데이터 저장소입니다. 캐시는 애플리케이션과 별도로 데이터를 유지하여 런타임을 개선하여 지속성 프로바이더가 관리합니다.
JBoss EAP는 다음과 같은 목적으로 캐싱을 지원합니다.
- 웹 세션 클러스터링
- 상태 저장 세션 빈 클러스터링
- SSO 클러스터링
- Hibernate 두 번째 수준 캐시
- 자카르타 지속성 두 번째 수준 캐시
각 캐시 컨테이너는 repl 및 dist 캐시를 정의합니다. 이러한 캐시는 사용자 애플리케이션에서 직접 사용해서는 안 됩니다.
12.8.1.1. 기본 두 번째 수준 캐시 공급자 링크 복사링크가 클립보드에 복사되었습니다!
Infinispan은 JBoss EAP의 기본 두 번째 수준 캐시 프로바이더입니다. Infinispan은 Apache 라이센스 2.0에서 사용할 수 있는 선택적 스키마가 있는 분산 메모리 내 키/값 데이터 저장소입니다.
12.8.1.1.1. 지속성 유닛에서 두 번째 수준 캐시 구성 링크 복사링크가 클립보드에 복사되었습니다!
향후 JBoss EAP 릴리스와의 호환성을 보장하기 위해 persistence.xml 속성 덮어쓰기 대신 jenkinsfile 하위 시스템을 사용하여 캐시 구성을 사용자 지정해야 합니다.
지속성 유닛의 shared-cache-mode 요소를 사용하여 두 번째 수준 캐시를 구성할 수 있습니다.
-
Red Hat CodeReady Studio에서
persistence.xml파일을 생성하려면 Create a Simple Jakarta Persistence Application 을 참조하십시오. 다음을
persistence.xml파일에 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow SHARED_CACHE_MODE요소에는 다음 값을 사용할 수 있습니다.-
ALL: 모든 엔터티는 캐시 가능한 것으로 간주해야 합니다. -
NONE: 어떠한 엔터티도 캐시 가능한 것으로 간주해서는 안 됩니다. -
ENABLE_SELECTIVE: 캐시 가능으로 표시된 엔터티만 캐시 가능으로 간주해야 합니다. -
DISABLE_SELECTIVE: not cacheable로 명시적으로 표시된 엔터티를 제외한 모든 엔터티는 캐시 가능으로 간주되어야 합니다. -
지정되지 않음: 동작이 정의되지 않았습니다. 공급자별 기본값은 적용 가능합니다.
-
예제: persistence.xml을 사용하여 엔터티 및 로컬 쿼리 캐시의 속성 변경
| 속성 | 설명 |
|---|---|
|
| 개체 메모리 크기를 나타냅니다. |
|
| 캐시 항목이 캐시에서 유지 관리되는 최대 유휴 시간(밀리초)을 나타냅니다. |
|
| 캐시 항목이 만료된 후 최대 수명(밀리초)을 나타냅니다. 기본값은 60초입니다. 무한한 수명을 -1을 사용하여 지정할 수 있습니다. |
|
| 캐시에서 만료된 항목을 제거하기 위해 후속 실행 간 간격(밀리초)을 나타냅니다. -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 사양에 정의된 유효성 검사 제한 조건이 포함되어 있습니다.
| 주석 | 속성 유형 | 런타임 검사 | Hibernate 메타데이터 영향 |
|---|---|---|---|
| @AssertFalse | 부울 | 메서드가 false로 평가되는지 확인합니다. 주석이 아닌 코드로 표현된 제약 조건에 유용합니다. | 없음. |
| @AssertTrue | 부울 | 메서드가 true로 평가되는지 확인합니다. 주석이 아닌 코드로 표현된 제약 조건에 유용합니다. | 없음. |
| @Digits(integerDigits=1) | 숫자의 숫자 또는 문자열 표시 |
속성이 정수Digits | 열 정확도 및 스케일링을 정의합니다. |
| @Future | 날짜 또는 일정 | 날짜가 향후 상태인지 확인합니다. | 없음. |
| @Max(value=) | 숫자의 숫자 또는 문자열 표시 | 값이 max보다 작거나 같은지 확인합니다. | 열에 검사 제한 조건을 추가합니다. |
| @Min(value=) | 숫자의 숫자 또는 문자열 표시 | 값이 Min보다 크거나 같은지 확인합니다. | 열에 검사 제한 조건을 추가합니다. |
| @NotNull | 값이 null이 아닌지 확인합니다. | 열은 null이 아닙니다. | |
| @Past | 날짜 또는 일정 | 날짜가 과거인지 확인합니다. | 열에 검사 제한 조건을 추가합니다. |
| @Pattern(regexp="regexp", flag=) or @Patterns( {@Pattern(…)} ) | 문자열 |
속성에 일치하는 플래그가 지정된 정규 표현식과 일치하는지 확인합니다. | 없음. |
| @Size(min=, max=) | 배열, 컬렉션, 맵 | 요소 크기가 min과 max 사이의지, 두 값 모두 포함된지 확인합니다. | 없음. |
| @Valid | 개체 | 연결된 오브젝트에서 검증을 재귀적으로 수행합니다. 오브젝트가 Collection 또는 array인 경우 요소가 재귀적으로 검증됩니다. 오브젝트가 Map인 경우 값 요소의 유효성이 재귀적으로 확인됩니다. | 없음. |
@Valid 매개변수는 javax.validation.constraints 패키지에 있더라도 Jakarta Bean Validation 사양의 일부입니다.
Hibernate Validator별 검증 제한
다음 표에는 org.hibernate.validator.constraints 패키지의 일부인 벤더별 유효성 검사 제한 조건이 포함되어 있습니다.
| 주석 | 속성 유형 | 런타임 검사 | Hibernate 메타데이터 영향 |
|---|---|---|---|
| @Length(min=, max=) | 문자열 | 문자열 길이가 범위와 일치하는지 확인합니다. | 열 길이는 max로 설정됩니다. |
| @CreditCardNumber | 문자열 | 문자열이 잘 포맷된 신용 카드 번호인지, Luhn 알고리즘의 파생인지 확인하십시오. | 없음. |
| @EAN | 문자열 | 문자열이 올바른 형식의 EAN인지 또는 UPC-A 코드인지 확인합니다. | 없음. |
| | 문자열 | 문자열이 전자 메일 주소 사양을 준수하는지 확인합니다. | 없음. |
| @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 클래스에 정의된 사용자 지정 제약 조건 집합을 사용하여 엔터티 Person 의 personAddress 필드가 검증되었음을 보여줍니다.
엔터티
Person을 만듭니다.예제:
개인수업Copy to Clipboard Copied! Toggle word wrap Toggle overflow 제약 조건 유효성 검사기 파일을 생성합니다.
예제:
주소인터페이스Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예제:
PersonAddress클래스Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.2.3.2. 제약 조건 검증기 구현 링크 복사링크가 클립보드에 복사되었습니다!
주석을 정의한 경우 @Address 주석을 사용하여 요소를 검증할 수 있는 제한 조건 검증기를 생성해야 합니다. 이렇게 하려면 interface ConstraintValidator 를 다음과 같이 구현하십시오.
예제: AddressValidator Class
13.3. Jakarta Bean Validation Configuration 링크 복사링크가 클립보드에 복사되었습니다!
/META-INF 디렉터리에 있는 validation.xml 파일에서 XML 설명자를 사용하여 Jakarta Bean Validation을 구성할 수 있습니다. 이 파일이 클래스 경로에 있는 경우 ValidatorFactory 가 생성될 때 해당 구성이 적용됩니다.
예제: Jakarta Bean Validation Configuration 파일
다음 예제에서는 validation.xml 파일의 여러 구성 옵션을 보여줍니다. 모든 설정은 선택 사항입니다. 이러한 옵션은 javax.validation 패키지를 사용하여 구성할 수도 있습니다.
노드 default-provider 를 사용하면 Jakarta Bean Validation 공급자를 선택할 수 있습니다. 이는 클래스 경로에 공급자가 두 개 이상 있는 경우 유용합니다. message-interpolator 및 constraint -validator-factory 속성은 javax.validation 패키지에 정의된 MessageInterpolator 및 ConstraintValidatorFactory 인터페이스에 사용된 구현을 사용자 지정하는 데 사용됩니다. 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 애플리케이션의 간단한 예입니다. 다른 기능을 구현하지 않거나 실제 애플리케이션에 필요한 오류 처리를 포함하지 않습니다.
JavaScript HTML 클라이언트를 만듭니다.
다음은 자카르타 WebSocket 클라이언트의 예입니다. 여기에는 다음과 같은 JavaScript 기능이 포함되어 있습니다.
-
connect(): 이 기능은 자카르타 WebSocket URI를 전달하여 자카르타 WebSocket 연결을 생성합니다. 리소스 위치는 서버 엔드포인트 클래스에 정의된 리소스와 일치합니다. 이 기능은 또한 open, onmessage가로채고 처리합니다., onerror 및 onclose에서 Jakarta WebSocket을 -
sendMessage(): 이 함수는 양식에 입력한 이름을 가져오고 메시지를 생성한 다음 WebSocket.send() 명령을 사용하여 전송합니다. -
disconnect(): 이 함수는 WebSocket.close() 명령을 실행합니다. -
displayMessage(): 이 함수는 페이지에 표시 메시지를 Jakarta WebSocket endpoint 메서드에서 반환한 값으로 설정합니다. displayStatus(): 이 기능은 자카르타 WebSocket 연결 상태를 표시합니다.예제: 애플리케이션
index.html코드Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
자카르타 WebSocket 서버 엔드포인트를 만듭니다.
다음 방법 중 하나를 사용하여 Jakarta WebSocket 서버 끝점을 만들 수 있습니다.
-
프로그래밍 엔드 포인트: 엔드포인트는 엔드포인트 클래스를 확장합니다. -
주석이 있는 엔드 포인트: 엔드포인트 클래스는 주석을 사용하여 자카르타 WebSocket 이벤트와 상호 작용합니다. 프로그래밍 끝점보다 코딩하는 것이 더 간단합니다.
아래 코드 예제에서는 주석이 지정된 엔드포인트 접근법을 사용하고 다음 이벤트를 처리합니다.
-
@ServerEndpoint주석은 이 클래스를 자카르타 WebSocket 서버 엔드포인트로 식별하고 경로를 지정합니다. -
자카르타 WebSocket 연결이 열리면
@OnOpen주석이 트리거됩니다. -
메시지가 수신되면
@OnMessage주석이 트리거됩니다. 자카르타 WebSocket 연결이 닫히면
@OnClose주석이 트리거됩니다.예제: 자카르타 웹소켓 엔드 포인트 코드
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
프로젝트 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>
<dependency> <groupId>org.jboss.spec.javax.websocket</groupId> <artifactId>jboss-websocket-api_1.1_spec</artifactId> <scope>provided</scope> </dependency>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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에서 보안 도메인을 구성하는 것이 좋습니다.
예제: 자카르타 인증을 통한 보안 도메인
자카르타 인증을 사용하도록 웹 애플리케이션 구성
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>
<jboss-web>
<security-domain>jacc</security-domain>
<use-jboss-authorization>true</use-jboss-authorization>
</jboss-web>
자카르타 인증을 사용하도록 자카르타 엔터프라이즈 빈 애플리케이션 구성
보안 도메인을 사용하도록 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 에 설명되어 있습니다.
예제: 자카르타 엔터프라이즈 빈에서 자카르타 인증 방법 사용 권한
또한 웹 애플리케이션의 경우와 마찬가지로 보안 도메인을 사용하여 Jakarta Enterprise Bean의 인증 및 권한 부여 메커니즘을 제한할 수 있습니다. 보안 도메인은 <security> 하위 요소의 jboss-ejb3.xml 설명자에 선언됩니다. 보안 도메인 외에도 <run-as-principal> 을 지정하여 Jakarta Enterprise Beans가 실행되는 주체를 변경할 수도 있습니다.
예제: Jakarta Enterprise Bean의 보안 도메인 선언
elytron 하위 시스템을 사용하여 자카르타 권한 부여 활성화
레거시 보안 하위 시스템에서 자카르타 인증 비활성화
기본적으로 애플리케이션 서버는 레거시 보안 하위 시스템을 사용하여 Jakarta Authorization 정책 프로바이더 및 팩토리를 구성합니다. 기본 구성은 PicketBox의 구현으로 매핑됩니다.
Elytron을 사용하여 Jakarta Authorization 구성을 관리하거나 애플리케이션 서버에 설치하려는 기타 모든 정책을 관리하려면 먼저 레거시 보안 하위 시스템에서 Jakarta Authorization을 비활성화해야 합니다. 이를 위해 다음 관리 CLI 명령을 사용할 수 있습니다.
/subsystem=security:write-attribute(name=initialize-jacc, value=false)
/subsystem=security:write-attribute(name=initialize-jacc, value=false)
이렇게 하지 않으면 서버 로그에 다음과 같은 오류가 발생할 수 있습니다. MSC000004: org.wildfly.security.policy 서비스 중지 중에 오류가 발생했습니다: java.lang.StackOverflowError.
자카르타 인증 정책 공급자 정의
elytron 하위 시스템은 Jakarta Authorization 사양을 기반으로 기본 제공 정책 프로바이더를 제공합니다. 정책 공급자를 생성하려면 다음 관리 CLI 명령을 실행할 수 있습니다.
/subsystem=elytron/policy=jacc:add(jacc-policy={})
reload
/subsystem=elytron/policy=jacc:add(jacc-policy={})
reload
웹 배포에 대한 자카르타 인증 활성화
Jakarta Authorization 정책 공급자가 정의되면 다음 명령을 실행하여 웹 배포에 대해 Jakarta Authorization을 활성화할 수 있습니다.
/subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain,enable-jacc=true)
/subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain,enable-jacc=true)
위의 명령은 jboss-web.xml 파일에 제공되지 않는 경우 애플리케이션의 기본 보안 도메인을 정의합니다. 이미 application-security-domain 이 정의되어 있고 Jakarta Authorization을 활성화하려는 경우 다음 명령을 실행할 수 있습니다.
/subsystem=undertow/application-security-domain=my-security-domain:write-attribute(name=enable-jacc,value=true)
/subsystem=undertow/application-security-domain=my-security-domain:write-attribute(name=enable-jacc,value=true)
자카르타 엔터프라이즈 빈 배포에 대한 자카르타 인증 활성화
Jakarta Authorization 정책 공급자가 정의되면 다음 명령을 실행하여 Jakarta Enterprise Beans 배포에 대한 Jakarta Authorization Authorization을 활성화할 수 있습니다.
/subsystem=ejb3/application-security-domain=other:add(security-domain=ApplicationDomain,enable-jacc=true)
/subsystem=ejb3/application-security-domain=other:add(security-domain=ApplicationDomain,enable-jacc=true)
위의 명령은 Jakarta Enterprise Bean의 기본 보안 도메인을 정의합니다. 이미 application-security-domain 이 정의되어 있고 Jakarta Authorization을 활성화하려는 경우 다음과 같이 명령을 실행할 수 있습니다.
/subsystem=ejb3/application-security-domain=my-security-domain:write-attribute(name=enable-jacc,value=true)
/subsystem=ejb3/application-security-domain=my-security-domain:write-attribute(name=enable-jacc,value=true)
사용자 지정 Elytron 정책 공급자 생성
사용자 지정 정책 프로바이더는 권한을 확인하기 위해 일부 외부 인증 서비스와 통합하려는 경우와 같이 사용자 지정 java.security.Policy 가 필요할 때 사용됩니다. 사용자 지정 정책 프로바이더를 생성하려면 java.security.Policy 를 구현하고, 구현을 통해 사용자 지정 모듈을 생성 및 연결하며 elytron 하위 시스템의 모듈에서 구현을 사용해야 합니다.
/subsystem=elytron/policy=policy-provider-a:add(custom-policy={class-name=MyPolicyProviderA, module=x.y.z})
/subsystem=elytron/policy=policy-provider-a:add(custom-policy={class-name=MyPolicyProviderA, module=x.y.z})
자세한 내용은 정책 공급자 속성을 참조하십시오.
대부분의 경우 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 요소 구조
로그인 모듈 자체는 표준 인증 모듈과 동일한 방식으로 구성됩니다.
웹 기반 관리 콘솔은 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 또는 과 연결해야 합니다. 이렇게 하면 배포에 사용할 Elytron 보안 핸들러가 설치되고 배포에 대해 Elytron 보안 프레임워크가 활성화됩니다.
security- domain
배포에 대해 Elytron 보안 프레임워크가 활성화되면 요청이 처리될 때 전역적으로 등록된 AuthConfigFactory 가 쿼리됩니다. 해당 배포에 사용해야 하는 AuthConfigProvider 가 등록되었는지 확인합니다. AuthConfigProvider 가 있는 경우 배포 인증 구성 대신 JASPI 인증이 사용됩니다. AuthConfigProvider 를 찾을 수 없는 경우 배포에 대한 인증 구성이 대신 사용됩니다. 이로 인해 다음과 같은 세 가지 가능성 중 하나가 발생할 수 있습니다.
-
http-authentication-factory의 인증 메커니즘 사용. -
web.xml에 지정된 메커니즘 사용. - 애플리케이션에 정의된 메커니즘이 없는 경우 인증이 수행되지 않습니다.
AuthConfigFactory 에 수행된 업데이트는 즉시 사용할 수 있습니다. 즉 AuthConfigProvider 가 등록되고 기존 애플리케이션과 일치하는 경우 애플리케이션을 재배포할 필요 없이 즉시 사용할 수 있습니다.
JBoss EAP에 배포된 모든 웹 애플리케이션에는 보안 도메인이 있으며, 다음 순서로 해결됩니다.
- 배포 설명자 또는 주석에서 다음을 수행합니다.
-
undertow하위 시스템의default-security-domain특성에 정의된 값입니다. -
기본값은
other입니다.
이 보안 도메인은 PicketBox 보안 도메인에 대한 참조라고 가정하므로 활성화의 최종 단계는 undertow 하위 시스템에서 application-security-domain 리소스를 사용하여 Elytron에 매핑되도록 합니다.
이 매핑은 다음 중 하나를 수행할 수 있습니다.
예를 들면
다음과같습니다./subsystem=undertow/application-security-domain=MyAppSecurity:add(security-domain=ApplicationDomain)
/subsystem=undertow/application-security-domain=MyAppSecurity:add(security-domain=ApplicationDomain)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 인증 메커니즘 인스턴스를 가져오려면
http-authentication-factory리소스를 참조합니다. 예를 들면 다음과 같습니다./subsystem=undertow/application-security-domain=MyAppSecurity:add(http-authentication-factory=application-http-authentication)
/subsystem=undertow/application-security-domain=MyAppSecurity:add(http-authentication-factory=application-http-authentication)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Jakarta Authentication 통합을 활성화하기 위한 최소 단계는 다음과 같습니다.
-
default-security-domain속성이 기본적으로다른사용자로 설정되도록undertow 하위 시스템에서정의되지 않은 상태로 둡니다. -
다른항목의application-security-domain매핑을 Elytron 보안 도메인에 추가합니다.
이러한 단계에서 배포와 연결된 보안 도메인은 인증에 사용되는 ServerAuthModule 인스턴스로 전달될 콜백Handler 로 래핑되는 보안 도메인입니다.
추가 옵션
Jakarta Authentication 동작을 추가로 제어할 수 있도록 두 개의 추가 특성이 application-security-domain 리소스에 추가되었습니다.
| 속성 | 설명 |
|---|---|
|
|
이 매핑을 사용하는 모든 배포에 대한 Jakarta Authentication 지원을 비활성화하려면 |
|
|
기본적으로 모든 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}])
/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}])
이렇게 하면 다음과 같은 구성이 지속됩니다.
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();
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();
예를 들어 서블릿의 init() 메서드 내에서 이 코드를 실행하여 해당 배포에 고유한 AuthConfigProvider 를 등록할 수 있습니다. 이 코드 예제에서는 ServletContext 를 컨설팅하여 애플리케이션 컨텍스트도 어셈블했습니다.
register() 메서드는 AuthConfigFactory 에서 이 등록을 직접 제거하는 데 사용할 수도 있는 결과 등록 ID를 반환합니다.
하위 시스템 구성과 마찬가지로 이 호출은 Elytron 보안 프레임워크를 사용하는 모든 웹 애플리케이션에 즉시 적용됩니다.
인증 프로세스
undertow 하위 시스템에서 application-security-domain 리소스의 구성에 따라 ServerAuthModule 에 전달된 CallbackHandler 는 다음 모드 중 하나에서 작동할 수 있습니다.
통합 모드
통합 모드에서 작동하는 경우 ServerAuthModule 인스턴스가 실제 인증을 처리하지만 해당 SecurityDomain에서 참조하는 Security 에서 생성된 ID가 로드됩니다 Realms를 사용하여 참조된 Security Domain. 이 모드에서는 서블릿 컨테이너 내에서 할당할 역할을 재정의할 수 있습니다.
이 모드의 장점은 ServerAuthModule이 ID 로드를 위한 Elytron 구성을 활용하여 데이터베이스 및 LDAP와 같은 일반적인 위치에 저장된 ID를 로드할 수 있다는 것입니다. ServerAuthModule 은 이러한 위치를 인식할 필요가 없습니다. 또한 역할 및 권한 매핑과 같은 기타 Elytron 구성을 적용할 수 있습니다. 참조된 SecurityDomain 은 SASL 인증 또는 기타 비 JASPI 애플리케이션에 대해 참조할 수도 있으며, 모두 공통 ID 저장소에서 지원합니다.
| 작업 | 설명 |
|---|---|
|
|
사용자 이름과 암호는 인증을 수행하기 위해 |
|
|
이 참고
null 주체 및 이름을 사용하여
익명 ID에 대한 권한 부여가 수행되는 경우 익명 ID에 |
|
|
이 모드에서는 보안 도메인에 구성된 로드, 역할 디코딩 및 역할 매핑이 ID를 설정하는 데 사용됩니다. 이 |
통합되지 않은 모드
통합되지 않은 모드에서 작동하는 경우 ServerAuthModule은 모든 인증 및 ID 관리를 완벽하게 담당합니다. 지정된 콜백을 사용하여 ID를 설정할 수 있습니다. 결과 ID는 SecurityDomain 에서 생성되지만 참조된 SecurityRealms 에 저장된 ID와 독립적입니다.
이 모드의 장점은 간단한 SecurityDomain 정의를 넘어 어떤 것도 요구하지 않고도 ID를 완전히 처리할 수 있는 JASPI 구성을 애플리케이션 서버에 배포할 수 있다는 점입니다. 이 SecurityDomain 에는 런타임 시 사용할 ID를 실제로 포함할 필요가 없습니다. 이 모드의 단점은 이제 ServerAuthModule 이 모든 ID 처리를 담당하므로 구현이 훨씬 더 복잡해질 수 있다는 것입니다.
| 작업 | 설명 |
|---|---|
|
|
이 모드에서는 |
|
|
이
|
|
|
|
validateRequest
ServerAuthContext 에서 validateRequest 를 호출하는 동안 개별 ServerAuthModule 인스턴스가 정의된 순서대로 호출됩니다. 각 모듈에 대해 컨트롤 플래그를 지정할 수도 있습니다. 이 플래그는 응답을 해석하는 방법과 처리가 다음 서버 인증 모듈로 계속 진행되어야 하는지 또는 즉시 반환해야 하는지 정의합니다.
컨트롤 플래그
구성이 elytron 하위 시스템 내에서 제공되거나 JaspiConfigurationBuilder API를 사용하는지 여부에 따라 컨트롤 플래그를 각 ServerAuthModule 과 연결할 수 있습니다. 지정하지 않으면 기본값은 REQUIRED 입니다. 플래그에는 결과에 따라 다음과 같은 의미가 있습니다.
| 플래그 | AuthStatus.SEND_SUCCESS | AuthStatus.SEND_FAILURE, AuthStatus.SEND_CONTINUE |
|---|---|---|
| 필수 항목 | 검증은 나머지 모듈로 계속됩니다. 나머지 모듈의 요구 사항이 충족되면 요청을 계속할 수 있습니다. | 검증은 나머지 모듈로 계속됩니다. 그러나 결과에 관계없이 검증에 성공하지 않고 제어 권한이 클라이언트로 돌아갑니다. |
| 필수 사항 | 검증은 나머지 모듈로 계속됩니다. 나머지 모듈의 요구 사항이 충족되면 요청을 계속할 수 있습니다. | 요청은 즉시 클라이언트로 반환됩니다. |
| 충분하지 않음 |
검증은 이전에 |
검증을 통해 나머지 모듈 목록이 계속 중단됩니다. 이 상태는 |
| 선택 사항 |
검증은 |
검증을 통해 나머지 모듈 목록이 계속 중단됩니다. 이 상태는 |
모든 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 의 결과로 생성됩니다. 콜백에 따라 콜백에서 설명하는 임시 ID가 됩니다. 이 SecurityDomain 에서 직접 로드된 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 하위 시스템을 구성해야 합니다.
레거시
보안하위 시스템에서 자카르타 권한 부여를 비활성화합니다. Jakarta Authorization이 이미 Elytron에서 관리되도록 구성된 경우 이 단계를 건너뜁니다./subsystem=security:write-attribute(name=initialize-jacc, value=false)
/subsystem=security:write-attribute(name=initialize-jacc, value=false)Copy to Clipboard Copied! Toggle word wrap Toggle overflow OR
lyron하위 시스템에서 자카르타 권한 부여 정책 프로바이더를 정의하고 서버를 다시 로드합니다./subsystem=elytron/policy=jacc:add(jacc-policy={}) reload/subsystem=elytron/policy=jacc:add(jacc-policy={}) reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
웹 애플리케이션의 자카르타 보안 활성화
웹 애플리케이션에 자카르타 보안을 사용하려면 웹 애플리케이션을 Elytron http-authentication-factory 또는 과 연결해야 합니다. 그러면 Elytron 보안 핸들러가 설치되고 배포에 대한 Elytron 보안 프레임워크가 활성화됩니다.
security- domain
Jakarta Security를 활성화하기 위한 최소 단계는 다음과 같습니다.
-
default-security-domain속성이 기본적으로다른사용자로 설정되도록undertow 하위 시스템에서정의되지 않은 상태로 둡니다. 다른항목의application-security-domain매핑을 Elytron 보안 도메인에 추가합니다./subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain, integrated-jaspi=false)
/subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain, integrated-jaspi=false)Copy to Clipboard Copied! Toggle word wrap Toggle overflow integrated-jaspi를false로 설정하면애드혹 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 배치 종속성
18.2. JSL(작업 사양 언어) 상속 링크 복사링크가 클립보드에 복사되었습니다!
JBoss EAP batch-jberet 하위 시스템의 기능은 작업 정의의 일반적인 부분을 추상화하기 위해 JSL(작업 사양 언어) 상속을 사용하는 기능입니다.
동일한 작업 XML 파일 내의 단계 및 흐름 상속
상위 요소(예: step 및 flow)는 직접 실행하지 못하도록 abstract="true" 속성으로 표시됩니다. 하위 요소에는 상위 요소를 가리키는 상위 속성이 포함됩니다.
다른 작업 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>
<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>
예: chunk-parent.xml
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>
<batchlet ref="myBatchlet">
<properties>
<property name="number" value="10"/>
</properties>
</batchlet>
예제: 아티팩트 클래스
임의의 배열로 Batchlet 클래스에 숫자 시퀀스 삽입
예제: 작업 XML 파일
<batchlet ref="myBatchlet">
<properties>
<property name="weekDays" value="1,2,3,4,5,6,7"/>
</properties>
</batchlet>
<batchlet ref="myBatchlet">
<properties>
<property name="weekDays" value="1,2,3,4,5,6,7"/>
</properties>
</batchlet>
예제: 아티팩트 클래스
배치 클래스에 클래스 속성 삽입
예제: 작업 XML 파일
<batchlet ref="myBatchlet">
<properties>
<property name="myClass" value="org.jberet.support.io.Person"/>
</properties>
</batchlet>
<batchlet ref="myBatchlet">
<properties>
<property name="myClass" value="org.jberet.support.io.Person"/>
</properties>
</batchlet>
예제: 아티팩트 클래스
속성 주입을 위해 주석이 있는 필드에 기본값 할당
타겟 배치 속성이 작업 XML 파일에 정의되지 않은 경우 아티팩트 Java 클래스의 필드에 기본값을 할당할 수 있습니다. target 속성이 유효한 값으로 확인되면 해당 속성이 해당 필드에 삽입됩니다. 그렇지 않으면 값이 삽입되지 않고 기본 필드 값이 사용됩니다.
예제: 아티팩트 클래스
19장. 클라이언트 구성 링크 복사링크가 클립보드에 복사되었습니다!
19.1. wildfly-config.xml 파일을 사용한 클라이언트 설정 링크 복사링크가 클립보드에 복사되었습니다!
JBoss EAP 7.1은 모든 클라이언트 구성을 하나의 구성 파일로 통합하기 위한 와일드플ly -config.xml 파일을 도입했습니다.
다음 표는 JBoss EAP에서 the wildfly-config.xml 파일을 사용하여 수행할 수 있는 클라이언트 및 구성 유형과 각 구성의 참조 스키마 링크에 대한 링크를 설명합니다.
| 클라이언트 설정 | 스키마 위치/구성 정보 |
|---|---|
| 인증 클라이언트 |
스키마 참조는 스키마는 http://www.jboss.org/schema/jbossas/elytron-client-1_2.xsd 에도 게시되어 있습니다. |
|
자세한 내용 및 구성 예는 the 자세한 내용은 JBoss EAP에 대한 ID 관리 구성 방법의 Elytron Client로 클라이언트 인증 구성에서 확인할 수 있습니다. | |
| Jakarta Enterprise Beans 클라이언트 |
스키마 참조는 스키마는 http://www.jboss.org/schema/jbossas/wildfly-client-ejb_3_0.xsd 에도 게시되어 있습니다. |
|
자세한 내용 및 구성에 대한 자세한 내용은 Jakarta Enterprise Beans Client Configuration Using the 또 다른 간단한 예는 JBoss EAP 의 마이그레이션 가이드의 Jakarta Enterprise Bean Client에서 Elytron 으로 마이그레이션 섹션에 있습니다. | |
| HTTP 클라이언트 |
스키마 참조는 스키마는 http://www.jboss.org/schema/jbossas/wildfly-http-client_1_0.xsd 에도 게시되어 있습니다. |
| 참고 이 기능은 기술 프리뷰로 만 제공됩니다.
자세한 내용 및 구성 예는 HTTP 클라이언트 구성을 | |
| 클라이언트 원격화 |
스키마 참조는 스키마는 http://www.jboss.org/schema/jbossas/jboss-remoting_5_0.xsd 에도 게시되어 있습니다. |
|
자세한 내용 및 구성에 | |
| XNIO 작업자 클라이언트 |
스키마 참조는 스키마는 http://www.jboss.org/schema/jbossas/xnio_3_5.xsd 에도 게시되어 있습니다. |
|
자세한 내용 및 구성에 대한 자세한 내용은 기본 XNIO 작업자 구성에서 the |
19.1.1. wildfly-config.xml 파일을 사용한 클라이언트 인증 구성 링크 복사링크가 클립보드에 복사되었습니다!
urn:elytron: 요소를 사용하여 client:1.2 네임스페이스에 있는 authentication- clientwildfly-config.xml 파일을 사용하여 클라이언트 인증 정보를 구성할 수 있습니다. 이 섹션에서는 이 요소를 사용하여 클라이언트 인증을 구성하는 방법에 대해 설명합니다.
인증-클라이언트 요소 및 속성
authentication-client 요소에는 하위 요소와 함께 다음 최상위 하위 요소를 선택적으로 포함할 수 있습니다.
credential-stores이 선택적 요소는 구성의 다른 위치에서 참조되는 인증 정보 저장소를 구성 내에 자격 증명을 포함하는 대안으로 정의합니다.
원하는 수의
자격 증명 저장소요소를 포함할 수 있습니다.예:
credentials-stores구성Copy to Clipboard Copied! Toggle word wrap Toggle overflow
credential-store이 요소는 구성의 다른 위치에서 참조되는 자격 증명 저장소를 정의합니다.
다음과 같은 특성이 있습니다.
Expand 특성 이름 특성 설명 name
자격 증명 저장소의 이름입니다. 이 속성은 필수입니다.
type
자격 증명 저장소 유형입니다. 이 속성은 선택 사항입니다.
공급자
자격 증명 저장소를 로드하는 데 사용할
java.security.Provider의 이름입니다. 이 속성은 선택 사항입니다.다음 하위 요소 중 하나와 하나만 포함할 수 있습니다.
속성이 요소는 자격 증명 저장소를 초기화하는 데 사용되는 구성 속성을 정의하며 구성에 필요한 만큼 반복될 수 있습니다.
예:
특성구성<attributes> <attribute name="..." value="..." /> </attributes>
<attributes> <attribute name="..." value="..." /> </attributes>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
protection-parameter-credentials이 요소에는 자격 증명 저장소를 초기화할 때 사용할 보호 매개 변수로 조합할 하나 이상의 자격 증명이 포함되어 있습니다.
인증 정보 저장소 구현에 따라 하나 이상의 다음 하위 요소를 포함할 수 있습니다.
예:
protection-parameter-credentials구성Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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>
<key-store-reference key-store-name="..." alias="..."> <key-store-clear-password password="..." /> <key-store-credential>...</key-store-credential> </key-store-reference>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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이 선택적 요소는 구성의 다른 위치에서 참조되는 키 저장소를 정의합니다.
예:
키 저장소구성Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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>
<key-store-credential key-store-name="..." alias="..."> <key-store-clear-password password="..." /> <key-store-credential>...</key-store-credential> </key-store-credential>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
authentication-rules이 요소는 아웃바운드 연결과 일치하는 규칙을 정의하여 적절한 인증 구성을 적용합니다.
인증 구성이 필요한경우 액세스한 리소스의 URI와 선택적 추상 유형 및 추상 유형 기관이 구성에 정의된 규칙과 일치하여사용할 인증구성을 식별합니다.이 요소에는 하나 이상의 하위
규칙요소가 포함될 수 있습니다.예:
authentication-rules구성Copy to Clipboard Copied! Toggle word wrap Toggle overflow
규칙이 요소는 아웃바운드 연결과 일치하는 규칙을 정의하여 적절한 인증 구성을 적용합니다.
다음과 같은 속성이 있습니다.
Expand 특성 이름 특성 설명 use-configuration
규칙이 일치할 때 선택되는 인증 구성입니다.
인증 구성 규칙 일치는 SSL 컨텍스트 규칙 일치와 독립적입니다. 인증 규칙 구조는 SSL 컨텍스트 규칙 구조와 동일합니다. 단, SSL 컨텍스트 규칙은 SSL 컨텍스트 규칙을 참조합니다.
다음 하위 요소를 포함할 수 있습니다.
예: 인증을 위한
규칙구성Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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구성Copy to Clipboard Copied! Toggle word wrap Toggle overflow
설정이 요소는 인증 규칙에 따라 선택할 명명된 인증 구성을 정의합니다.
다음 하위 요소를 포함할 수 있습니다.
-
선택적
set-host-name,set-port-number및set-protocol요소는 대상을 재정의할 수 있습니다. -
선택적
set-user-name및set-anonymous요소는 상호 배타적이며 인증을 위해 이름을 설정하거나 익명 인증으로 전환하는 데 사용할 수 있습니다. -
다음으로
set-mechanism-realm-name, rewrite-user-name-regex,sasl-mechanism-selector,set-mechanism-properties,credentials,set-authorization-name및provider선택적 요소입니다. -
마지막 옵션인
use-provider-sasl-factory및use-service-loader-sasl-factory요소는 상호 배타적이며 인증을 위해 SASL 메커니즘 팩토리가 검색되는 방식을 정의합니다.
-
선택적
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.ElytronAuthenticator가java.net.Authenticator.setDefault(Authenticator)에 등록됩니다. 이를 통해 인증이 필요한 HTTP 호출에 JDK API를 사용할 때 Elytron 인증 클라이언트 구성을 인증에 사용할 수 있습니다.참고JDK는 JVM에서 첫 번째 호출 시 인증을 캐시하므로 동일한 URI에 대한 다른 호출에 다른 자격 증명이 필요하지 않은 독립 실행형 프로세스에서만 이 방법을 사용하는 것이 좋습니다.
ssl-context-rules이 선택적 요소는 SSL 컨텍스트 규칙을 정의합니다.
ssl-context가 필요한 경우 액세스한 리소스의 URI와 선택적 추상 유형 및 추상 유형 권한이 구성에 정의된 규칙과 일치하여 사용해야 하는ssl-context를 식별합니다.이 요소에는 하나 이상의 하위
규칙요소가 포함될 수 있습니다.예:
ssl-context-rules구성Copy to Clipboard Copied! Toggle word wrap Toggle overflow
규칙이 요소는 SSL 컨텍스트 정의와 일치하는 규칙을 정의합니다.
다음과 같은 속성이 있습니다.
Expand 특성 이름 특성 설명 use-ssl-context
규칙이 일치할 때 선택하는 SSL 컨텍스트 정의입니다.
SSL 컨텍스트 규칙 일치는 인증 규칙 일치와 독립적입니다. SSL 컨텍스트 규칙 구조는 SSL 컨텍스트를 참조하는 반면 인증 규칙은 인증 구성을 참조한다는 점을 제외하고는 인증 구성 규칙 구조와 동일합니다.
다음 하위 요소를 포함할 수 있습니다.
예: SSL 컨텍스트에 대한
규칙구성Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ssl-contexts이 선택적 요소는 SSL 컨텍스트 규칙에 의해 선택할 SSL 컨텍스트 정의를 정의합니다.
예:
ssl-contexts구성Copy to Clipboard Copied! Toggle word wrap Toggle overflow
default-ssl-context-
이 요소는
javax.net.ssl.SSLContext.getDefault()에서반환한 SSLContext를 가져와ssl-context-rules에서 참조할 수 있도록 이름을 할당합니다. 이 요소는 반복할 수 있습니다. 즉, 다른 이름을 사용하여 기본 SSL 컨텍스트를 참조할 수 있습니다.
ssl-context이 요소는 연결에 사용할 SSL 컨텍스트를 정의합니다.
선택적으로 다음 하위 요소 중 하나를 포함할 수 있습니다.
key-store-ssl-certificate이 요소는 이 SSL 컨텍스트에 사용할 키 저장소 내의 항목에 대한 참조를 정의합니다.
다음과 같은 특성이 있습니다.
Expand 특성 이름 특성 설명 key-store-name
키 저장소 이름입니다. 이 속성은 필수입니다.
alias
참조된 키 저장소에서 로드할 항목의 별칭입니다. 이는 단일 항목만 포함하는 키 저장소에만 대해 생략할 수 있습니다.
다음과 같은 하위 요소를 포함할 수 있습니다.
이 구조는
키 저장소-자격 증명구성에 사용되는 구조와 거의 동일합니다. 여기서 키 및 인증서에 대한 항목을 가져옵니다. 그러나 중첩된key-store-clean-password및key-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>
<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 Copied! Toggle word wrap Toggle overflow
trust-store이 요소는
TrustManager를 초기화하는 데 사용되는 키 저장소에 대한 참조입니다.다음과 같은 속성이 있습니다.
Expand 특성 이름 특성 설명 key-store-name
키 저장소 이름입니다. 이 속성은 필수입니다.
cipher-suite이 요소는 활성화된 암호화 제품군에 대한 필터를 구성합니다.
다음과 같은 속성이 있습니다.
Expand 특성 이름 특성 설명 선택기
암호화 제품군을 필터링하는 선택기입니다. 선택기는
org.wildfly.security.ssl.CipherSuiteSelector.fromString(selector)메서드로 생성된 OpenSSL 스타일 암호 목록 문자열의 형식을 사용합니다.예: 기본 필터링을 사용하는
암호화-강의 구성<cipher-suite selector="DEFAULT" />
<cipher-suite selector="DEFAULT" />Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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의 구성 섹션은 서로 독립적이므로 다음 위치에서 이 요소를 구성할 수 있습니다.예제:
공급자구성의 위치Copy to Clipboard Copied! Toggle word wrap Toggle overflow 프로바이더구성은 재정의되지 않는 한 정의된 요소와 하위 요소에 모두 적용됩니다. 하위 요소의공급자사양은 상위 요소에 지정된프로바이더를 재정의합니다.공급자구성이 지정되지 않은 경우 기본 동작은 다음과 같습니다. 이는 전 세계에 등록된 공급자에 대해 Elytron 공급자 우선 순위를 부여하지만 세계적으로 등록된 공급자를 사용할 수도 있습니다.예:
공급자구성<providers> <use-service-loader /> <global /> </providers>
<providers> <use-service-loader /> <global /> </providers>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
global-
이 빈 요소는
java.security.Security.getProviders()메서드 호출로 로드된 글로벌 공급자를 사용하도록 지정합니다.
use-service-loader- 이 빈 요소는 지정된 모듈에 의해 로드되는 공급자를 사용하도록 지정합니다. 모듈을 지정하지 않으면 인증 클라이언트를 로드한 클래스 로더가 사용됩니다.
모든 JBoss EAP 인증 메커니즘에서 현재 사용되지 않는 요소
현재 Elytron 클라이언트 구성의 자격 증명 요소의 하위 요소는 JBoss EAP의 인증 메커니즘에서 사용되지 않습니다. 인증 메커니즘의 사용자 지정 구현에서 사용할 수 있지만 이러한 메커니즘은 지원되지 않습니다.
-
key-pair -
public-key-pem -
key-store-reference -
certificate
19.1.2. wildfly-config.xml 파일을 사용한 Jakarta Enterprise Beans 클라이언트 구성 링크 복사링크가 클립보드에 복사되었습니다!
urn:jboss:wildfly 파일을 사용하여 Jakarta Enterprise Beans 클라이언트 연결, 글로벌 인터셉터 및 호출 시간 초과를 구성할 수 있습니다. 이 섹션에서는 이 요소를 사용하여 Jakarta Enterprise Beans 클라이언트를 구성하는 방법에 대해 설명합니다.
-client-ejb:3.0 네임스페이스에 있는 jboss -ejb-client 요소를 사용하여 wildfly- config.xml
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 클라이언트 연결, 글로벌 인터셉터 및 호출 타임아웃을 구성하는 예제입니다.
19.1.3. wildfly-config.xml 파일을 사용한 HTTP 클라이언트 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음은 the wildfly-config.xml 파일을 사용하여 HTTP 클라이언트를 구성하는 방법의 예입니다.
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
끝점 요소 및 속성
엔드포인트 요소는 선택적으로 다음 두 개의 최상위 하위 요소를 하위 요소와 함께 포함할 수 있습니다.
또한 다음과 같은 속성이 있습니다.
| 특성 이름 | 특성 설명 |
|---|---|
| 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 파일을 사용하여 원격 클라이언트를 구성하는 예입니다.
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 작업자를 구성하는 방법의 예입니다.
부록 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
INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0003: Undertow 1.4.18.Final-redhat-1 starting
AccessControlListHandler
클래스 이름: io.undertow.server.handlers.AccessControlListHandler
이름: access-control
원격 피어의 특성에 따라 요청을 수락하거나 거부할 수 있는 핸들러.
| 이름 | 설명 |
|---|---|
| ACL | ACL 규칙. 이 매개 변수는 필수입니다. |
| attribute | 교환 특성 문자열. 이 매개 변수는 필수입니다. |
| default-allow |
핸들러가 기본적으로 요청을 수락하거나 거부할지 여부를 지정하는 부울입니다. 기본값은 |
AccessLogHandler
클래스 이름: io.undertow.server.handlers.accesslog.AccessLogHandler
이름: access-log
로그 핸들러 액세스. 이 핸들러는 제공된 형식 문자열을 기반으로 액세스 로그 메시지를 생성하고 제공된 AccessLogReceiver 에 이러한 메시지를 전달합니다.
이 핸들러는 ExchangeAttribute 메커니즘을 통해 제공된 모든 특성을 로깅할 수 있습니다.
이 팩토리는 다음 패턴에 대한 토큰 핸들러를 생성합니다.
| 패턴 | 설명 |
|---|---|
| %a | 원격 IP 주소 |
| %A | 로컬 IP 주소 |
| %b |
HTTP 헤더를 제외하고 전송된 바이트 또는 바이트가 없는 경우 |
| %B | HTTP 헤더를 제외하고 전송된 바이트 |
| %h | 원격 호스트 이름 |
| %H | 요청 프로토콜 |
| %l |
원격 논리 사용자 이름 from |
| %m | 요청 방법 |
| %p | 로컬 포트 |
| %q |
쿼리 문자열 ( |
| %r | 요청의 첫 번째 행 |
| %s | 응답의 HTTP 상태 코드 |
| %t | 날짜 및 시간(일반 로그 형식) |
| %u | 인증된 원격 사용자 |
| %U | 요청된 URL 경로 |
| %v | 로컬 서버 이름 |
| %D | 요청을 처리하는 데 걸린 시간(밀리초) |
| %T | 요청을 처리하는 데 걸리는 시간(초) |
| %I | 현재 요청 스레드 이름 (나중에 스택 추적과 비교할 수 있음) |
| Common |
|
| 결합 |
|
쿠키, 수신 헤더 또는 세션에서 정보를 작성할 수도 있습니다.
Apache 구문 다음에 모델링됩니다.
-
수신 헤더의
%{I,xxx} -
나가는 응답 헤더의
%{O,xxx} -
특정 쿠키를 위한
%{C,xxx} -
%{R,xxx}여기서xxx는ServletRequest의 속성입니다. -
%{s,xxx}여기서xxx는HttpSession의 속성입니다.
| 이름 | 설명 |
|---|---|
| 포맷 | 로그 메시지를 생성하는 데 사용되는 형식입니다. 기본 매개변수 입니다. |
AllowedMethodsHandler
특정 HTTP 메서드를 허용 목록에 추가하는 핸들러입니다. 허용된 메서드 집합에 메서드가 있는 요청만 계속할 수 있습니다.
클래스 이름: io.undertow.server.handlers.AllowedMethodsHandler
이름: allowed-methods
| 이름 | 설명 |
|---|---|
| 방법 |
|
BlockingHandler
차단 요청을 시작하는 HttpHandler입니다. 스레드가 현재 I/O 스레드에서 실행 중인 경우 디스패치됩니다.
클래스 이름: io.undertow.server.handlers.BlockingHandler
이름: 차단
이 핸들러에는 매개 변수가 없습니다.
ByteRangeHandler
범위 요청에 대한 핸들러입니다. 이는 고정된 콘텐츠 길이의 모든 리소스에 대한 범위 요청을 처리할 수 있는 일반 핸들러입니다(예: content-length 헤더가 설정된 모든 리소스). 전체 콘텐츠가 생성되고 삭제되므로 이 방법이 범위 요청을 처리하는 가장 효율적인 방법은 아닙니다. 현재 이 핸들러는 단순한 단일 범위 요청만 처리할 수 있습니다. 여러 범위가 요청되면 Range 헤더가 무시됩니다.
클래스 이름: io.undertow.server.handlers.ByteRangeHandler
이름: byte-range
| 이름 | 설명 |
|---|---|
| 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
| 이름 | 설명 |
|---|---|
| 방법 |
|
EncodingHandler
이 핸들러는 콘텐츠 인코딩 구현의 기초 역할을 합니다. 인코딩 핸들러는 지정된 서버 측 우선 순위와 함께 이 핸들러에 위임으로 추가됩니다.
q 값은 올바른 핸들러를 결정하는 데 사용됩니다. q 값이 없는 요청이 도착하면 서버에서 사용할 인코딩으로 우선 순위가 가장 높은 핸들러를 선택합니다.
일치하는 핸들러가 없으면 ID 인코딩이라고 가정합니다. q 값이 0 으로 인해 ID 인코딩이 구체적으로 허용되지 않은 경우 핸들러는 응답 코드 406(수용되지 않음) 을 설정하고 반환합니다.
클래스 이름: io.undertow.server.handlers.encoding.EncodingHandler
이름: 압축
이 핸들러에는 매개 변수가 없습니다.
FileErrorPageHandler
오류 페이지 역할을 하기 위해 디스크에서 파일을 제공하는 핸들러입니다. 이 핸들러는 기본적으로 응답하는 응답 코드를 구성하지 않으므로 응답하는 응답 코드를 구성해야 합니다.
클래스 이름: io.undertow.server.handlers.error.FileErrorPageHandler
이름: error-file
| 이름 | 설명 |
|---|---|
| file | 오류 페이지로 사용할 파일의 위치. |
| response-codes | 정의된 오류 페이지 파일로 리디렉션되는 응답 코드 목록입니다. |
HttpTraceHandler
HTTP 추적 요청을 처리하는 핸들러입니다.
클래스 이름: io.undertow.server.handlers.HttpTraceHandler
이름: trace
이 핸들러에는 매개 변수가 없습니다.
IPAddressAccessControlHandler
원격 피어의 IP 주소를 기반으로 요청을 수락하거나 거부할 수 있는 핸들러입니다.
클래스 이름: io.undertow.server.handlers.IPAddressAccessControlHandler
이름: ip-access-control
| 이름 | 설명 |
|---|---|
| ACL | 액세스 제어 목록을 나타내는 문자열입니다. 기본 매개변수 입니다. |
| failure-status | 거부된 요청에 반환할 상태 코드를 나타내는 정수입니다. |
| default-allow | 부울은 기본적으로 허용 여부를 나타냅니다. |
JDBCLogHandler
클래스 이름: io.undertow.server.handlers.JDBCLogHandler
이름: jdbc-access-log
| 이름 | 설명 |
|---|---|
| 포맷 |
JDBC 로그 패턴을 지정합니다. 기본값은 |
| 데이터 소스 | 로깅할 데이터 소스의 이름입니다. 이 매개 변수는 필수이며 기본 매개변수 입니다. |
| tableName | 테이블 이름. |
| remoteHostField | 원격 호스트 주소. |
| userField | 사용자 이름. |
| timestampField | 타임스탬프. |
| virtualHostField | VirtualHost. |
| methodField | 메서드. |
| queryField | 쿼리. |
| statusField | 상태. |
| bytesField | 바이트. |
| refererField | 참조자. |
| userAgentField | userAgent. |
LearningPushHandler
브라우저에서 요청하는 리소스 캐시를 빌드하고 server push를 사용하여 지원 시 푸시하는 핸들러.
클래스 이름: io.undertow.server.handlers.LearningPushHandler
이름: learning-push
| 이름 | 설명 |
|---|---|
| 최대 크기 | 캐시 항목의 최대 시간을 나타내는 정수입니다. |
| 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
이름: 리디렉션
| 이름 | 설명 |
|---|---|
| value | 리디렉션 대상입니다. 기본 매개변수 입니다. |
RequestBufferingHandler
모든 요청 데이터를 버퍼링하는 핸들러.
클래스 이름: io.undertow.server.handlers.RequestBufferingHandler
이름: buffer-request
| 이름 | 설명 |
|---|---|
| 버퍼 | 최대 버퍼 수를 정의하는 정수입니다. 기본 매개변수 입니다. |
RequestDumpingHandler
교환을 로그에 덤프하는 핸들러.
클래스 이름: io.undertow.server.handlers.RequestDumpingHandler
이름: dump-request
이 핸들러에는 매개 변수가 없습니다.
RequestLimitingHandler
최대 동시 요청 수를 제한하는 핸들러입니다. 제한 이외의 요청은 이전 요청이 완료될 때까지 차단됩니다.
클래스 이름: io.undertow.server.handlers.RequestLimitingHandler
이름: request-limit
| 이름 | 설명 |
|---|---|
| requests | 최대 동시 요청 수를 나타내는 정수입니다. 기본 매개변수 이며 필수입니다. |
ResourceHandler
리소스를 제공하는 핸들러입니다.
클래스 이름: io.undertow.server.handlers.resource.ResourceHandler
이름: resource
| 이름 | 설명 |
|---|---|
| 위치 | 리소스 위치. 기본 매개변수 이며 필수입니다. |
| allow-listing | 디렉토리 목록 허용 여부를 결정하는 부울 값입니다. |
ResponseRateLimitingHandler
다운로드 속도를 설정된 바이트/시간으로 제한하는 핸들러.
클래스 이름: io.undertow.server.handlers.ResponseRateLimitingHandler
이름: response-rate-limit
| 이름 | 설명 |
|---|---|
| 바이트 | 다운로드 속도를 제한하는 바이트 수입니다. 이 매개 변수는 필수입니다. |
| time | 다운로드 속도를 제한하는 시간(초)입니다. 이 매개 변수는 필수입니다. |
SetHeaderHandler
고정 응답 헤더를 설정하는 핸들러입니다.
클래스 이름: io.undertow.server.handlers.SetHeaderHandler
이름: 헤더
| 이름 | 설명 |
|---|---|
| 헤더 | 헤더 속성의 이름입니다. 이 매개 변수는 필수입니다. |
| 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
| 이름 | 설명 |
|---|---|
| Threshhold |
요청을 처리하는 데 걸리는 시간을 결정하는 정수 값(초)입니다. 기본값은 |
URLDecodingHandler
지정된 문자 집합에 URL 및 쿼리 매개 변수를 디코딩하는 핸들러입니다. 이 핸들러를 사용하는 경우 UndertowOptions.DECODE_URL 매개변수를 false 로 설정해야 합니다.
이 방법은 구문 분석기가 UTF-8 디코더에 빌드된 사용만큼 효율적이지 않습니다. UTF-8 이외의 것으로 디코딩해야 하는 경우가 아니면 구문 분석기를 대신 사용해야 합니다.
클래스 이름: io.undertow.server.handlers.URLDecodingHandler
이름: url-decoding
| 이름 | 설명 |
|---|---|
| charactersset | 디코딩할 charactersset. 기본 매개변수 이므로 필수입니다. |
A.2. 지속성 유닛 속성 링크 복사링크가 클립보드에 복사되었습니다!
지속성 유닛 정의는 persistence.xml 파일에서 구성할 수 있는 다음 속성을 지원합니다.
| 속성 | 설명 |
|---|---|
| jboss.as.jpa.providerModule |
지속성 프로바이더 모듈의 이름입니다. 기본값은 |
| jboss.as.jpa.adapterModule | JBoss EAP가 지속성 프로바이더와 함께 작업하는 데 도움이 되는 통합 클래스의 이름입니다. |
| jboss.as.jpa.adapterClass | 통합 어댑터의 클래스 이름입니다. |
| jboss.as.jpa.managed |
컨테이너 관리 자카르타 지속성 액세스를 비활성화하려면 |
| jboss.as.jpa.classtransformer |
지속성 유닛의 클래스 변환기를 비활성화하려면
또한 Hibernate는 |
| jboss.as.jpa.scopedname |
사용할 정규화된 애플리케이션 범위 지속성 유닛 이름을 지정합니다. 기본적으로 이는 애플리케이션 이름 및 지속성 유닛 이름으로 설정됩니다. |
| jboss.as.jpa.deferdetach |
Jakarta가 아닌 트랜잭션 스레드에 사용되는 트랜잭션 범위 지속성 컨텍스트가 각 |
| wildfly.jpa.default-unit |
애플리케이션에서 기본 지속성 유닛을 선택하려면 |
| wildfly.jpa.twophasebootstrap |
지속성 프로바이더는 자카르타 컨텍스트 및 종속성 주입과의 자카르타 지속성 통합을 개선하는 2단계 지속성 유닛 부트스트랩을 허용합니다. |
| wildfly.jpa.allowdefaultdatasourceuse |
지속성 유닛이 기본 데이터 소스를 사용하지 못하도록 하려면 |
| wildfly.jpa.hibernate.search.module |
클래스 경로에 포함할 Hibernate Search 버전을 제어합니다. 기본값은 |
A.3. 정책 공급자 속성 링크 복사링크가 클립보드에 복사되었습니다!
| 속성 | 설명 |
|---|---|
| custom-policy | 사용자 지정 정책 프로바이더 정의. |
| JACC-policy | Jakarta Authorization 및 관련 서비스를 설정하는 정책 공급자 정의입니다. |
| 속성 | 설명 |
|---|---|
| class-name |
정책 프로바이더를 참조하는 |
| module | 프로바이더를 로드할 모듈의 이름입니다. |
| 속성 | 설명 |
|---|---|
| policy |
정책 프로바이더를 참조하는 |
| configuration-factory |
정책 구성 팩토리 공급자를 참조하는 |
| module | 프로바이더를 로드할 모듈의 이름입니다. |
A.4. Jakarta EE 프로필 및 기술 참조 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에는 범주별 Jakarta EE 기술이 나열되어 있으며, 이 기술이 Web Profile 또는 Full Platform 프로필에 포함되는지 여부를 확인합니다.
사양은 Jakarta EE Specification 을 참조하십시오.
| 기술 | 웹 프로파일 | 전체 플랫폼 |
|---|---|---|
| 자카르타 웹소켓 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
org.apache.taglibs.standard.xml.accessExternalEntityCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
standalone.
sh 또는를 전달합니다.accessExternalEntity=""domain.sh스크립트의 인수로 -Dorg.apache.taglibs.standard.xml.
| 기술 | 웹 프로파일 | 전체 플랫폼 |
|---|---|---|
| 자카르타 배치 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 | ✔ |
| 기술 | 웹 프로파일 | 전체 플랫폼 |
|---|---|---|
| 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 (선택 사항) |
| 기술 | 웹 프로파일 | 전체 플랫폼 |
|---|---|---|
| 자카르타 보안 1.0 | ✔ | ✔ |
| 자카르타 인증 1.1 | ✔ | ✔ |
| 자카르타 권한 1.5 | ✔ | |
| Jakarta Deployment 1.2 (선택 사항) | ✔ | |
| 자카르타 관리 1.1 | ✔ | |
| 다른 언어에 대한 자카르타 디버깅 지원 1.0 | ✔ |
2024-02-09에 최종 업데이트된 문서