애플리케이션을 JBoss EAP 7에서 JBoss EAP 8.0으로 같은 주요 릴리스에서 다른 주요 릴리스로 이동할 때 주요 업그레이드 또는 마이그레이션이 필요합니다. 자카르타 EE 8 사양을 준수하거나 독점 코드를 포함하거나 더 이상 사용되지 않는 API를 사용하는 애플리케이션에는 JBoss EAP 8.0에서 실행하기 위해 애플리케이션 코드를 수정해야 할 수 있습니다. 자카르타 EE 10의 도입에는 JBoss EAP 8.0과의 호환성을 위해 자카르타 EE 애플리케이션 코드를 조정해야 하는 Java 패키지 이름 및 기타 측면을 변경해야 합니다. 또한 JBoss EAP 8.0에서 서버 구성이 변경되었으며 마이그레이션이 필요합니다. 이 유형의 마이그레이션은 이 가이드에서 다룹니다.

JBoss EAP의 마이너 업데이트는 버그 수정, 보안 수정 및 새로운 기능을 제공하는 포인트 릴리스입니다. 각 릴리스의 변경 사항은 Red Hat JBoss Enterprise Application Platform 8.0의 릴리스 노트에 설명되어 있습니다.

JBoss Server Migration Tool을 사용하여 한 시점에서 다른 지점으로 자동으로 업그레이드하십시오(예: JBoss EAP 7.0에서 JBoss EAP 7.1으로 자동 업그레이드). 자세한 내용은 JBoss Server 마이그레이션 툴 사용을 참조하십시오.

JBoss EAP는 버그 및 보안 수정 사항이 포함된 누적 패치를 주기적으로 제공합니다. 누적 패치는 마지막 숫자가 릴리스(예: 버전 7.1.0에서 7.1.1)로 업그레이드합니다.

JBoss Server 마이그레이션 도구는 JBoss EAP 버전 7의 모든 릴리스에서 JBoss EAP 8.0으로의 마이그레이션을 지원합니다.

CDI 4.0 사양 변경 노트에 따라 빈 beans.xml 파일이 있는 배포에서 Contexts 및 dependency Cryostat 또는 CDI 빈을 검색하는 기본 동작이 모두 주석 으로 변경되었습니다. 즉, 이러한 배포에서는 Quarkus 정의 주석이 있는 배포 클래스만 CDI에서 검색됩니다. 빈을 사용하는 모든 애플리케이션 클래스에 이러한 주석이 있는 경우 이 CDI 변경에 영향을 미치지 않습니다. 그러지 않으면 CDI에서 특정 8080을 제공하는 유형을 찾을 수 없는 경우 애플리케이션 배포가 실패할 수 있습니다.

이 변경으로 인해 애플리케이션에 영향을 받는 경우 다음과 같은 몇 가지 옵션이 있습니다.

Jakarta Contexts 및 dependency Cryostat 4.0은 더 이상 사용되지 않는 다음과 같은 API 요소를 제거했습니다.

Java SE 14는 java.security.Identity 클래스를 제거했기 때문에 Jakarta Enterprise Cryostats 4.0 API에서 사용이 제거되었습니다.

javax.el.MethodExpression.isParmetersProvided() 메서드가 잘못 입력되었습니다. 대신 MethodExpression.isParametersProvided() 를 사용할 수 있습니다.

기본적으로 jakarta.json.bind.annotation.JsonbCreator 주석으로 주석이 달린 유형은 JSON 콘텐츠에서 모든 매개변수를 사용할 수 있을 필요가 없습니다. 구문 분석 중인 JSON이 매개변수 중 하나가 누락된 경우 기본값을 사용합니다. JSON에 모든 매개변수가 있어야 하는 EE 8 동작은 jakarta.json.bind.JsonbConfig().withCreatorParametersRequired(true) 를 호출하여 설정할 수 있습니다.

다음의 더 이상 사용되지 않는 기능은 자카르타 eyess 4.0에서 제거되었습니다.

Jakarta Servlet 6.0은 대부분 서블릿 2.x 릴리스에서 더 이상 사용되지 않는 여러 API 클래스와 방법을 제거합니다.

javax.servlet.SingleThreadModel 마커 인터페이스가 제거되었으며 이 인터페이스를 구현하는 서블릿에서 인터페이스 선언을 제거하고 서블릿 코드가 상태 및 기타 리소스 액세스를 동시에 액세스하도록 해야 합니다. 예를 들어 인스턴스 변수를 사용하지 않도록 하거나 리소스에 액세스하는 코드 블록을 동기화합니다. 그러나 개발자가 성능에 대한 동기화의 영향으로 인해 서비스 메서드(또는 doGet 및 doPost 와 같은 메서드)를 동기화하지 않는 것이 좋습니다.

javax.servlet.http.HttpSessionContext 인터페이스가 javax.servlet.http.HttpSession.getSessionContext() 메서드와 함께 제거되었습니다. Servlet 2.1 이후 이 인터페이스에는 사용 가능한 데이터를 제공하지 않는 사양에 구현이 필요하기 때문에 이 인터페이스에 대한 사용 사례가 없었습니다.

javax.servlet.http.HttpUtils 유틸리티 클래스가 제거되었습니다. 애플리케이션은 다음 메서드 대신 ServletRequest 및 CryostatServletRequest 인터페이스를 사용해야 합니다.

또한 다음과 같은 기타 메서드 및 생성자가 제거되었습니다.

jaxm.properties 파일을 통한 공급자 조회 지원이 제거되었습니다.

더 이상 사용되지 않는 javax.xml.soap.SOAP CryostatFactory 클래스가 제거되었습니다. jakarta.xml.soap.SOAPFactory 를 사용하여음악을 생성합니다.

xml 바인딩 파일에서 사용해야 하는 XML 네임스페이스가 변경되었습니다. http://java.sun.com/xml/ns/jaxb 네임스페이스는 https://jakarta.ee/xml/ns/jaxb 로 교체해야 합니다.

연결된 javax.xml.bind.createValidator() 메서드와 같이 더 이상 사용되지 않는 javax.xml.bind.Validator 인터페이스가 제거되었습니다. 마샬링 및 unmarshalling 작업을 검증하려면 javax.xml.validation.Schema 를 jakarta.xml.bind.Marshaller.setSchema(Schema) 에 제공합니다.

CryostatB 1.0과의 호환성 지원이 제거되었습니다.

Cryostat BContext 구현 조회 알고리즘에서 더 이상 사용되지 않는 일부 단계가 제거되었습니다. jaxb.properties 파일, javax.xml.bind.factory 또는 jakarta.xml. bind.JAXBContext 속성 및 /META-INF/services/javax.xml.bind.JAXBContext 리소스 파일을 삭제하여 구현 클래스 이름을 검색합니다. 현재 구현 검색 알고리즘에 대한 자세한 내용은 Jakarta XML Binding 4.0 사양 을 참조하십시오.

javax.xml.bind.Marshaller 인터페이스에서 여러 메서드에 대한 일반 요구 사항은 다음과 같이 변경되었습니다.

Jakarta XML Binding API의 변경 사항 외에도 구현 라이브러리 EAP 8에서 패키지 이름이 크게 변경되어 구현 라이브러리에 직접 액세스하는 일부 애플리케이션에 영향을 줄 수 있습니다.

JBoss EAP 7.0에서 웹 애플리케이션의 루트 컨텍스트는 mod_cluster 에서는 기본적으로 비활성화되어 있습니다.

JBoss EAP 7.1부터는 더 이상 그렇지 않습니다. 루트 컨텍스트를 비활성화해야 하는 경우 이로 인해 예기치 않은 결과가 발생할 수 있습니다. 예를 들어, 원하지 않는 노드로 요청이 잘못 라우팅되거나 노출해서는 안 되는 개인 애플리케이션은 공용 프록시를 통해 의도치 않게 액세스할 수 있습니다. 이제 Cryostat 위치는 명시적으로 제외되지 않는 한 mod_cluster 로드 밸런서에 자동으로 등록됩니다.

다음 관리 CLI 명령을 사용하여 modcluster 하위 시스템 구성에서 ROOT를 제외합니다.

/subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=excluded-contexts,value=ROOT)

다음 관리 CLI 명령을 사용하여 기본 시작 웹 애플리케이션을 비활성화합니다.

/subsystem=undertow/server=default-server/host=default-host/location=\/:remove
/subsystem=undertow/configuration=handler/file=welcome-content:remove
reload

Red Hat JBoss Enterprise Application Platform 7.2 이전에는 기본 undertow 하위 시스템 구성에 default-host 에 의해 각 HTTP 응답에 추가된 두 개의 응답 헤더 필터가 포함되었습니다.

이러한 응답 헤더 필터는 사용 중인 서버에 대한 정보의 의도하지 않은 공개를 방지하기 위해 기본 JBoss EAP 7.2 구성에서 제거되었습니다.

다음은 JBoss EAP 7.1의 기본 undertow 하위 시스템 구성의 예입니다.

<subsystem xmlns="urn:jboss:domain:undertow:4.0">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https"/>
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <filter-ref name="server-header"/>
            <filter-ref name="x-powered-by-header"/>
            <http-invoker security-realm="ApplicationRealm"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
        <websockets/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
    <filters>
        <response-header name="server-header" header-name="Server" header-value="JBoss-EAP/7"/>
        <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
    </filters>
</subsystem>

다음은 JBoss EAP 7.4의 기본 undertow 하위 시스템 구성의 예입니다.

<subsystem xmlns="urn:jboss:domain:undertow:12.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <http-invoker security-realm="ApplicationRealm"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
        <websockets/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
</subsystem>

다음은 JBoss EAP 8.0의 기본 undertow 하위 시스템 구성의 예입니다.

<subsystem xmlns="urn:jboss:domain:undertow:14.0" default-virtual-host="default-host" default-servlet-container="default" default-server="default-server" statistics-enabled="${wildfly.undertow.statistics-enabled:${wildfly.statistics-enabled:false}}" default-security-domain="other">
    <byte-buffer-pool name="default"/>
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
        <https-listener name="https" socket-binding="https" ssl-context="applicationSSC" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <http-invoker http-authentication-factory="application-http-authentication"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
        <websockets/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
    <application-security-domains>
        <application-security-domain name="other" security-domain="ApplicationDomain"/>
    </application-security-domains>
</subsystem>

JBoss EAP 7.1 이상 버전에서는 활성화가 활성화된 사용자 정의 상태 저장 세션 빈(SFSB) 캐시가 변경되었습니다. 비활성화를 사용하여 SFSB 캐시를 구성할 때 다음과 같은 주요 변경 사항을 고려하십시오.

JBoss EAP 7.1 이상 버전에서 비활성화를 위해 사용자 지정 SFSB 캐시를 구성할 때 다음 제한 사항을 고려하십시오.

JBoss EAP 7.0 이상 버전 간의 동작 변경을 수행하려면 일괄 모드 또는 특수 헤더를 사용하여 캐시 컨테이너 전송 프로토콜에 대한 업데이트를 수행해야 합니다. 이 변경 사항은 JBoss EAP 서버 관리에 사용되는 툴에도 영향을 미칩니다.

다음은 JBoss EAP 7.0에서 캐시 컨테이너 전송 프로토콜을 구성하는 데 사용되는 관리 CLI 명령의 예입니다.

/subsystem=infinispan/cache-container=my:add()
/subsystem=infinispan/cache-container=my/transport=jgroups:add()
/subsystem=infinispan/cache-container=my/invalidation-cache=mycache:add(mode=SYNC)

다음은 JBoss EAP 7.1에서 동일한 구성을 수행하는 데 필요한 관리 CLI 명령의 예입니다. 명령은 일괄 처리 모드로 실행됩니다.

batch
/subsystem=infinispan/cache-container=my:add()
/subsystem=infinispan/cache-container=my/transport=jgroups:add()
/subsystem=infinispan/cache-container=my/invalidation-cache=mycache:add(mode=SYNC)
run-batch

배치 모드를 사용하지 않으려면 전송을 정의할 때 작업 헤더 allow-resource-service-restart=true 를 대신 지정할 수 있습니다.

스크립트를 사용하여 캐시 컨테이너 전송 프로토콜을 업데이트하는 경우 이를 검토하고 일괄 처리 모드를 추가해야 합니다.

JBoss EAP 8.0에서는 새 하위 시스템 및 여러 리소스에 대한 업데이트를 포함하여 SFSB(Distributedable stateful session beans)에 대한 EJB(Enterprise JavaBeans) 하위 시스템 구성 변경 사항이 도입되었습니다. JBoss EAP 6 및 7에서 사용되는 여러 리소스도 더 이상 사용되지 않습니다. 이러한 변경 사항을 통해 서버 구성 마이그레이션을 통해 애플리케이션이 향후 주요 릴리스와 호환되는지 확인할 수 있습니다.

JBoss EAP 8.0은 JBoss EAP 6 및 7에서 사용되는 더 이상 사용되지 않는 리소스를 분산형 SFSB 캐싱을 구성하기 위한 두 개의 새 리소스와 distributable - Cryostat 하위 시스템으로 대체합니다. 다음 표에는 더 이상 사용되지 않는 리소스와 해당 리소스를 대체하는 새 리소스가 요약되어 있습니다.

배포 불가능한 SFSB 캐시, /subsystem= Cryostat3/simple-cache 는 JBoss EAP 7에서 사용된 SFSB 캐시인 /subsystem= Cryostat3/cache 와 동일합니다.

배포 가능한 SFSB 캐시 /subsystem= Cryostat3/distributable-cache 에는 배포 가능 - Cryostat 하위 시스템에서 해당 리소스를 참조하는 선택적 8080- management 특성이 포함되어 있습니다. 리소스를 정의하지 않으면 기본값은 distributable - Cryostat 하위 시스템 내의 8080 -management 리소스입니다.

JBoss EAP 8.0에서 업데이트된 접근 방식으로 서버 구성을 마이그레이션하는 것이 좋습니다. 현재 릴리스는 더 이상 사용되지 않는 리소스에서 계속 작동하지만 제거 시 향후 릴리스에서는 그렇지 않을 수 있습니다.

JBoss EAP 7과 기본 JBoss EAP 8.0 구성 간의 비교 예는 다음과 같습니다.

/subsystem=ejb3/cache=example-simple-cache:add()
/subsystem=ejb3/passivation-store=infinispan:add(cache-container=ejb, bean-cache=default, max-size=1024)
/subsystem=ejb3/cache=example-distributed-cache:add(passivation-store=infinispan)

/subsystem=ejb3/simple-cache=example-simple-cache:add()
/subsystem=distributable-ejb=example-distributed-cache/infinispan-bean-management=example-bean-cache:add(cache-container=ejb, cache=default, max-active-beans=1024)
/subsystem=ejb3/distributable-cache=example-distributed-cache:add(bean-management=example-bean-cache)

기본 JBoss EAP 8.0 구성을 채택하면 서버가 최신 버전 및 향후 주요 릴리스와 호환됩니다. 또한 배포 가능한 SFSB를 위한 향상된 리소스 및 하위 시스템의 이점도 누릴 수 있습니다.

다음 DuplicateServiceException 오류는 JBoss EAP 7의 변경 사항을 캐싱하여 발생합니다.

ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".cache-dependencies-installer: org.jboss.msc.service.StartException in service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".cache-dependencies-installer: Failed to start service
...
Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.infinispan.ejb."mdb-1.0-SNAPSHOT.jar".config is already registered

JBoss EAP 7의 변경 사항 캐싱으로 인한 DuplicateServiceException 을 해결하려면 다음 명령을 실행하여 Cryostat 3 하위 시스템에서 캐싱을 재구성합니다.

/subsystem=ejb3/file-passivation-store=file:remove
/subsystem=ejb3/cluster-passivation-store=infinispan:remove
/subsystem=ejb3/passivation-store=infinispan:add(cache-container=ejb, max-size=10000)

/subsystem=ejb3/cache=passivating:remove
/subsystem=ejb3/cache=clustered:remove
/subsystem=ejb3/cache=distributable:add(passivation-store=infinispan, aliases=[passivating, clustered])

캐시를 재구성하면 이 오류를 해결하고 DuplicateServiceException 이 발생하지 않도록 할 수 있습니다.

Red Hat JBoss Enterprise Application Platform에서 메시징 데이터를 마이그레이션하는 데 사용할 수 있는 접근 방식을 검토하십시오.

이전 JBoss EAP 7.x 릴리스에서 JBoss EAP 8.0으로 메시징 데이터를 마이그레이션하려면 내보내기 및 가져오기 방법을 사용하여 메시징 데이터를 마이그레이션할 수 있습니다. 이 방법은 이전 릴리스에서 메시징 데이터를 내보내고 관리 CLI import-journal 작업을 사용하여 JBoss EAP 8.0으로 가져와야 합니다. 이 방법은 파일 기반 메시징 시스템에 특히 적용됩니다.

버전 7과 마찬가지로 JBoss EAP 8.0은 ActiveMQ Artemis를 Jakarta Messaging 지원 공급자로 계속 사용하므로 마이그레이션 프로세스를 더 원활하게 수행할 수 있습니다.

타사 자카르타 메시징 공급자와 함께 사용할 일반 자카르타 메시징 리소스 어댑터를 구성하는 방식이 Red Hat JBoss Enterprise Application Platform 8.0에서 변경되었습니다. 자세한 내용은 JBoss EAP 7.4 Messaging 구성 가이드의 일반 Java Message Service 리소스 어댑터 배포를 참조하십시오.

Red Hat JBoss Enterprise Application Platform 7.0에서 check-for-live-server 속성을 지정하지 않고 replication-primary 정책을 구성한 경우 기본값이 false 로 설정되었습니다. 이는 JBoss EAP 7.1 이상에서 변경되었습니다. check-for-live-server 속성의 기본값이 이제 true 로 설정됩니다.

다음은 check-for-live-server 특성을 지정하지 않고 replication-primary 정책을 구성하는 관리 CLI 명령의 예입니다.

/subsystem=messaging-activemq/server=default/ha-policy=replication-primary:add(cluster-name=my-cluster,group-name=group1)

관리 CLI를 사용하여 리소스를 읽을 때 check-for-live-server 속성 값이 true 로 설정되어 있는지 확인합니다.

/subsystem=messaging-activemq/server=default/ha-policy=replication-primary:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "check-for-live-server" => true,
        "cluster-name" => "my-cluster",
        "group-name" => "group1",
        "initial-replication-sync-timeout" => 30000L
    },
    "response-headers" => {"process-state" => "reload-required"}
}

JBoss EAP 7에서는 포함된 메시징 브로커가 기본 설치의 일부였습니다. JBoss EAP 8에서는 이 기능이 embedded-activemq 라는 새로운 Galleon 계층에 추가되었습니다.

이 새 계층은 기본 구성의 일부가 아니므로 JBoss EAP에 포함된 브로커를 사용하고자 하는 사용자는 구성에 명시적으로 포함해야 합니다.

이 계층은 고객이 OpenShift에서 전용 AMQ 클러스터를 사용하는 것을 권장하더라도 임베디드 브로커가 포함된 messaging-activemq 하위 시스템을 제공합니다. 또한 이 사용 사례를 지원하는 데 필요한 소켓 바인딩 및 필요한 종속성과 같은 보조 리소스도 프로비저닝합니다.

자격 증명 모음이 JBoss EAP 8.0에서 제거되었습니다. elytron 하위 시스템에서 제공하는 인증 정보 저장소를 사용하여 중요한 문자열을 저장합니다.

레거시 보안 하위 시스템 및 레거시 보안 영역이 JBoss EAP 8.0에서 제거되었습니다. elytron 하위 시스템에서 제공하는 보안 영역을 사용합니다.

CryostatetLink 하위 시스템이 JBoss EAP 8.0에서 제거되었습니다. Red Hat build of Keycloak ID 공급자 대신 Keycloak 빌드와 Red Hat build of Keycloak SAML 어댑터 대신 Cryostat SAML 어댑터를 사용하십시오.

keycloak 하위 시스템은 JBoss EAP 8.0에서 지원되지 않으며 elytron-oidc-client 하위 시스템으로 교체됩니다. JBoss Server 마이그레이션 도구는 기본적으로 마이그레이션을 수행합니다.

JBoss EAP 8.0에서는 레거시 보안 하위 시스템이 제거되었습니다. elytron 하위 시스템에서 사용자 지정 로그인 모듈을 계속 사용하려면 새로운 JAAS(Java Authentication and Authorization Service) 보안 영역과 jaas-realm 을 사용합니다.

JBoss EAP 7.1부터 자체 서명된 인증서의 자동 생성은 개발 목적으로 기본적으로 활성화됩니다. FIPS 모드에서 실행 중인 경우 자동 자체 서명 인증서 생성을 비활성화하도록 서버를 구성합니다. 이렇게 하지 않으면 서버를 시작할 때 다음과 같은 오류가 발생할 수 있습니다.

ERROR [org.xnio.listener] (default I/O-6) XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException: WFLYDM0114: Failed to lazily initialize SSL context
...
Caused by: java.lang.RuntimeException: WFLYDM0112: Failed to generate self signed certificate
...
Caused by: java.security.KeyStoreException: Cannot get key bytes, not PKCS#8 encoded

JAX-RPC(Java API for XML-based RPC)는 Java EE 6에서 더 이상 사용되지 않으며 Java EE 7에서는 선택 사항입니다. JBoss EAP 7부터는 더 이상 지원되지 않습니다. Cryostat-RPC를 사용하는 애플리케이션은 현재 자카르타 EE 표준 웹 서비스 프레임워크인 Jakarta XML Web Services 를 사용하도록 마이그레이션해야 합니다.

Cryostat-RPC 웹 서비스의 사용은 다음과 같은 방법으로 식별할 수 있습니다.

이전 릴리스의 JBoss EAP에서는 엔드포인트 배포 아카이브와 함께 jbossws-cxf.xml 구성 파일을 포함하여 JBossWS 및 Apache CXF 통합을 사용자 지정할 수 있습니다. 이에 대한 한 가지 사용 사례는 Apache CXF 버스에서 웹 서비스 클라이언트 및 서버 끝점에 대한 인터셉터 체인을 구성하는 것입니다. 이러한 통합에는 Spring이 JBoss EAP 서버에 배포되어야 했습니다.

JBoss EAP 8에서는 Spring 통합이 더 이상 지원되지 않습니다. jbossws-cxf.xml 설명자 구성 파일이 포함된 애플리케이션은 해당 파일에 정의된 사용자 지정 구성을 대체하도록 수정해야 합니다. Apache CXF API에 직접 액세스할 수는 있지만 애플리케이션은 이식할 수 없습니다.

제안된 접근 방식은 Spring 사용자 지정 구성을 가능한 경우 새 JBossWS 설명자 구성 옵션으로 교체하는 것입니다. JBossWS 설명자 기반 접근 방식은 클라이언트 엔드포인트 코드를 수정하지 않고도 유사한 기능을 제공합니다. 경우에 따라 Spring을 CDI(컨텍스트 종속성)로 교체할 수 있습니다.

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jakartaee="https://jakarta.ee/xml/ns/jakartaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:5.0 schema/jbossws-jaxws-config_5_0.xsd">
  <endpoint-config>
    <config-name>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointImpl</config-name>
    <property>
      <property-name>cxf.interceptors.in</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointInterceptor,org.jboss.test.ws.jaxws.cxf.interceptors.FooInterceptor</property-value>
    </property>
    <property>
      <property-name>cxf.interceptors.out</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointCounterInterceptor</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jakartaee="https://jakarta.ee/xml/ns/jakartaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:5.0 schema/jbossws-jaxws-config_5_0.xsd">
  <endpoint-config>
    <config-name>Custom FI Config</config-name>
    <property>
      <property-name>cxf.features</property-name>
      <property-value>org.apache.cxf.feature.FastInfosetFeature</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

import org.apache.cxf.frontend.ClientProxy;
import org.apache.cxf.transport.http.HTTPConduit;
import org.apache.cxf.transports.http.configuration.HTTPClientPolicy;

// Set chunking threshold before using a JAX-WS port client
...
HTTPConduit conduit = (HTTPConduit)ClientProxy.getClient(port).getConduit();
HTTPClientPolicy client = conduit.getClient();

client.setChunkingThreshold(8192);
...

이 섹션에서는 JBoss EAP 6.4 및 JBoss EAP 7.0에서 애플리케이션에 대한 다양한 WS-Security 변경 사항에 대해 설명합니다.

cxf-api 및 cxf-rt-core JAR이 하나의 cxf-core JAR로 병합되었습니다. 그 결과 JBoss EAP의 org.apache.cxf 모듈에는 이제 cxf-core JAR이 포함되어 이전 릴리스보다 더 많은 클래스를 노출합니다.

XML/WS-Security의 대칭 암호화에 Galois/Counter Mode(GCM)와 함께 AES 암호화를 사용하려면 BouncyCastle Security Provider가 필요합니다.

JBoss EAP 7부터 org.bouncycastle 모듈에 포함되었으며 JBossWS는 클래스 로더를 사용하여 BouncyCastle 보안 공급자를 가져오고 사용할 수 있었습니다. 따라서 더 이상 현재 JVM에 BouncyCastle을 정적으로 설치할 필요가 없습니다. 컨테이너 외부에서 실행되는 애플리케이션의 경우 클래스 경로에 BouncyCastle 라이브러리를 추가하여 JBossWS에서 보안 공급자를 사용할 수 있습니다.

서버의 jaxws-endpoint-config.xml 배포 설명자 파일에서 org.jboss.ws.cxf.noLocalBC 속성 값을 true 로 설정하거나 서버의 jaxws-client-config.xml 설명자 파일을 클라이언트에 대해 jaxws-client-config.xml 설명자 파일을 설정하여 이 동작을 비활성화할 수 있습니다.

JBoss EAP와 함께 제공되는 버전과 다른 버전을 사용하려면 BouncyCastle을 JVM에 정적으로 설치할 수 있습니다. 이 경우 정적으로 설치된 BouncyCastle Security Provider가 클래스 경로에 있는 공급자를 통해 선택됩니다. 문제가 발생하지 않도록 하려면 BouncyCastle 1.72 이상을 사용해야 합니다.

컨테이너에서 실행되는 클라이언트의 기본 버스 선택 전략이 THREAD_BUS 에서 TCCL_BUS 로 변경되었습니다. 컨테이너 외부에서 실행되는 클라이언트의 경우 기본 전략은 여전히 THREAD_BUS 입니다. 다음 방법 중 하나를 사용하여 이전 릴리스의 해당 동작을 복원할 수 있습니다.

컨테이너는 웹 서비스 참조에 삽입된 클라이언트를 빌드하기 위해 WebServiceFeature 클래스를 생성자에 인수로 포함하는 Jakarta XML Web Services 2.2 스타일 생성자를 사용해야 합니다. JBossWS 4와 함께 제공되는 JBoss EAP 6.4는 이러한 요구 사항을 숨깁니다. JBossWS 5가 포함된 JBoss EAP 7부터 이 요구 사항은 숨겨지지 않습니다. 이는 사용자가 컨테이너에서 삽입한 서비스 클래스를 제공한 경우 하나 이상의 WebServiceFeature 인수를 포함하는 jakarta.xml.ws.Service 생성자를 사용하도록 기존 코드를 업데이트하여 Jakarta XML Web Services 2.2 이상을 구현해야 합니다.

protected Service(URL wsdlDocumentLocation,
       QName serviceName,
       WebServiceFeature... features)

이전 릴리스에서는 시스템 속성 org.jboss.security.ignoreHttpsHost 를 true 로 설정하여 인증서에 지정된 서비스의 CN(Common Name)에 대해 HTTPS URL 호스트 이름을 비활성화할 수 있습니다. 이 시스템 속성 이름은 cxf.tls-client.disableCNCheck 로 교체되었습니다.

서비스 엔드포인트 및 서비스 클라이언트 처리기에 삽입을 사용하면 더 이상 org.jboss.as.webservices.server.integration JBoss 모듈에서 처리기 클래스를 자동으로 로드할 수 없습니다. 애플리케이션이 사전 정의된 지정된 구성에 종속된 경우 배포에 대한 새 모듈 종속성을 명시적으로 정의해야 할 수 있습니다. 자세한 내용은 명시적 모듈 종속 항목 마이그레이션 을 참조하십시오.

Java 지원 표준 덮어쓰기 메커니즘 은 JDK 1.8_40에서 더 이상 사용되지 않으며 JDK 9에서 제거하려고 했습니다. 이 메커니즘을 통해 개발자는 JAR을 JRE 내의 보증 디렉터리에 배치하여 배포된 모든 애플리케이션에서 라이브러리를 사용할 수 있습니다.

JBoss EAP 7 릴리스부터 애플리케이션이 Apache CXF의 JBossWS 구현을 사용한 경우 필요한 종속 항목이 올바른 순서로 추가되므로 이러한 변경의 영향을 받지 않아야 합니다. 애플리케이션이 Apache CXF에 직접 액세스하는 경우 애플리케이션 배포의 일부로 JBossWS 종속성을 사용한 후 Apache CXF 종속 항목을 제공해야 합니다.

이전 릴리스의 JBoss EAP에서는 JAR 아카이브의 META-INF/ 디렉터리에 있는 Jakarta Enterprise Cryostats 웹 서비스 배포에 대한 jboss-webservices.xml 배포 설명자 파일을 구성하거나 WAR 아카이브에 번들된 Jakarta Enterprise Cryostats 웹 서비스 끝점을 위한 article -INF/ 디렉터리에 구성할 수 있습니다.

JBoss EAP 7부터는 EAR 아카이브의 META-INF/ 디렉터리에 jboss-webservices.xml 배포 설명자 파일을 구성할 수 있습니다. jboss-webservices.xml 파일이 EAR 아카이브 및 JAR 또는 WAR 아카이브에 있는 경우 JAR에 대한 jboss-webservices.xml 파일의 구성 데이터가 EAR 설명자 파일의 해당 데이터를 덮어씁니다.

JBoss EAP 7부터는 이름 지정 패턴 -jms.xml 으로 식별되는 독점 HornetQ 메시징 리소스 배포 설명자 파일이 작동하지 않습니다. 다음은 JBoss EAP 6의 Java Message Service 리소스 배포 설명자 파일의 예입니다.

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-deployment:1.0">
  <hornetq-server>
    <jms-destinations>
      <jms-queue name="testQueue">
        <entry name="queue/test"/>
        <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
      <jms-topic name="testTopic">
        <entry name="topic/test"/>
        <entry name="java:jboss/exported/jms/topic/test"/>
      </jms-topic>
    </jms-destinations>
  </hornetq-server>
</messaging-deployment>

이전 릴리스에서 애플리케이션에서 -jms.xml Java Message Service 배포 설명자를 사용한 경우 Jakarta EE 플랫폼의 리소스 정의 및 구성 섹션에 지정된 표준 배포 설명자를 사용하도록 애플리케이션을 변환하거나 대신 messaging-activemq-deployment 스키마를 사용하도록 배포 설명자를 업데이트할 수 있습니다. 설명자를 업데이트하도록 선택하는 경우 다음과 같은 사항을 수정해야 합니다.

수정된 파일은 다음 예와 같아야 합니다.

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-activemq-deployment:1.0">
  <server>
    <jms-destinations>
      <jms-queue name="testQueue">
        <entry name="queue/test"/>
        <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
      <jms-topic name="testTopic">
        <entry name="topic/test"/>
        <entry name="java:jboss/exported/jms/topic/test"/>
      </jms-topic>
    </jms-destinations>
  </server>
</messaging-deployment>

JBoss EAP 6에는 애플리케이션 소스 코드에서 HornetQ API를 사용할 수 있는 org.hornetq 모듈이 포함되어 있었습니다.

Apache ActiveMQ Artemis는 JBoss EAP 7의 HornetQ를 대체하므로 Apache ActiveMQ Artemis API 를 사용하려면 HornetQ API를 사용하는 모든 코드를 마이그레이션해야 합니다. 이 API의 라이브러리는 org.apache.activemq.artemis 모듈에 포함되어 있습니다.

ActiveMQ Artemis는 HornetQ의 진화로, 많은 개념이 여전히 적용됩니다.

auto-create-jms-queues,auto-delete-jms-queues, auto-create-jms-topics ,auto-delete-jms-topics 속성 및 auto-delete-jms-topics 속성만 부분적으로 구현되고 JBoss EAP 7에서 완전히 구성할 수 없었습니다. 더 이상 사용되지 않는 이러한 속성은 기술 프리뷰 기능으로 만 제공되었으며 지원되지 않았습니다.

더 이상 사용되지 않는 이러한 특성을 다음과 같은 대체 속성으로 교체해야 합니다.

JBoss EAP 6에서 기본 주소 설정 속성이 false 로 설정되었습니다. JBoss EAP 7부터는 대체 속성이 기본적으로 true 로 설정됩니다.

JBoss EAP 6 동작을 유지하려면 교체 속성을 false 로 설정해야 합니다.

이러한 교체 속성에 대한 자세한 내용은 JBoss EAP 7.4 Configuring Messaging Guide 의 주소 설정 특성을 참조하십시오.

JBoss EAP 7.2부터 클라이언트 애플리케이션이 Artemis 클라이언트 JAR(예: Artemis -jms-client ,artemis- commons, artemis-client 또는 artemis- selector )에 직접 의존하는 경우 wildfly-client-properties 에 대해 pom.xml 파일에 다음 종속성을 추가해야 합니다.

<dependency>
  <groupId>org.jboss.eap</groupId>
  <artifactId>wildfly-client-properties</artifactId>
</dependency>

이는 JBEAP-15889 에 설명된 대로 message.getJMSReplyTo() 에서 message.getJMSReplyTo()를 호출할 때 JMSRuntimeException 을 방지하기 위한 것입니다.

인터셉터 및 MessageBody 클래스

Cryostat 311: Cryostat-RS: RESTful Web Services용 Java™ API에는 인터셉터 프레임워크가 포함되어 있지 않아 REST Cryostat 2가 제공되었습니다. Cryostat 339: Cryostat-RS 2.0: RESTful Web Services를 위한 Java API는 공식 인터셉터 및 필터 프레임워크를 도입했기 때문에 REST Cryostat 2에 포함된 인터셉터 프레임워크는 더 이상 사용되지 않으며 REST Cryostat 3.x의 Jakarta REST 호환 인터셉터 기능으로 대체되었습니다. 관련 인터페이스는 jakarta.ws.rs.api 모듈의 jakarta.ws.ext 패키지에 정의됩니다.

다음 공급자가 JBoss EAP 8.0에서 제거되었습니다.

다음은 Jakarta RESTful Web Services 대체가 있으므로 JBoss EAP 8.0에서 제거되었습니다.

클라이언트 API

resteasy-jaxrs 의 REST Cryostat 클라이언트 프레임워크는 JBoss EAP 7.0의 Cryostat-RS 2.0 호환 resteasy-client 모듈로 교체되었습니다. 결과적으로 일부 REST Cryostat 클라이언트 API 클래스 및 메서드는 더 이상 사용되지 않습니다.

StringConverter

org.jboss.resteasy.spi.StringConverter 클래스는 REST Cryostat 3.x 및 JBoss EAP 8.0에서 더 이상 사용되지 않습니다. 이 기능은 Jakarta REST jakarta.ws.rs.ext.ParamConverterProvider 클래스를 사용하여 교체할 수 있습니다.

ResteasyProviderFactory 메서드 추가

대부분의 org.jboss.resteasy.spi.ResteasyProviderFactory add() 메서드가 REST Cryostat 3.0에서 제거되거나 보호됩니다. 예를 들어 add builtInMessageBody Cryostat() 및 addbuiltInMessageBodyWriter() 메서드가 제거되고 addMessageBody Cryostat() 및 addMessageBodyWriter() 메서드가 보호되었습니다.

이제 registerProvider() 및 registerProviderInstance() 메서드를 사용해야 합니다.

REST Cryostat 3에서 제거된 추가 클래스

Jakarta REST 메서드에 대한 응답을 캐시해야 하는 @org.jboss.resteasy.annotations.cache.ServerCached 주석은 REST Cryostat 3에서 제거되었으며 애플리케이션 코드에서 제거해야 합니다.

이 섹션에서는 JBoss EAP용 REST Cryostat의 몇 가지 추가 변경 사항에 대해 설명합니다.

SignedInput 및 SignedOuput

보안 필터

@RolesAllowed,@PermitAll 및 @DenyAll 에 대한 보안 필터는 이제 "401 Unauthorized" 대신 "403 Forbidden"을 반환합니다.

클라이언트 측 필터

Cryostat-RS 2.0에 도입된 클라이언트 측 필터는 REST Cryostat 3.0 이전 릴리스의 REST Cryostat 클라이언트 API를 사용할 때 바인딩 및 실행되지 않습니다.

비동기 HTTP 지원

Cryostat-RS 2.0 사양은 @Suspended 주석 및 AsynResponse 인터페이스를 사용하여 비동기 HTTP 지원을 추가했기 때문에 비동기 HTTP의 REST Cryostat 전용 API는 더 이상 사용되지 않으며 향후 REST Cryostat 릴리스에서 제거될 수 있습니다. 비동기 Tomcat 및 비동기 JBoss Web 모듈도 서버 설치에서 제거되었습니다. Servlet 3.0 컨테이너 이상을 사용하지 않는 경우 비동기 HTTP 서버 측 처리가 시뮬레이션되어 동일한 요청 스레드에서 동시에 실행됩니다.

서버 측 캐시

서버 측 캐시 설정이 변경되었습니다. 자세한 내용은 REST Cryostat 문서를 참조하십시오.

YAML 공급자 설정 변경 사항

이전 릴리스의 JBoss EAP에서는 REST Cryostat YAML 공급자 설정이 기본적으로 활성화되어 있었습니다. 이는 JBoss EAP 7에서 변경되었습니다. 이제 YAML 공급자가 기본적으로 비활성화되어 있습니다. 그 사용은 unmarshalling에 사용되는 SnakeYAML 라이브러리의 보안 문제로 인해 지원되지 않으며 애플리케이션에서 명시적으로 활성화해야 합니다. 애플리케이션에서 YAML 공급자를 활성화하고 Maven 종속성을 추가하는 방법에 대한 자세한 내용은 JBoss EAP 7.4 Developing Web Services Applications 의 YAML 공급자 를 참조하십시오.

Content-Type Header의 기본 Charset UTF-8

JBoss EAP 7.1부터 resteasy.add.charset 매개 변수는 기본적으로 true 로 설정됩니다. 명시적 charset 없이 resource 메서드에서 text/* 또는 application/xml* 미디어 유형을 반환하면 REST Cryostat가 반환된 content-type 헤더에 charset=UTF-8 을 추가하지 않으려면 resteasy.add.charset 매개변수를 false 로 설정할 수 있습니다.

텍스트 미디어 유형 및 문자 세트에 대한 자세한 내용은 JBoss EAP 7.4 Developing Web Services Applications 의 텍스트 미디어 유형 및 문자 집합 을 참조하십시오.

SerializableProvider

신뢰할 수 없는 소스에서 Java 개체를 역직렬화하는 것은 안전하지 않습니다. 이러한 이유로 JBoss EAP 7부터 org.jboss.resteasy.plugins.providers.SerializableProvider 클래스는 기본적으로 비활성화되어 있으며 이 공급자를 사용하지 않는 것이 좋습니다.

리소스 메서드에 대한 요청 일치

REST Cryostat 3에서는 Cryostat-RS 사양에 정의된 일치 규칙 구현에 대한 개선 및 수정이 수행되었습니다. 특히 하위 리소스 메서드 및 하위 리소스 메서드의 모호한 URI를 처리하는 방법에 대한 변경이 수행되었습니다.

REST Cryostat 2에서는 동일한 URI가 있는 다른 하위 리소스가 있는 경우에도 하위 리소스를 성공적으로 실행할 수 있었습니다. 이 동작은 사양에 따라 올바르지 않았습니다.

REST Cryostat 3에서는 하위 리소스 및 하위 리소스에 대한 모호한 URI가 있는 경우 하위 리소스를 호출하는 것은 성공할 수 있지만 하위 리소스 호출은 HTTP 상태 405 Method Not Allowed 오류가 발생합니다.

다음 예제에는 하위 리소스 메서드 및 하위 리소스 Cryostat에 대한 모호한 @Path 주석이 포함되어 있습니다. 두 끝점 모두에 대한 URI, anotherResource 및 anotherResourceLocator 는 동일합니다. 두 끝점의 차이점은 anotherResource 메서드가 REST 동사인 POST 와 연결되어 있다는 것입니다. anotherResourceLocator 메서드는 REST 동사와 연결되어 있지 않습니다. 사양에 따라 REST 동사가 있는 끝점(이 경우 anotherResource 메서드)이 항상 선택됩니다.

@Path("myResource")
public class ExampleSubResources {
    @POST
    @Path("items")
    @Produces("text/plain")
    public Response anotherResource(String text) {
        return Response.ok("ok").build();
    }

    @Path("items")
    @Produces("text/plain")
    public SubResource anotherResourceLocator() {
        return new SubResource();
    }
}

REST Cryostat SPI 공급자가 JBoss EAP 8에서 제거되었습니다.

SPI Exceptions

모든 SPI 실패 예외는 더 이상 사용되지 않으며 내부적으로 사용되지 않습니다. 해당 Jakarta REST 예외로 교체되었습니다.

InjectorFactory 및 Registry

InjectorFactory 및 Registry SPI가 변경되었습니다. 문서화 및 지원되는 REST Cryostat를 사용하는 경우 이 문제는 문제가 되지 않습니다.

JBoss EAP 6.4에 포함된 jackson 버전이 변경되었습니다. JBoss EAP 7부터는 jackson 공급자가 resteasy-jackson-provider 에서 resteasy-jackson2-provider 로 변경되었습니다.

resteasy-jackson2-provider 로 업그레이드하려면 일부 패키지를 변경해야 합니다. 예를 들어 jackson 주석 패키지가 org.codehaus.jackson.annotate 에서 com.fasterxml.jackson.annotation 로 변경되었습니다.

JBoss EAP 8.0은 REST Cryostat 6.2를 지원합니다. JBoss EAP 8.0과 함께 Spring 6.0 프레임워크를 사용하려면 Java 17을 사용해야 합니다.

Spring 4.0 프레임워크에는 Java 8 지원이 도입되었습니다. REST Cryostat 3.x 통합을 Spring과 통합하려는 경우 JBoss EAP 7에서 지원하는 가장 빠른 안정적인 버전이므로 4.2.x를 배포에서 최소 Spring 버전으로 지정해야 합니다.

REST Cryostat Cryostattison JSON 공급자는 JBoss EAP 7 이후 더 이상 사용되지 않으며 기본적으로 배포에 더 이상 추가되지 않습니다. 권장되는 REST Cryostat Jackson 공급자로 전환하는 것이 좋습니다. 다음 예에 설명된 대로 Cryostat 공급자를 계속 사용하려면 jboss-deployment-descriptor.xml 파일에서 이에 대한 명시적 종속성을 정의해야 합니다.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
  <deployment>
    <exclusions>
      <module name="org.jboss.resteasy.resteasy-jackson2-provider"/>
      <module name="org.jboss.resteasy.resteasy-jackson-provider"/>
    </exclusions>
    <dependencies>
      <module name="org.jboss.resteasy.resteasy-jettison-provider" services="import"/>
    </dependencies>
  </deployment>
</jboss-deployment-structure>

명시적 종속성을 정의하는 방법에 대한 자세한 내용은 JBoss EAP 7.4 개발 가이드에서 배포에 Explicit 모듈 종속성 추가 를 참조하십시오.

MicroProfile 은 개발자가 애플리케이션을 수정하거나 다시 패키징하지 않고도 여러 환경에서 실행되도록 애플리케이션 및 마이크로서비스를 구성하는 데 사용할 수 있는 사양의 이름입니다. 이전에는 MicroProfile 을 기술 프리뷰로 JBoss EAP 7.3에서 사용할 수 있었지만 이후 제거되었습니다. MicroProfile 은 이제 JBoss EAP XP에서만 사용할 수 있습니다.

활성화된 빈의ans 클래스를 Quarkus 아카이브에 배포하여 CDI에서 검색되고 빈으로 처리되도록 해야 합니다.

CDI 1.1에서는 주석 또는 하나 이상의 세션 빈이 포함된 하나 이상의ans 클래스를 포함하는 아카이브인 암시적 chain 아카이브가 도입되었습니다. 암시적 Cryostat 아카이브는 CDI에서 스캔하며, 유형 검색 중에 annotations이 정의된 class만 검색됩니다. 자세한 내용은 Java ^™ 2.0의 Type 및 Cryostat Discovery: Contexts and dependency Cryostat for Java ™ 를 참조하십시오. 주석을 정의하는 Quarkus에 해당하는 Jakarta는 Jakarta ContextDependions 2.0 사양에 정의되어 있습니다.

In CDI 4.0:

CDI 4.0에 대한 자세한 내용은 자카르타 컨텍스트 및 종속성 4.0을 참조하십시오.

Cryostat 아카이브에는 모든 주석 또는주석 처리 모드가 있습니다. 비어 있지 않은 beans.xml을 포함하는 Cryostat 아카이브는 8080-discovery-mode 속성을 지정해야 합니다. 특성의 기본값은 주석이 있습니다.

다음과 같은 경우 아카이브는 Cryostat 아카이브가 아닙니다.

아카이브는 다음의 경우 명시적 Cryostat 아카이브입니다.

아카이브는 다음의 경우 암시적 Cryostat 아카이브입니다.

CDI 1.2 제한을 통해 주석을 다음과 같이 정의합니다.

CDI 사양 발행 CDI-411에 설명된 대로 서블릿 사양과의 충돌을 방지하기 위해 CDI 1.2에서 대화 컨텍스트 라이프사이클이 변경되었습니다. 대화 범위는 모든 서블릿 요청 중에 활성화되며 다른 서블릿 또는 서블릿 필터가 요청 본문 또는 문자 인코딩을 설정하지 못하도록해서는 안 됩니다. 자세한 내용은 Jakarta EE의 대화 컨텍스트 라이프사이클을 참조하십시오.

CDI 1.2에서 이벤트 해상도를 부분적으로 다시 작성했습니다. CDI 1.0에서 관찰자 메서드에 모든 이벤트 한정자가 있는 경우 이벤트가 관찰자 메서드로 전달됩니다. CDI 1.2에서 관찰자 메서드에 이벤트 한정자가 없거나 이벤트 한정자의 하위 집합이 있는 경우 이벤트가 관찰자 메서드로 전달됩니다. 자세한 내용은 Observer resolution 을 참조하십시오.

이 섹션에서는 Hibernate ORM 버전 5.3에서 5.4로 마이그레이션할 때 필요한 변경 사항을 중점적으로 설명합니다. Hibernate ORM 5.3과 Hibernate ORM 5.4 간에 구현된 변경 사항에 대한 자세한 내용은 Hibernate ORM 5.4 마이그레이션 가이드를 참조하십시오.

알려진 변경 사항

다음은 Hibernate ORM 버전 5.3에서 5.4로 마이그레이션할 때의 몇 가지 변경 사항에 대해 설명합니다.

이 섹션에서는 Hibernate ORM 버전 5.4에서 5.5로 마이그레이션할 때 필요한 변경 사항을 중점적으로 설명합니다. Hibernate ORM 5.4와 Hibernate ORM 5.5 간에 구현된 변경 사항에 대한 자세한 내용은 Hibernate ORM 5.5 마이그레이션 가이드를 참조하십시오.

알려진 변경 사항

Hibernate ORM 5.5 버전은 5.4 유지 관리 릴리스에 적용된 모든 버그 수정을 포함하고 Jakarta 지속성 API에 대한 지원을 도입하므로 Hibernate ORM 5.4와 유사합니다.

이 섹션에서는 Hibernate ORM 버전 5.5에서 5.6로 마이그레이션할 때 필요한 변경 사항을 중점적으로 설명합니다. Hibernate ORM 5.5 및 Hibernate ORM 5.6 간에 구현된 변경 사항에 대한 자세한 내용은 Hibernate ORM 5.6 마이그레이션 가이드를 참조하십시오.

더 이상 사용되지 않는 기능

Hibernate 5.6 버전은 이전 Hibernate 5.5 버전과 매우 유사하며, 이전 Hibernate 릴리스에서 더 이상 사용되지 않는 일부 기능은 제거되지 않습니다.

이 섹션에서는 Hibernate ORM 버전 5.6에서 6.0으로 마이그레이션할 때 필요한 변경 사항을 설명합니다. Hibernate ORM 5.6과 Hibernate ORM 6.0 간에 구현된 변경 사항에 대한 자세한 내용은 Hibernate ORM 6.0 마이그레이션 가이드를 참조하십시오.

Hibernate 6.0 릴리스에는 다음과 같은 변경 사항이 포함되어 있습니다.

이러한 기능에 대한 자세한 내용은 Hibernate ORM 6.0 마이그레이션 가이드를 참조하십시오.

Hibernate 6.0 릴리스에는 다음과 같이 나열된 이전 Hibernate 릴리스에서 많은 기능 제거 기능이 포함되어 있습니다.

Hibernate 6.0에서 제거된 기능에 대한 자세한 내용은 Hibernate ORM 6.0 마이그레이션 가이드를 참조하십시오.

이 섹션에서는 Hibernate ORM 버전 6.0에서 6.1으로 마이그레이션할 때 필요한 변경 사항을 설명합니다. Hibernate ORM 6.0과 Hibernate ORM 6.1 간에 구현된 변경 사항에 대한 자세한 내용은 Hibernate ORM 6.1 마이그레이션 가이드를 참조하십시오.

Hibernate 6.1 릴리스에는 다음과 같은 변경 사항이 포함되어 있습니다.

Hibernate 6.1에 포함된 기능에 대한 자세한 내용은 Hibernate ORM 6.1 마이그레이션 가이드를 참조하십시오.

이 섹션에서는 Hibernate ORM 버전 6.1에서 6.2로 마이그레이션할 때 필요한 변경 사항을 중점적으로 설명합니다. Hibernate ORM 6.1과 Hibernate ORM 6.2 간에 구현된 변경 사항에 대한 자세한 내용은 Hibernate ORM 6.2 마이그레이션 가이드를 참조하십시오.

Hibernate 6.2 릴리스에는 다음과 같은 향상된 기능이 포함되어 있습니다.

DDL 유형 변경:

JBoss EAP 7.0에는 Hibernate ORM 5.0이 포함되어 있습니다. 이 섹션에서는 Hibernate ORM 버전 4.3에서 버전 5로 마이그레이션할 때 필요한 변경 사항을 중점적으로 설명합니다. Hibernate ORM 4와 Hibernate ORM 5 간에 구현된 변경 사항에 대한 자세한 내용은 Hibernate ORM 5.0 마이그레이션 가이드를 참조하십시오.

제거 및 더 이상 사용되지 않는 클래스

다음의 더 이상 사용되지 않는 클래스는 Hibernate ORM 5에서 제거되었습니다.

클래스 및 패키지에 대한 기타 변경 사항

유형 처리

트랜잭션 관리

기타 Hibernate ORM 5 변경

JBoss EAP 7.1에는 Hibernate ORM 5.1이 포함되어 있습니다. 이 섹션에서는 Hibernate ORM 버전 5.0에서 버전 5.1로 마이그레이션할 때 필요한 차이점과 변경 사항을 중점적으로 설명합니다.

Hibernate ORM 5.1 기능

이 Hibernate 릴리스에는 성능 개선 및 버그 수정이 포함되어 있습니다. 자세한 내용은 7.1.0용 JBoss EAP 릴리스 노트 의 Hibernate ORM 5.1 기능을 참조하십시오. Hibernate ORM 5.0과 Hibernate ORM 5.1 간에 구현된 변경 사항에 대한 자세한 내용은 Hibernate ORM 5.1 마이그레이션 가이드를 참조하십시오.

스키마 관리 툴링 변경

JBoss EAP 7의 스키마 관리 툴 변경

Hibernate ORM 5.1의 스키마 관리 툴링 변경 사항은 다음 영역에 중점을 두고 있습니다.

스키마 관리 툴링 변경은 다음 클래스를 직접 사용하는 애플리케이션의 마이그레이션 문제일 뿐입니다.

JBoss EAP 7.1의 스키마 관리 툴 변경

JBoss EAP 7.1에 포함된 Hibernate ORM 5.1.10에는 SchemaMigrator 및 SchemaValidator 성능을 개선하는 데이터베이스 테이블을 검색하는 전략이 도입되었습니다. 이 전략은 단일 java.sql.DatabaseMetaData#getTables(String, string, String, String, String[]) 호출을 실행하여 각 javax.persistence.Entity 에 매핑된 데이터베이스 테이블이 있는지 확인합니다. 이는 기본 전략이며 hibernate.hbm2ddl.jdbc_metadata_extraction_strategy=grouped 속성 설정을 사용합니다. 이 전략을 사용하려면 hibernate.default_schema 및/또는 hibernate.default_catalog 가 필요할 수 있습니다.

java.sql.DatabaseMetaData#getTables(String, String, String, String, String[]) 호출의 이전 전략을 사용하려면 hibernate . hbm2ddl.jdbc_metadata_extraction_strategy=individually 속성 설정을 사용합니다.

JBoss EAP 7.4에는 Hibernate ORM 5.3이 포함되어 있습니다. 이 섹션에서는 Hibernate ORM 5.1에서 Hibernate ORM 5.2로 마이그레이션한 다음 Hibernate ORM 5.3으로 마이그레이션할 때 필요한 몇 가지 변경 사항을 중점적으로 설명합니다.

Hibernate ORM 5.2 기능

Hibernate ORM 5.2는 Java 8 JDK를 사용하여 구축되었으며 런타임 시 Java 8 JRE가 필요합니다. 다음은 이 릴리스에서 수행된 일부 변경 사항 목록입니다.

Hibernate 5.2에서 구현된 변경 사항의 전체 목록은 Hibernate ORM 5.2 마이그레이션 가이드를 참조하십시오.

Hibernate ORM 5.3 기능

Hibernate ORM 5.3에서는 자카르타 지속성 2.2 사양에 대한 지원이 추가되었습니다. 이 릴리스에는 기타 개선 사항과 함께 이 사양을 준수하기 위한 변경 사항이 포함되어 있습니다. 다음은 이러한 변경 사항 중 일부 목록입니다.

Hibernate 5.3에서 구현된 이러한 변경 사항 및 기타 변경 사항의 전체 목록은 Hibernate ORM 5.3 마이그레이션 가이드를 참조하십시오.

Hibernate 5.1과 Hibernate 5.3 간의 변경 사항 예외 처리

Hibernate 5.2 및 5.3에서는 Hibernate의 네이티브 부트스트랩을 사용하여 구축된 SessionFactory 에 대한 예외 처리, Jakarta Persistence 사양에 따라 HibernateException 을 래핑하거나 변환합니다. 이 동작에 대한 유일한 예외는 작업이 Hibernate에 특정한 경우입니다(예: Session.save() 또는 Session.saveOrUpdate() ).

Hibernate 5.3.3에서는 hibernate.native_exception_handling_51_compliance 속성이 추가되었습니다. 이 속성은 Hibernate의 네이티브 부트스트랩을 사용하여 구축된 SessionFactory 에 대한 예외 처리가 Hibernate ORM 5.1의 기본 예외 처리와 동일하게 작동하는지 여부를 나타냅니다. true 로 설정하면HibernateException 이 Jakarta Persistence 사양에 따라 래핑되거나 변환되지 않습니다. 이 설정은 Jakarta Persistence 부트스트랩을 사용하여 빌드된 SessionFactory 에서 무시됩니다.

호환성 변환기

JBoss EAP 7.4에는 더 이상 Hibernate ORM 5.1과 호환되지 않는 Hibernate ORM 5.3 API 방법을 처리하는 호환성 변형기가 포함되어 있습니다. 변환기는 Hibernate ORM 5.1을 사용하여 빌드된 애플리케이션이 JBoss EAP 7.4의 Hibernate 5.3과 동일한 동작을 표시할 수 있도록 하는 임시 조치입니다. 임시 솔루션이므로 이러한 메서드 호출을 권장되는 Jakarta 지속성 메서드 호출로 교체해야 합니다.

다음 방법 중 하나로 변환기를 활성화할 수 있습니다.

다음 표에는 변환된 Hibernate 5.1 방법과 다음과 같은 Hibernate 5.3 방법이 나열되어 있습니다.

Hibernate Search 5 API가 제거되었으며 JBoss EAP 8.0에서 Hibernate Search 6 API로 대체되었습니다.

제거된 기능 목록을 보려면 JBoss EAP 7.4에서 더 이상 사용되지 않고 EAP 8.0에서 제거된 Hibernate Search 5 API를 참조하십시오.

JBoss EAP 8.0에 포함된 Hibernate Search 6의 최신 버전은 6.2입니다. Hibernate Search 5에서 마이그레이션하는 경우 버전 6.0, 6.1 및 6.2로 마이그레이션해야 합니다.

자세한 내용은 다음 마이그레이션 가이드를 참조하십시오.

JBoss EAP 8.0은 또한 Hibernate Search 6의 Elasticsearch 백엔드를 사용하여 데이터를 원격 Elasticsearch 또는 OpenSearch 클러스터로 인덱싱할 수 있도록 지원합니다.

가능한 Hibernate 검색 아키텍처 및 백엔드 목록을 보려면 테이블 2를 참조하십시오. Hibernate Search 6.2 참조 문서의 아키텍처 비교.

Hibernate Search 6 구성에 대한 자세한 내용은 WildFly Developer 가이드의 Hibernate 검색 사용을 참조하십시오.

JBoss EAP 7부터 기본 원격 커넥터 및 포트가 변경되었습니다. 이 변경 사항에 대한 자세한 내용은 원격 URL 커넥터 및 포트 업데이트를 참조하십시오.

JBoss Server 마이그레이션 도구를 사용하여 서버 구성을 마이그레이션한 경우 이전 설정이 유지되며 여기에 자세히 변경할 필요가 없습니다. 그러나 새 JBoss EAP 8.0 기본 구성을 사용하는 경우 다음과 같은 사항을 변경해야 합니다.

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=8080
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

새로운 기본 JBoss EAP 7 구성으로 실행하는 경우 새 기본 원격 포트와 커넥터를 사용하도록 클라이언트 코드를 수정해야 합니다.

다음은 JBoss EAP 6의 클라이언트 코드에 원격 이름 지정 속성을 지정하는 방법의 예입니다.

java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=remote://localhost:4447

다음은 JBoss EAP 7의 클라이언트 코드에서 원격 이름 지정 속성을 지정하는 방법의 예입니다.

java.naming.factory.initial=org.wildfly.naming.client.WildFlyInitialContextFactory
java.naming.provider.url=http-remoting://localhost:8080

JBoss EAP 7.0은 JBoss Enterprise Java Cryostat 클라이언트 2.1.4에 포함되어 있으며 JBoss EAP 7.1 이상은 API에 대한 여러 변경 사항이 포함된 JBoss Enterprise Java Cryostat 클라이언트 4.0.x에 포함되었습니다.

JBoss EAP 6.4에서 AuthenticatorBase 를 확장한 사용자 정의 인증기를 생성한 경우 이를 JBoss EAP 7에서 사용자 지정 HTTP 인증 구현으로 교체해야 합니다. HTTP 인증 메커니즘은 elytron 하위 시스템에서 생성된 다음 undertow 하위 시스템에 등록됩니다. 사용자 지정 HTTP 인증 메커니즘을 구현하는 방법에 대한 자세한 내용은 JBoss EAP 7.4 개발 가이드에서 사용자 지정 HTTP 메커니즘 개발을 참조하십시오.

CryostatetLink가 JBoss EAP 8.0에서 제거되었습니다.

PicketLink SP

CryostatetLink 서비스 공급자 대신 Keycloak SAML 어댑터를 사용합니다.

Keycloak SAML 어댑터를 구성하여>-<etLink에서 마이그레이션하려면 다음 작업을 수행합니다.

PicketLink IDP

CryostatetLink IDP는 JBoss EAP 8.0 이후 사용할 수 없으며 Red Hat build of Keycloak을 대신 구성할 수 있습니다. 자세한 내용은 Red Hat build of Keycloak 구성을 참조하십시오.

PicketLink STS

이전 릴리스에서는 Apache CXF 보안 토큰 서비스 구현의 대안으로 CryostatetLink STS를 구성할 수 있습니다. CryostatetLink STS 구성에는 레거시 보안 도메인이 포함됩니다. 기존 보안 도메인 및 STS 애플리케이션의 CryostatetLink에 대한 참조를 제거해야 하므로 대신 Apache CXF STS를 구성해야 합니다.

Apache CXF STS를 구성하는 방법에 대한 자세한 내용은 JBoss EAP 7.4 Developing Web Services Applications 의 STS(Security Token Service) 를 참조하십시오.

자격 증명 모음이 JBoss EAP 8.0에서 제거되었습니다. 애플리케이션에서 레거시 vault 표현식을 사용하는 경우 Elytron 암호화된 표현식을 마이그레이션하고 사용해야 합니다.

주석 또는 배포 설명자에 있을 수 있는 배포 파일에서 ${VAULT:: 인스턴스를 확인하고 해당 암호화된 표현식으로 교체합니다.

Keycloak OIDC 클라이언트 어댑터는 JBoss EAP 8.0에서 지원되지 않으며 기본 Elytron OIDC 클라이언트로 교체되어 유사한 기능과 구성을 제공합니다.

Keycloak OIDC 클라이언트 어댑터에서 기본 Elytron OIDC 클라이언트로 마이그레이션하려면 다음 단계를 따르십시오.

JBoss EAP 8.0에서는 레거시 보안 하위 시스템이 제거되었습니다. elytron 하위 시스템에서 사용자 지정 로그인 모듈을 계속 사용하려면 새로운 JAAS(Java Authentication and Authorization Service) 보안 영역과 jaas-realm 을 사용합니다.

JBoss EAP 7.2 이상과 이전 버전에는 몇 가지 차이점이 있습니다.

다음 목록에서는 애플리케이션을 JBoss EAP 6에서 JBoss EAP 8.0으로 마이그레이션할 때 알아야 할 새로운 클러스터링 기능 중 일부를 설명합니다.

JBoss EAP 7에는 새로운 웹 세션 클러스터링 구현이 도입되었습니다. 기존 JBoss Web 하위 시스템 소스 코드와 긴밀하게 연결된 이전 구현을 대체합니다.

새로운 웹 세션 클러스터링 구현은 애플리케이션을 jboss-web.xml JBoss EAP 소유 웹 애플리케이션 XML 설명자 파일에 구성하는 방법에 영향을 미칩니다. 다음은 이 파일에 남아 있는 유일한 클러스터링 구성 요소입니다.

<jboss-web>
  ...
  <max-active-sessions>...</max-active-sessions>
  ...
  <replication-config>
    <replication-granularity>...</replication-granularity>
    <cache-name>...</cache-name>
  </replication-config>
  ...
</jboss-web>

distributable-web 하위 시스템은 jboss-web.xml 의 < replication-config > 요소를 더 이상 사용하지 않습니다. 임시 배포 가능한 웹 세션 프로필을 생성하여 &lt ;replication-config >의 사용을 향상시킵니다.

세션 관리 프로필을 이름 또는 배포별 세션 관리 구성을 제공하여 기본 배포 가능한 세션 관리 동작을 재정의할 수 있습니다. 자세한 내용은 기본 배포 가능한 세션 관리 동작 덮어쓰기를 참조하십시오.

다음 표에서는 현재 사용되지 않는 jboss-web.xml 파일의 요소에 대해 유사한 동작을 수행하는 방법을 설명합니다.

이 새로운 구현에서는 write-through 캐시 저장소와 passivation 전용 캐시 저장소도 지원합니다. 일반적으로 나중 쓰기 캐시 저장소는 무효화 캐시와 함께 사용됩니다. 무효화 캐시와 함께 사용하면 JBoss EAP 6의 웹 세션 클러스터링 구현이 제대로 작동하지 않았습니다.

다음 방법 중 하나로 기본 배포 가능 세션 관리 동작을 재정의할 수 있습니다.

기존 세션 관리 프로필 참조

/WEB-INF/distributable-web.xml

<?xml version="1.0" encoding="UTF-8"?>
<distributable-web xmlns="urn:jboss:distributable-web:1.0">
    <session-management name="foo"/>
</distributable-web>

/META-INF/jboss-all.xml

<?xml version="1.0" encoding="UTF-8"?>
<jboss xmlns="urn:jboss:1.0">
    <distributable-web xmlns="urn:jboss:distributable-web:1.0">
        <session-management name="foo"/>
    </distributable-web>
</jboss>

배포별 세션 관리 프로필 사용

단일 웹 애플리케이션만 사용자 지정 세션 관리 구성을 사용하는 경우 배포 설명자 자체 내에서 구성을 정의할 수 있습니다. 애드혹 구성은 distributable-web 하위 시스템에서 사용하는 구성과 동일합니다.

/WEB-INF/distributable-web.xml

<?xml version="1.0" encoding="UTF-8"?>
<distributable-web xmlns="urn:jboss:distributable-web:1.0">
    <infinispan-session-management cache-container="foo" cache="bar" granularity="SESSION">
        <primary-owner-affinity/>
    </infinispan-session-management>
</distributable-web>

/META-INF/jboss-all.xml

<?xml version="1.0" encoding="UTF-8"?>
<jboss xmlns="urn:jboss:1.0">
    <distributable-web xmlns="urn:jboss:distributable-web:1.0">
        <infinispan-session-management cache-container="foo" cache="bar" granularity="ATTRIBUTE">
            <local-affinity/>
        </infinispan-session-management>
    </distributable-web>
</jboss>

JBoss EAP 6에서는 다음 방법 중 하나로 SFSB(상태 저장 세션 빈)에 대한 클러스터링 동작을 활성화해야 했습니다.

JBoss EAP 7부터 더 이상 클러스터링 동작을 활성화할 필요가 없습니다. 기본적으로 HA 프로필을 사용하여 서버를 시작하면 SFSB의 상태가 자동으로 복제됩니다. 다음 방법 중 하나로 이 기본 동작을 비활성화할 수 있습니다.

JBoss EAP 6에서 클러스터링 서비스 API는 개인 모듈에 있으며 지원되지 않았습니다.

JBoss EAP 7에는 애플리케이션에서 사용할 수 있는 공용 클러스터링 서비스 API가 도입되었습니다. 새로운 서비스는 경량화되고 쉽게 삽입할 수 있도록 설계되었으며 외부 종속성이 필요하지 않습니다.

이러한 서비스는 이전 릴리스에서 사용 가능한 유사한 API, 즉 JBoss EAP 5 및 GroupCommunicationService,GroupMembershipNotifier 및 GroupRpcDispatcher 의 JBoss EAP 6에서 사용 가능한 유사한 API를 대체합니다.

자세한 내용은 JBoss EAP 7.4 개발 가이드의 public API for Cryostat 서비스를 참조하십시오.

JBoss EAP 6에서는 클러스터 전체 HA 싱글톤 서비스에 사용할 수 있는 공용 API가 없었습니다. 개인 org.jboss.as.clustering.singleton.* 클래스를 사용한 경우 애플리케이션을 JBoss EAP 8로 마이그레이션할 때 새 공개 org.wildfly.clustering.singleton.* 패키지를 사용하도록 코드를 변경해야 합니다.

HA 싱글톤 서비스에 대한 자세한 내용은 JBoss EAP 7.4 Development Guide 의 HA Singleton 서비스를 참조하십시오. HA Singleton 배포에 대한 자세한 내용은 JBoss EAP 7.4 Development Guide 의 HA Singleton 배포를 참조하십시오.

IBM MQ는 분산 시스템의 애플리케이션이 서로 통신할 수 있는 IBM의 메시징 오리엔드 미들웨어(MOM) 제품입니다. 이는 메시지 및 메시지 큐를 사용하여 수행됩니다. IBM MQ는 메시지 큐에 메시지를 전달하고 메시지 채널을 사용하여 다른 대기열 관리자에게 데이터를 전송합니다. IBM MQ에 대한 자세한 내용은 IBM MQ on the IBM products website를 참조하십시오.

요약

IBM MQ는 JBoss EAP 8.0의 외부 Java Message Service 공급자로 구성할 수 있습니다. 이 섹션에서는 JBoss EAP에서 IBM MQ 리소스 어댑터를 배포하고 구성하는 단계를 설명합니다. 이 배포 및 구성은 관리 CLI 도구 또는 웹 기반 관리 콘솔을 사용하여 수행할 수 있습니다. IBM MQ의 지원되는 구성에 대한 최신 정보는 JBoss EAP 지원 구성을 참조하십시오.

JBoss EAP 8.0은 자카르타 EE 10 구현이므로 모든 EE API에 사용되는 패키지가 javax에서 jakarta로 변경되었으며 Jakarta EE 10 호환 리소스 어댑터가 필요합니다. JBoss EAP 7.x 이전 버전에서 IBM MQ Resource 어댑터를 사용하는 경우 이 jakarta 네임스페이스를 사용하는 IBM MQ Resource Adapter인 wmq.jakarta.jmsra.rar 를 사용해야 합니다.

@ActivationConfigProperty(propertyName = "destination", propertyValue = "QUEUE")

@JMSConnectionFactoryDefinition(
    name = "java:/jms/WMQConnectionFactory",
    interfaceName = "javax.jms.ConnectionFactory",
    resourceAdapter = "wmq.jmsra",
    properties = {
        "channel=<channel>",
        "hostName=<hostname_wmq_broker>",
        "transportType=<transport_type>",
        "queueManager=<queue_manager>"
    }
)

@Inject
@JMSConnectionFactory("jms/CF")
@JMSPasswordCredential(userName="myusername", password="mypassword")
@JMSSessionMode(JMSContext.DUPS_OK_ACKNOWLEDGE)
transient JMSContext context3;

WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri] (EJB default - 7) IJ000604: Throwable while attempting to get a new connection: null: com.ibm.mq.connector.DetailedResourceException: MQJCA1011: Failed to allocate a JMS connection., error code: MQJCA1011 An internal error caused an attempt to allocate a connection to fail. See the linked exception for details of the failure.

QueueConnection qc = queueConnectionFactory.createQueueConnection("invalidUserName", "invalidPassword");

SVR-ERROR: Expected JMSException, received com.ibm.mq.connector.outbound.MQQueueProxy cannot be cast to com.ibm.mq.jms.MQDestination

ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /jmsServlet-1.0-SNAPSHOT/: com.ibm.msg.client.jms.DetailedJMSRuntimeException: MQJCA0002: An exception occurred in the IBM MQ layer. See the linked exception for details.
A call to IBM MQ classes for Java(tm) caused an exception to be thrown.

SVR-ERROR: com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ2007: Failed to send a message to destination 'MDB_NAME TOPIC_NAME'

com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2072' ('MQRC_SYNCPOINT_NOT_AVAILABLE')

JBoss EAP 8부터 Apache Log4j 버전 1 API에 대한 지원이 중지되었습니다. log4j.jar 및 log4j 구성을 패키징하지 않은 모든 애플리케이션을 업데이트해야 합니다.

영향:

로그 메시지는 로깅 하위 시스템을 기반으로 더 이상 라우팅되지 않습니다. 애플리케이션이 log4j.jar 패키징하지 않고 다음 명령문 중 하나라도 true인 경우 마이그레이션 변경 사항이 필요합니다.

마이그레이션:

또는

추가 세부 정보:

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
  <deployment>
    <exclude-subsystems>
      <subsystem name="logging"/>
    </exclude-subsystems>
  </deployment>
</jboss-deployment-structure>

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
  <sub-deployment name="example.war">
    <exclude-subsystems>
      <subsystem name="logging"/>
    </exclude-subsystems>
  </sub-deployment>
</jboss-deployment-structure>

<subsystem xmlns="urn:jboss:domain:logging:8.0">
    <add-logging-api-dependencies value="false"/>
  ...
</subsystem>

자세한 내용은 JBoss EAP 8.0에서 Apache Log4j 버전 1이 더 이상 제공되지 않음을 참조하십시오.

JBoss EAP 7.0의 레거시 보안 하위 시스템에서 일반 텍스트 문자열 암호화를 저장하는 데 사용되는 보안 자격 증명 모음은 JBoss EAP 7.1 이상에서 Elytron과 호환되지 않습니다. JBoss EAP 7.1 이상에서는 자격 증명 저장소를 사용하여 문자열을 저장합니다. 자격 증명은 JBoss EAP 구성 파일 외부의 스토리지 파일에 암호화 자격 증명을 저장합니다. Elytron에서 제공하는 구현을 사용하거나 인증 정보 저장소 API 및 SPI를 사용하여 구성을 사용자 지정할 수 있습니다. 각 JBoss EAP 서버에는 여러 인증 정보 저장소가 포함될 수 있습니다.

인증 정보 저장소에 대한 자세한 내용은 JBoss EAP 7.4 서버 보안 구성 방법의 인증 정보 저장소를 참조하십시오.

$ EAP_HOME/bin/elytron-tool.sh vault VAULT_ARGUMENTS

$ EAP_HOME/bin/elytron-tool.sh vault --help

$ EAP_HOME/bin/elytron-tool.sh vault --enc-dir vault_data/ --keystore vault-jceks.keystore --keystore-password MASK-2hKo56F1a3jYGnJwhPmiF5 --iteration 34 --salt 12345678 --alias test --location cs-v1.store --summary

Vault (enc-dir="vault_data/";keystore="vault-jceks.keystore") converted to credential store "cs-v1.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="cs-v1.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})

keystore:vault-v1/vault-jceks.keystore
keystore-password:MASK-2hKo56F1a3jYGnJwhPmiF5
enc-dir:vault-v1/vault_data/
salt:12345678
iteration:34
location:v1-cs-1.store
alias:test

keystore:vault-v1/vault-jceks.keystore
keystore-password:secretsecret
enc-dir:vault-v1/vault_data/
location:v1-cs-2.store
alias:test

# different vault vault-v1-more
keystore:vault-v1-more/vault-jceks.keystore
keystore-password:MASK-2hKo56F1a3jYGnJwhPmiF5
enc-dir:vault-v1-more/vault_data/
salt:12345678
iteration:34
location:v1-cs-more.store
alias:test

$ EAP_HOME/bin/elytron-tool.sh vault --bulk-convert path/to/bulk-vault-conversion-descriptor.txt --summary

Vault (enc-dir="vault-v1/vault_data/";keystore="vault-v1/vault-jceks.keystore") converted to credential store "v1-cs-1.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-1.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})
--------------------------------------

Vault (enc-dir="vault-v1/vault_data/";keystore="vault-v1/vault-jceks.keystore") converted to credential store "v1-cs-2.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-2.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="secretsecret"})
--------------------------------------

Vault (enc-dir="vault-v1-more/vault_data/";keystore="vault-v1-more/vault-jceks.keystore") converted to credential store "v1-cs-more.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-more.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})
--------------------------------------

다음 예제에서는 group.name 및 encoding.algorithm 보안 속성이 레거시 보안 하위 시스템에서 security -properties 로 정의되었다고 가정합니다.

보안 에 정의된 보안 속성:

<subsystem xmlns="urn:jboss:domain:security:2.0">
    ...
    <security-properties>
        <property name="group.name" value="engineering-group" />
        <property name="encoding.algorithm" value="BASE64" />
    </security-properties>
</subsystem>

elytron 하위 시스템에서 이러한 보안 속성을 정의하려면 다음 관리 CLI 명령을 사용하여 elytron 하위 시스템의 security-properties 속성을 설정합니다.

/subsystem=elytron:write-attribute(name=security-properties, value={ group.name = "engineering-group", encoding.algorithm = "BASE64" })

서버 구성 파일의 elytron 하위 시스템에서 security-properties 를 정의합니다.

<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
    <security-properties>
        <security-property name="group.name" value="engineering-group"/>
        <security-property name="encoding.algorithm" value="BASE64"/>
    </security-properties>
    ...
</subsystem>

이전 명령의 write-attribute 작업은 기존 속성을 덮어씁니다. 다른 보안 속성에 영향을 주지 않고 보안 속성을 추가하거나 변경하려면 관리 CLI 명령에서 맵 작업을 사용합니다.

/subsystem=elytron:map-put(name=security-properties, key=group.name, value=technical-support)

유사한 방식으로 map-remove 작업을 사용하여 특정 보안 속성을 제거할 수 있습니다.

/subsystem=elytron:map-remove(name=security-properties, key=group.name)

다음 예제를 사용하여 controlPlaneetBox 속성 기반 인증을 Elytron으로 마이그레이션합니다.

/subsystem=security/security-domain=application-security:add
/subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[{code=UsersRoles, flag=Required, module-options={usersProperties=file://${jboss.server.config.dir}/example-users.properties, rolesProperties=file://${jboss.server.config.dir}/example-roles.properties}}])

그러면 다음 서버 구성이 생성됩니다.

<security-domain name="application-security">
  <authentication>
    <login-module code="UsersRoles" flag="required">
      <module-option name="usersProperties" value="file://${jboss.server.config.dir}/example-users.properties"/>
      <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/example-roles.properties"/>
    </login-module>
  </authentication>
</security-domain>

이 섹션에서는 사용자, 암호 및 그룹 정보를 속성 파일에서 JBoss EAP 7.4 및 이전 버전에서 Elytron으로 로드하는 레거시 보안 영역을 마이그레이션하는 방법을 설명합니다. 이러한 유형의 기존 보안 영역은 일반적으로 관리 인터페이스를 보호하거나 커넥터를 제거하는 데 사용되었습니다.

JBoss EAP 8.0에서는 filesystem-realm이 properties-realm보다 선호됩니다.

/core-service=management/security-realm=ApplicationSecurity:add
/core-service=management/security-realm=ApplicationSecurity/authentication=properties:add(relative-to=jboss.server.config.dir, path=example-users.properties, plain-text=true)
/core-service=management/security-realm=ApplicationSecurity/authorization=properties:add(relative-to=jboss.server.config.dir, path=example-roles.properties)

그러면 다음 서버 구성이 생성됩니다.

<security-realm name="ApplicationSecurity">
  <authentication>
    <properties path="example-users.properties" relative-to="jboss.server.config.dir" plain-text="true"/>
  </authentication>
  <authorization>
    <properties path="example-roles.properties" relative-to="jboss.server.config.dir"/>
  </authorization>
</security-realm>

Elytron 보안을 애플리케이션 서버에 추가하는 이유 중 하나는 서버에서 일관된 보안 솔루션을 사용할 수 있도록 하는 것이었습니다. 속성 기반 레거시 보안 영역을 Elytron으로 마이그레이션하기 위한 초기 단계는 Elytron으로 ChecketBox 속성 기반 인증을 마이그레이션하는 데 사용되는 것과 유사합니다. 다음 단계에 따라 속성 기반 레거시 보안 영역을 Elytron으로 마이그레이션합니다.

기존 속성 기반 구성을 Elytron으로 마이그레이션하는 작업이 완료되었습니다.

elytron.sh 툴의 filesystem-realm 명령을 사용하여 레거시 속성 기반 보안 영역을 Elytron의 파일 시스템 기반 영역으로 마이그레이션합니다.

파일 시스템 기반 영역은 Elytron에서 사용자 ID를 저장하는 데 사용하는 파일 시스템 기반 ID 저장소입니다. filesystem-realm 명령은 properties-realm 파일을 filesystem-realm 로 변환합니다. 또한 이 영역과 보안 도메인을 elytron 하위 시스템에 추가하기 위한 명령을 생성합니다.

정보를 ID 속성으로 관리할 수 있도록 레거시 LDAP 인증을 Elytron으로 마이그레이션합니다.

다음 예제에서는 그룹 또는 역할 정보가 LDAP에서 직접 로드되고 기존 LDAP 인증이 다음과 같이 구성되어 있다고 가정합니다.

<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-realms>
    ...
    <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true">
      <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
        <attribute-mapping>
          <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
        </attribute-mapping>
      </identity-mapping>
    </ldap-realm>
  </security-realms>
  ...
  <dir-contexts>
    <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system">
      <credential-reference clear-text="secret"/>
    </dir-context>
  </dir-contexts>
</subsystem>

JDBC 데이터 소스 기반 CryostatetBox 인증을 Elytron으로 마이그레이션합니다. 보안 도메인 정의, 인증 팩토리를 정의하고 인증을 위해 매핑하는 방법은 속성 기반 인증 및 권한 부여 마이그레이션을 참조하십시오.

다음 예제에서는 사용자 인증 데이터가 다음 예제와 유사한 구문을 사용하여 생성된 데이터베이스 테이블에 저장된다고 가정합니다.

CREATE TABLE User (
    id BIGINT NOT NULL,
    username VARCHAR(255),
    password VARCHAR(255),
    role ENUM('admin', 'manager', 'user'),
    PRIMARY KEY (id),
    UNIQUE (username)
)

인증 목적을 위해 사용자 이름은 username 열에 저장된 데이터와 일치하며 암호 열에 암호 가 16으로 인코딩된 MD5 해시로 저장되고 권한 부여 목적으로 사용자 역할은 역할 열에 저장됩니다.

CryostatetBox 보안 도메인은 JBDC 데이터 소스를 사용하여 데이터베이스 테이블에서 데이터를 검색한 다음 이를 사용하여 사용자 이름과 암호를 확인하고 역할을 할당하도록 구성됩니다. picketBox 보안 도메인이 다음 관리 CLI 명령을 사용하여 구성되어 있다고 가정합니다.

/subsystem=security/security-domain=application-security:add
/subsystem=security/security-domain=application-security/authentication=classic:add( login-modules=[ { code=Database, flag=Required, module-options={ dsJndiName="java:jboss/datasources/ExampleDS", principalsQuery="SELECT password FROM User WHERE username = ?", rolesQuery="SELECT role, 'Roles' FROM User WHERE username = ?", hashAlgorithm=MD5, hashEncoding=base64 } } ] )

그러면 레거시 보안 하위 시스템에 다음과 같은 로그인 모듈 구성이 생성됩니다.

<subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    ...
    <security-domain name="application-security">
      <authentication>
        <login-module code="Database" flag="required">
          <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
          <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/>
          <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/>
          <module-option name="hashAlgorithm" value="MD5"/>
          <module-option name="hashEncoding" value="base64"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

/subsystem=elytron/jdbc-realm=jdbc-realm:add(principal-query=[ { data-source=ExampleDS, sql="SELECT role, password FROM User WHERE username = ?", attribute-mapping=[{index=1, to=Roles } ] simple-digest-mapper={algorithm=simple-digest-md5, password-index=2} } ] )

<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-realms>
    ...
    <jdbc-realm name="jdbc-realm">
      <principal-query sql="SELECT role, password FROM User WHERE username = ?" data-source="ExampleDS">
        <attribute-mapping>
          <attribute to="Roles" index="1"/>
        </attribute-mapping>
        <simple-digest-mapper password-index="2"/>
      </principal-query>
    </jdbc-realm>
    ...
  </security-realms>
  ...
</subsystem>

Kerberos 구성으로 작업할 때 JBoss EAP 서버는 환경의 구성 정보를 사용하거나 시스템 속성을 사용하여 키 구성을 지정할 수 있습니다.

이러한 시스템 속성은 레거시 구성과 마이그레이션된 Elytron 구성에 모두 적용할 수 있습니다.

# Enable debugging
/system-property=sun.security.krb5.debug:add(value=true)
# Identify the Kerberos realm to use
/system-property=java.security.krb5.realm:add(value=ELYTRON.ORG)
# Identify the address of the KDC
/system-property=java.security.krb5.kdc:add(value=kdc.elytron.org)

<system-properties>
  <property name="sun.security.krb5.debug" value="true"/>
  <property name="java.security.krb5.realm" value="ELYTRON.ORG"/>
  <property name="java.security.krb5.kdc" value="kdc.elytron.org"/>
</system-properties>

인증 메커니즘에 따라 다음 마이그레이션 옵션 중 하나를 선택합니다.

/core-service=management/security-realm=Kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos/keytab=HTTP\/test-server.elytron.org@ELYTRON.ORG:add(path=/path/to/test-server.keytab, debug=true)
/core-service=management/security-realm=Kerberos/authentication=kerberos:add(remove-realm=true)

<security-realms>
  ...
  <security-realm name="Kerberos">
    <server-identities>
      <kerberos>
        <keytab principal="HTTP/test-server.elytron.org@ELYTRON.ORG" path="/path/to/test-server.keytab" debug="true"/>
      </kerberos>
    </server-identities>
    <authentication>
      <kerberos remove-realm="true"/>
    </authentication>
  </security-realm>
</security-realms>

# Define the first security domain
/subsystem=security/security-domain=host:add
/subsystem=security/security-domain=host/authentication=classic:add
/subsystem=security/security-domain=host/authentication=classic/login-module=1:add(code=Kerberos, flag=Required, module-options={storeKey=true, useKeyTab=true, principal=HTTP/test-server.elytron.org@ELYTRON.ORG, keyTab=path/to/test-server.keytab, debug=true}

# Define the second SPNEGO security domain
/subsystem=security/security-domain=SPNEGO:add
/subsystem=security/security-domain=SPNEGO/authentication=classic:add
/subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=1:add(code=SPNEGO, flag=requisite,  module-options={password-stacking=useFirstPass, serverSecurityDomain=host})
/subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=1:write-attribute(name=module, value=org.jboss.security.negotiation)
/subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=2:add(code=UsersRoles, flag=required, module-options={password-stacking=useFirstPass, usersProperties=  /path/to/kerberos/spnego-users.properties, rolesProperties=  /path/to/kerberos/spnego-roles.properties, defaultUsersProperties=  /path/to/kerberos/spnego-users.properties, defaultRolesProperties=  /path/to/kerberos/spnego-roles.properties})

<subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    ...
    <security-domain name="host">
      <authentication>
        <login-module name="1" code="Kerberos" flag="required">
          <module-option name="storeKey" value="true"/>
          <module-option name="useKeyTab" value="true"/>
          <module-option name="principal" value="HTTP/test-server.elytron.org@ELYTRON.ORG"/>
          <module-option name="keyTab" value="/path/to/test-server.keytab"/>
          <module-option name="debug" value="true"/>
        </login-module>
      </authentication>
    </security-domain>
    <security-domain name="SPNEGO">
      <authentication>
        <login-module name="1" code="SPNEGO" flag="requisite" module="org.jboss.security.negotiation">
          <module-option name="password-stacking" value="useFirstPass"/>
          <module-option name="serverSecurityDomain" value="host"/>
        </login-module>
        <login-module name="2" code="UsersRoles" flag="required">
          <module-option name="password-stacking" value="useFirstPass"/>
          <module-option name="usersProperties" value="path/to/kerberos/spnego-users.properties"/>
          <module-option name="rolesProperties" value="  /path/to/kerberos/spnego-roles.properties"/>
          <module-option name="defaultUsersProperties" value="  /path/to/kerberos/spnego-users.properties"/>
          <module-option name="defaultRolesProperties" value="  /path/to/kerberos/spnego-roles.properties"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

/core-service=management/security-realm=Kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos/keytab=remote\/test-server.elytron.org@ELYTRON.ORG:add(path=path/to/remote-test-server.keytab, debug=true)
/core-service=management/security-realm=Kerberos/authentication=kerberos:add(remove-realm=true)

<management>
  <security-realms>
    ...
    <security-realm name="Kerberos">
      <server-identities>
        <kerberos>
          <keytab principal="remote/test-server.elytron.org@ELYTRON.ORG" path="path/to/remote-test-server.keytab" debug="true"/>
        </kerberos>
      </server-identities>
      <authentication>
        <kerberos remove-realm="true"/>
      </authentication>
    </security-realm>
  </security-realms>
  ...
</management>

<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="KerberosDomain" default-realm="kerberos-properties" permission-mapper="default-permission-mapper">
      <realm name="kerberos-properties" role-decoder="groups-to-roles"/>
    </security-domain>
  </security-domains>
  <security-realms>
   ...
     <properties-realm name="kerberos-properties">
       <users-properties path="kerberos-users.properties" relative-to="kerberos" digest-realm-name="ELYTRON.ORG"/>
       <groups-properties path="kerberos-groups.properties" relative-to="kerberos"/>
     </properties-realm>
   </security-realms>
   <credential-security-factories>
     <kerberos-security-factory name="test-server" principal="remote/test-server.elytron.org@ELYTRON.ORG" path="remote-test-server.keytab" relative-to="kerberos"/>
   </credential-security-factories>
   ...
   <sasl>
     ...
     <sasl-authentication-factory name="gssapi-authentication-factory" sasl-server-factory="elytron" security-domain="KerberosDomain">
       <mechanism-configuration>
         <mechanism mechanism-name="GSSAPI" credential-security-factory="test-server"/>
       </mechanism-configuration>
     </sasl-authentication-factory>
     ...
   </sasl>
 </subsystem>

이 섹션에서는 여러 ID 저장소를 사용하는 Elytron Aggregate Security Cryostat Configuration 을 사용하는 Cryostatet Box 또는 레거시 보안 영역 구성을 마이그레이션하는 방법을 설명합니다.

CryostatetBox 또는 레거시 보안 영역을 사용하는 경우, 권한 부여에 사용되는 정보가 다른 저장소에서 로드되는 동안 하나의 ID 저장소에 대해 인증이 수행되는 구성을 정의할 수 있습니다. Elytron으로 마이그레이션할 때 집계 보안 영역을 사용하여 이 작업을 수행할 수 있습니다.

다음 예제에서는 example-users.properties 속성 파일을 사용하여 사용자 인증을 수행한 다음 LDAP를 쿼리하여 그룹 및 역할 정보를 로드합니다.

/subsystem=security/security-domain=application-security:add

/subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[ {code=UsersRoles, flag=Required, module-options={ password-stacking=useFirstPass, usersProperties=file://${jboss.server.config.dir}/example-users.properties}} {code=LdapExtended, flag=Required, module-options={ password-stacking=useFirstPass, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.authentication=simple, bindDN="uid=admin,ou=system", bindCredential=secret, baseCtxDN="ou=users,dc=group-to-principal,dc=wildfly,dc=org", baseFilter="(uid={0})", rolesCtxDN="ou=groups,dc=group-to-principal,dc=wildfly,dc=org",roleFilter="(uniqueMember={1})", roleAttributeID="uid" }}])

<security-domain name="application-security">
  <authentication>
    <login-module code="UsersRoles" flag="required">
      <module-option name="password-stacking" value="useFirstPass"/>
      <module-option name="usersProperties" value="file://${jboss.server.config.dir}/example-users.properties"/>
    </login-module>
    <login-module code="LdapExtended" flag="required">
      <module-option name="password-stacking" value="useFirstPass"/>
      <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
      <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
      <module-option name="java.naming.security.authentication" value="simple"/>
      <module-option name="bindDN" value="uid=admin,ou=system"/>
      <module-option name="bindCredential" value="secret"/>
      <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/>
      <module-option name="baseFilter" value="(uid={0})"/>
      <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
      <module-option name="roleFilter" value="(uniqueMember={1})"/>
      <module-option name="roleAttributeID" value="uid"/>
    </login-module>
  </authentication>
</security-domain>

/core-service=management/ldap-connection=MyLdapConnection:add(url="ldap://localhost:10389", search-dn="uid=admin,ou=system", search-credential="secret")

/core-service=management/security-realm=ApplicationSecurity:add
/core-service=management/security-realm=ApplicationSecurity/authentication=properties:add(path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true)

batch
/core-service=management/security-realm=ApplicationSecurity/authorization=ldap:add(connection=MyLdapConnection)
/core-service=management/security-realm=ApplicationSecurity/authorization=ldap/username-to-dn=username-filter:add(attribute=uid, base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org")
/core-service=management/security-realm=ApplicationSecurity/authorization=ldap/group-search=group-to-principal:add(base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", iterative=true, prefer-original-connection=true, principal-attribute=uniqueMember, search-by=DISTINGUISHED_NAME, group-name=SIMPLE, group-name-attribute=uid)
run-batch

<security-realms>
  ...
  <security-realm name="ApplicationSecurity">
    <authentication>
      <properties path="example-users.properties" relative-to="jboss.server.config.dir" plain-text="true"/>
    </authentication>
    <authorization>
      <ldap connection="MyLdapConnection">
        <username-to-dn>
          <username-filter base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org" attribute="uid"/>
        </username-to-dn>
        <group-search group-name="SIMPLE" iterative="true" group-name-attribute="uid">
          <group-to-principal search-by="DISTINGUISHED_NAME" base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org" prefer-original-connection="true">
            <membership-filter principal-attribute="uniqueMember"/>
          </group-to-principal>
        </group-search>
      </ldap>
    </authorization>
  </security-realm>
</security-realms>
<outbound-connections>
  <ldap name="MyLdapConnection" url="ldap://localhost:10389" search-dn="uid=admin,ou=system" search-credential="secret"/>
</outbound-connections>

/subsystem=elytron/dir-context=ldap-connection:add(url=ldap://localhost:10389, principal="uid=admin,ou=system", credential-reference={clear-text=secret})

/subsystem=elytron/ldap-realm=ldap-realm:add(dir-context=ldap-connection, direct-verification=true, identity-mapping={search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org", rdn-identifier="uid", attribute-mapping=[{filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org",filter="(uniqueMember={1})",from="uid",to="Roles"}]})

/subsystem=elytron/properties-realm=application-properties:add(users-properties={path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true, digest-realm-name="Application Security"})

/subsystem=elytron/aggregate-realm=combined-realm:add(authentication-realm=application-properties, authorization-realm=ldap-realm)

/subsystem=elytron/security-domain=application-security:add(realms=[{realm=combined-realm}], default-realm=combined-realm, permission-mapper=default-permission-mapper)
/subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=BASIC}])

<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="application-security" default-realm="combined-realm" permission-mapper="default-permission-mapper">
      <realm name="combined-realm"/>
    </security-domain>
  </security-domains>
  <security-realms>
    <aggregate-realm name="combined-realm" authentication-realm="application-properties" authorization-realm="ldap-realm"/>
      ...
      <properties-realm name="application-properties">
        <users-properties path="example-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="Application Security" plain-text="true"/>
      </properties-realm>
      <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true">
        <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
          <attribute-mapping>
            <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
          </attribute-mapping>
        </identity-mapping>
      </ldap-realm>
  </security-realms>
  ...
  <http>
    ...
    <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
      <mechanism-configuration>
        <mechanism mechanism-name="BASIC"/>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
  </http>
  ...
  <dir-contexts>
    <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system">
      <credential-reference clear-text="secret"/>
    </dir-context>
  </dir-contexts>
</subsystem>

CryostatetBox를 사용하는 경우 보안 도메인을 정의하고 액세스를 위해 메모리 내 캐싱을 활성화할 수 있었습니다. 이를 통해 메모리의 ID 데이터에 액세스하고 ID 저장소에 대한 추가 직접 액세스를 방지할 수 있었습니다. Elytron을 사용하여 유사한 구성을 수행할 수 있습니다. 이 섹션에서는 Elytron을 사용할 때 CryostatetBox 구성 및 동등한 보안 도메인 캐싱 구성 예를 보여줍니다.

/subsystem=security/security-domain=application-security:add(cache-type=default)
/subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[{code=LdapExtended, flag=Required, module-options={ java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.authentication=simple, bindDN="uid=admin,ou=system", bindCredential=secret, baseCtxDN="ou=users,dc=group-to-principal,dc=wildfly,dc=org", baseFilter="(uid={0})", rolesCtxDN="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", roleFilter="(uniqueMember={1})", roleAttributeID="uid" }}])

<subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    ...
    <security-domain name="application-security" cache-type="default">
      <authentication>
        <login-module code="LdapExtended" flag="required">
          <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
          <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
          <module-option name="java.naming.security.authentication" value="simple"/>
          <module-option name="bindDN" value="uid=admin,ou=system"/>
          <module-option name="bindCredential" value="secret"/>
          <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/>
          <module-option name="baseFilter" value="(uid={0})"/>
          <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
          <module-option name="roleFilter" value="(uniqueMember={1})"/>
          <module-option name="roleAttributeID" value="uid"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="application-security" default-realm="cached-ldap" permission-mapper="default-permission-mapper">
      <realm name="cached-ldap"/>
    </security-domain>
  </security-domains>
  ...
  <security-realms>
    ....
  <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true">
      <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
        <attribute-mapping>
          <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
        </attribute-mapping>
      </identity-mapping>
    </ldap-realm>
    <caching-realm name="cached-ldap" realm="ldap-realm"/>
  </security-realms>
  ...
  <http>
    ...
    <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
      <mechanism-configuration>
        <mechanism mechanism-name="BASIC"/>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
  </http>
   ...
  <dir-contexts>
    <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system">
      <credential-reference clear-text="secret"/>
    </dir-context>
  </dir-contexts>
  ...

기본적으로 JBoss EAP 7.4 및 이전 버전은 레거시 보안 하위 시스템을 사용하여 Jakarta 인증 정책 공급자 및 팩토리를 구성합니다. 기본 구성은 CryostatetBox의 구현에 매핑됩니다.

elytron 하위 시스템은 JACC(Java Authorization Contract for Containers) 사양을 기반으로 기본 제공 정책 공급자를 제공합니다.

elytron 하위 시스템에서 Java Authorization Contract for Containers 정책 공급자를 활성화하고 정의하는 방법에 대한 자세한 내용은 JBoss EAP 7.4 개발 가이드에서 Jakarta 인증 정책 공급자 정의를 참조하십시오.

구성 접근 방식을 사용하여 이름 지정 클라이언트를 Elytron으로 마이그레이션합니다.

이 방법을 사용하면 애플리케이션 코드에서 직접 이름 지정 공급자에 대한 연결을 설정하는 데 사용되는 사용자 자격 증명을 제공합니다.

// Create the authentication configuration
AuthenticationConfiguration namingConfig = AuthenticationConfiguration.empty().useName("bob").usePassword("secret");

// Create the authentication context
AuthenticationContext context = AuthenticationContext.empty().with(MatchRule.ALL.matchHost("127.0.0.1"), namingConfig);

// Create a callable that creates and uses an InitialContext
Callable<Void> callable = () -> {
    Properties properties = new Properties();
    properties.put(Context.INITIAL_CONTEXT_FACTORY,"org.wildfly.naming.client.WildFlyInitialContextFactory");
    properties.put(Context.PROVIDER_URL,"remote+http://127.0.0.1:8080");
    InitialContext context = new InitialContext(properties);
    Bar bar = (Bar) context.lookup("foo/bar");
    ...
    return null;
};

// Use the authentication context to run the callable
context.runCallable(callable);

이 마이그레이션 예제에서는 jboss- Cryostat-client.properties 파일을 사용하여 원격 서버에 배포된 Jakarta Enterprise Cryostat를 호출하도록 클라이언트 애플리케이션이 구성되어 있다고 가정합니다. 클라이언트 애플리케이션 META-INF/ 디렉터리에 있는 이 파일에는 원격 서버에 연결하는 데 필요한 다음 정보가 포함되어 있습니다.

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=127.0.0.1
remote.connection.default.port = 8080
remote.connection.default.username=bob
remote.connection.default.password=secret

클라이언트는 자카르타 Enterprise Cryostat를 조회하고 다음 예제와 유사한 코드를 사용하여 메서드 중 하나를 호출합니다.

// Create an InitialContext
Properties properties = new Properties();
properties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
InitialContext context = new InitialContext(properties);

// Look up the Jakarta Enterprise Beans and invoke one of its methods
RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
    "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
int sum = statelessRemoteCalculator.add(101, 202);

다음 마이그레이션 방법 중 하나를 선택할 수 있습니다.

// Create the authentication configuration
AuthenticationConfiguration ejbConfig = AuthenticationConfiguration.empty().useName("bob").usePassword("secret");

// Create the authentication context
AuthenticationContext context = AuthenticationContext.empty().with(MatchRule.ALL.matchHost("127.0.0.1"), ejbConfig);

// Create a callable that invokes the Jakarta Enterprise Beans
Callable<Void> callable = () -> {

    // Create an InitialContext
    Properties properties = new Properties();
    properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
    properties.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080");
    InitialContext context = new InitialContext(properties);

    // Look up the Jakarta Enterprise Beans and invoke one of its methods
    // Note that this code is the same as before
    RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
        "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
    int sum = statelessRemoteCalculator.add(101, 202);
    ...
    return null;
};

// Use the authentication context to run the callable
context.runCallable(callable);

CLIENT-CERT SSL 인증을 활성화하려면 인증 요소에 truststore 요소를 추가합니다.

<security-realm name="ManagementRealm">
  <server-identities>
    <ssl>
      <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="KEYSTORE_PASSWORD" alias="server" key-password="key_password" />
    </ssl>
  </server-identities>
  <authentication>
    <truststore path="server.truststore" relative-to="jboss.server.config.dir" keystore-password="TRUSTSTORE_PASSWORD" />
    <local default-user="$local"/>
    <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
  </authentication>
</security-realm>

레거시 신뢰 저장소 는 다음 두 가지 방법으로 사용할 수 있습니다.

<subsystem xmlns="urn:wildfly:elytron:4.0"...>
  ...
  <tls>
    <key-stores>
      <key-store name="LocalhostKeyStore">
        <credential-reference clear-text="keystore_password"/>
        <implementation type="JKS"/>
        <file path="server.keystore" relative-to="jboss.server.config.dir"/>
      </key-store>
      <key-store name="TrustStore">
        <credential-reference clear-text="truststore_password"/>
        <implementation type="JKS"/>
        <file path="server.truststore" relative-to="jboss.server.config.dir"/>
      </key-store>
    </key-stores>
    <key-managers>
      <key-manager name="LocalhostKeyManager" key-store="LocalhostKeyStore" alias-filter="server">
        <credential-reference clear-text="key_password"/>
      </key-manager>
    </key-managers>
    <trust-managers>
      <trust-manager name="TrustManager" key-store="TrustStore"/>
    </trust-managers>
    <server-ssl-contexts>
      <server-ssl-context name="LocalhostSslContext" need-client-auth="true" key-manager="LocalhostKeyManager" trust-manager="TrustManager"/>
    </server-ssl-contexts>
  </tls>
</subsystem>

<subsystem xmlns="urn:jboss:domain:undertow:14.0">
...
<https-listener name="https" socket-binding="https" ssl-context="LocalhostSslContext" enable-http2="true"/>
...
</subsystem>

<security-domains>
    <security-domain name="ManagementDomain" default-realm="ManagementRealm" permission-mapper="default-permission-mapper">
        <realm name="ManagementRealm" role-decoder="groups-to-roles"/>
        <realm name="local"/>
    </security-domain>
</security-domains>
<security-realms>
    <properties-realm name="ManagementRealm">
        <users-properties path="mgmt-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="ManagementRealm"/>
        <groups-properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
    </properties-realm>
</security-realms>

/subsystem=elytron/x500-attribute-principal-decoder=x500-decoder:add(attribute-name=CN)

/subsystem=elytron/configurable-http-server-mechanism-factory=configured-cert:add(http-server-mechanism-factory=global, properties={org.wildfly.security.http.skip-certificate-verification=true})

./subsystem=elytron/http-authentication-factory=client-cert-digest:add(http-server-mechanism-factory=configured-cert,security-domain=ManagementDomain,mechanism-configurations=[{mechanism-name=CLIENT_CERT,pre-realm-principal-transformer=x500-decoder},{mechanism-name=DIGEST, mechanism-realm-configurations=[{realm-name=ManagementRealm}]}])

<subsystem xmlns="urn:wildfly:elytron:4.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <http>
    ...
    <http-authentication-factory name="client-cert-digest" http-server-mechanism-factory="configured-cert" security-domain="ManagementDomain">
      <mechanism-configuration>
        <mechanism mechanism-name="CLIENT_CERT" pre-realm-principal-transformer="x500-decoder"/>
        <mechanism mechanism-name="DIGEST">
          <mechanism-realm realm-name="ManagementRealm"/>
        </mechanism>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
    <configurable-http-server-mechanism-factory name="configured-cert" http-server-mechanism-factory="configured-cert">
        <properties>
            <property name="org.wildfly.security.http.skip-certificate-verification" value="true"/>
        </properties>
    </configurable-http-server-mechanism-factory>
    ...
  </http>
  ...
</subsystem>