Liberty:문제점 해결 팁
Liberty의 문제점 해결에 대한 팁입니다.
제품에는 문제를 식별하고 해결하는 데 도움을 주기 위해 통합된 로깅 컴포넌트가 있습니다. 로깅 및 추적을 확인하십시오. 또한 ${wlp.install.dir}/bin 디렉토리에서 IBM® Support Assistant 데이터 콜렉터(ISADC) 명령 도구를 사용하여 요약 파일(예: 로그 파일, 구성 파일)을 신속하게 수집하거나 추적을 실행할 수 있습니다.
예외 메시지를 수신하는 경우, 메시지에 관한 정보는 Liberty:메시지에서 사용 가능합니다.
각 Liberty API에 대한 Java™ API 문서는 ${wlp.install.dir}/dev 디렉토리의 javadoc 서브디렉토리 중 하나에 별도의 .zip 파일로 사용 가능합니다.

Liberty를 사용할 때 적용되는 기본적으로 알려진 제한사항에 대한 세부사항은
Liberty:런타임 환경의 알려진 문제점 및 제한사항의 내용을 참조하십시오.
JDK가 지원되는 레벨에 있는지 확인
쉽게 원인을 알 수 없는 문제를 경험하고 있는 경우에는 사용하고 있는 JDK가 Java 버전 7 이상을 준수하고 있으며 현재 서비스 레벨에 있는지 확인하십시오. 지원되는 최소 Java 레벨을 확인하십시오.
보안 문제점 해결
이 절은 선택할 수 있는 일부 공통 보안 문제 및 솔루션을 설명합니다.
- SESN0008E: 익명으로 인증된 사용자가 user:LdapRegistry/cn=steven,o=myCompany,c=US가 소유하는 세션에 액세스하려고 했습니다.
- 인증된 사용자가 생성한 세션에 인증되지 않은 사용자가 액세스하려고 하는 경우, 이 오류가 발생합니다. 기본적으로 사용 가능한 세션 보안은 세션의 권한 없는 액세스를 금지합니다. 세션을 작성한 사용자만이 액세스할 수 있습니다. 자세한 정보는 세션 보안을 참조하십시오.
JSP(예: login.jsp)를 양식-로그인으로 사용하고 브라우저에서 전송한 SSO 토큰이 만기된 경우 이 오류가 발생할 수 있습니다. SSO 토큰이 만기되기 때문에, 사용자가 양식-로그인으로 구성된 login.jsp 페이지를 사용하여 다시 로그인하도록 프롬프트를 표시합니다. 기본적으로 jsp 페이지가 세션을 가져오려고 합니다. 이 세션은 토큰이 만기된 사용자가 원래 작성했습니다. 토큰이 만기되고 사용자가 인증되지 않기 때문에 이 세션에 액세스할 때 신임 정보가 설정되지 않으며, 이것은 오류가 됩니다.
이 오류를 방지하려면, 새 세션을 시작하는 브라우저를 다시 시작하거나, 기본적으로 세션을 작성하지 않도록 login.jsp 파일을 구성하십시오. login.jsp 파일을 업데이트하도록 선택한 경우, <%@ page session="false" %>를 설정하십시오.
- CWWKS9104A: {2}에서 {1}을(를) 호출하는 동안 사용자 {0}에 대한 권한 부여에 실패했습니다. 사용자에게 어떠한 필수 역할에 대한 액세스 권한도 부여되지 않았습니다. {3}.
- 애플리케이션에서 요구하는 역할에 대한 권한이 사용자에게 없는 경우 이 오류가 발생합니다. 사용자나 사용자가 속한 그룹이 오류 메시지에서 언급된 역할 중 하나 이상에 맵핑되는지 확인하십시오. ibm-application-bnd.xmi/xml 파일에 정의된 사용자 대 역할 맵핑이 server.xml 파일에 정의된 맵핑보다 우선합니다. 올바른 맵핑이 정의되었는지 확인하기 위해 두 자원을 검사하십시오. Liberty에서 애플리케이션에 대한 권한 구성을 확인하십시오.
- CWWKS9104A: {0} 사용자에 대해 권한 부여에 실패했습니다.
- 동일한 컨텍스트 루트에 대해 application과 webApplication을 모두 지정하는 경우 이 오류가 발생할 수 있습니다. 충돌이 발생하면 정의된 최신 구성이 무시되며 예상치 못한 오류가 발생합니다(예: CWWKS9104A).
- CWWKZ0013E: {0}(이)라는 두 개의 애플리케이션이 시작되지 않고 예기치 않은 보안 동작과 CWWKS9104A 같은 오류 메시지가 표시될 수 있습니다.
- dropins 폴더와 application 요소를 사용한 server.xml 모두에서 애플리케이션을 지정할 때 이 오류가 발생합니다.
결과적으로 애플리케이션 설치가 두 번 시도되고
server.xml 파일의 보안 구성이
적용되거나 적용되지 않을 수 있습니다. 이 문제를 해결하려면
dropins 폴더에서 애플리케이션을 제거하고
다른 디렉토리에 복사해야 합니다. dropins 폴더에 애플리케이션을 남겨 두어야 할 경우에는
server.xml 파일의 다음 코드를 사용하여
애플리케이션 모니터링을 사용하지 않도록 설정해야 합니다.
<applicationMonitor dropinsEnabled="false"/>
- 인증되지 않은 사용자가 내 서블릿 또는 JSP에 액세스할 수 있었습니다.
- 인증이 실패하거나 서블릿이나 JSP가 보호되지 않은 경우 UNAUTHENTICATED의 프린시펄을 포함한 사용자(또는
z/OS®에서 인증되지 않은 SAF 사용자)가
작성됩니다. 보안 제한조건을 정의하지 않거나
EVERYONE의 특수 주제를 애플리케이션에서 요구한 역할에 맵핑한 경우, 인증되지 않은 사용자는 사용자의 서블릿이나 JSP에 액세스할 수 있습니다. ibm-application-bnd.xmi/xml 및
server.xml 파일에서 사용자 대 역할 맵핑을 검토하십시오.
다음 옵션 중 하나를 사용하십시오.
- 서블릿이나 JSP가 보호되지 않은 경우, 보안 제한조건을 사용자 애플리케이션의 배치 디스크립터에 추가하십시오. Liberty: 인증을 확인하십시오.
- 인증되지 않은 사용자가 사용자의 애플리케이션에 액세스하지 않게 하려면, 해당 역할에 대한 맵핑에서 EVERYONE 특수 주제를 제거하십시오. Liberty에서 애플리케이션에 대한 권한 구성을 확인하십시오.
- 특정 사용자에게 사용자의 서블릿 또는 JSP에 대한 권한을 부여할 수 없는 경우, ibm-application-bnd.xmi/xml 및 server.xml 파일을 조사하여 해당 역할로 맵핑된 사용자를 검토하십시오. 역할을 사용자, 그룹 또는 특수 주제에 맵핑할 수 있습니다. 사용자의 역할이 EVERYONE 특수 주제에 맵핑된 경우 모든 사용자가 액세스하도록 허용됩니다. 사용자의 역할이 ALL_AUTHENTICATED 특수 주제로 맵핑된 경우, 인증된 사용자가 액세스하도록 허용됩니다. 서블릿이나 JSP에 액세스할 수 있는 사용자를 추가로 제한하려는 경우 이 특수 주제를 제거하십시오. 마지막으로, 사용자가 속한 그룹을 확인하십시오. 사용자가 명시 액세스 권한을 가질 수 없더라도 그룹은 해당 역할에 맵핑될 수 있습니다. 이 경우, 권한 부여된 그룹에서 사용자를 제거하거나 역할 맵핑에서 그룹을 제거하십시오. Liberty에서 애플리케이션에 대한 권한 구성을 확인하십시오.
- 싱글 사인온(SSO)이 작동하지 않습니다.
- SSO가 작동하지 않는 경우에는 동일한 LTPA 키, 비밀번호 및 webAppSecurity 요소의 ssoCookieName 속성을 사용하는 서로 다른 Liberty 서버가 동일한 UTC(Universal Time)를 보유하며 동일한 사용자 레지스트리를 공유하는지 확인하십시오. 또한 영역을 수정하거나 쿠키가 나타내는 사용자를 제거하는 등의 일관되지 않은 방식으로 사용자 레지스트리를 변경한 후 웹 브라우저로부터 쿠키가 전송되거나 토큰이 만료되는 경우에는 SSO가 실패하며 신임 정보를 다시 입력하라는 프롬프트가 사용자에게 표시됩니다. Liberty에서 LTPA 쿠키를 사용하여 SSO 구성 사용자 정의을 확인하십시오.
- 보안 공용 API 디버깅.
- 보안이 사용하도록 설정되지 않은 경우(예: 보안 기능 appSecurity-1.0, appSecurity-2.0 또는 zosSecurity-1.0이 지정되지 않은 경우)에도 WSSecurityHelper 및 RegistryHelper가 로드됩니다. 보안이 사용 불가능한 경우, WSSecurityHelper.isServerSecurityEnabled() 및 WSSecurityHelper.isGlobalSecurityEnabled() 메소드 모두가 false를 리턴하며 RegistryHelper.getUserRegistry() 메소드는 널을 리턴합니다.
보안이 사용 불가능한 경우 기타 보안 공용 API 클래스를 로드하지 못할 수 있습니다. 이 클래스에 액세스하려고 하는 경우 클래스 중 하나에서 메소드를 호출하려고 하면 java.lang.NoClassDefFoundError 예외가 발생할 수 있습니다.
java.lang.NoClassDefFoundError 예외가 발생하지 않도록, WSSecurityHelper.isServerSecurityEnabled() 또는 WSSecurityHelper.isGlobalSecurityEnabled() 클래스를 호출하여 보안이 사용 가능한지 여부를 확인하기 위해 먼저 테스트한 다음, 보안이 사용 가능한 경우에만 기타 보안 공용 API 클래스를 호출하십시오. 이 코딩 기술의 예제는 Liberty:보안 공용 API의 내용을 참조하십시오.
- 참고: 이 동작은 WebSphere Application Server Traditional과 다릅니다. WebSphere Application Server Traditional에서, 모든 클래스는 보안이 사용 가능한지 여부와 상관없이 항상 로드됩니다.
- 유니코드 문자를 가진 사용자를 인증할 수 없음
- 이름에 유니코드 문자가 포함된 사용자를 인증하려면 다음의 jvm 옵션을
서버 시작 명령에 추가하여 Liberty 서버에서 사용하는 문자 인코딩 유형을
UTF-8로 설정해야 합니다.
-Dclient.encoding.override=UTF-8
또한 로그인 페이지에서 charset 및 pageEncoding을 지정해야 합니다. 로그인 JSP 페이지에서 이 매개변수를 지정하는 예제는 다음과 같습니다.<%@page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
- java.lang.annotation.AnnotationFormatError: java.lang.IllegalArgumentException: sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:87)에 있는 상수 풀 인덱스의 유형이 잘못됨
- 이 오류는 OpenID Connect 또는 OAuth 제공자가 일부 JDK 7 버전에 대한 클라이언트 등록에 데이터베이스 저장소를 사용할 때 발생할 수 있습니다.
이 문제점을 방지하려면 JDK 버전 7.1로 업그레이드하십시오.
LDAP 문제점 해결
이 절은 일부 공통 LDAP 문제점과 선택할 수 있는 솔루션을 설명합니다.
- FFDC1015I: An FFDC Incident has been created: javax.naming.ServiceUnavailableException: myldapserver.mycompany.com:636; socket closed com.ibm.ws.security.registry.ldap.internal.LdapRegistry 298
- messages.log의 이 메시지는 구성된 LDAP 서버에 도달할 수 없다는 것을 표시합니다. LDAP 서버를 검사하여 실행 중이며 IP 주소를 Liberty 서버에서 액세스할 수 있는지 확인하십시오.
- The javax.naming.CommunicationException: simple bind failed: myldapserver.mycompany.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.g: PKIX path building failed: java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target]
- LDAP 서버의 서명자를 LDAPSSLSettings 요소에서 참조된 신뢰 저장소로 복사하지 않고 LDAP 서버에서 SSL을 사용 가능하게 설정한 경우, LDAP 서버와의 연결이 SSL 핸드쉐이크 오류로 실패합니다. LDAP 서버의 서명자를 신뢰 저장소로 복사하는지 확인하십시오.
- The javax.naming.CommunicationException: myldapserver.mycompany.com:389 [Root exception is java.net.BindException: Address already in use: connect]
- 이 메시지는 FFDC 로그에 표시될 수 있으며 로컬 서버에서 사용 가능한 소켓이 소모되어 LDAP 서버에 연결할 때 실패함을 표시합니다. 소켓이 사용되지 않는지 확인하고 다시 시도하십시오.
- CWWKS1100A: 사용자 ID xxxxx에 대한 인증이 성공하지 못했습니다. 지정된 사용자 ID나 비밀번호가 올바르지 않습니다.
- 로드 부하가 많은 경우 메시지에 나와 있는 사용자가 LDAP 서버의 유효한 사용자라도 이 FFDC 예외가 발생할 수 있습니다. LDAP 구성을 통해 reuseConnection=false 특성을 추가하거나 개발자 도구를 사용하여 해당 특성을 사용하지 않도록 설정할 수 있습니다. 문제점을 해결하려면 이 특성을 기본값인 true로 설정하십시오.
SSL 문제점 해결
이 절은 일부 공통 SSL 문제점과 선택할 수 있는 솔루션을 설명합니다.
- CWWKS9105E: 자동 경로 재지정을 위한 SSL 포트를 판별할 수 없습니다.
- SSL 포트로 경로 재지정하고 SSL 포트가 사용 가능하지 않은 애플리케이션에 사용자가 액세스하려고 하는 경우 이 오류가 발생합니다. 누락된 SSL 구성 또는 SSL 구성 정의의 일부 오류 때문에 포트를 사용할 수 없습니다. server.xml 파일에서 SSL 구성이 존재하고 올바른지 확인하십시오. Liberty와의 통신 보안을 확인하십시오.
- FFDC1015I: An FFDC Incident has been created: "java.lang.IllegalArgumentException: Unknown, incomplete configuration: missing id field com.ibm.ws.config.internal.cm.ManagedServiceFactoryTracker aSyncReadNupdate. Exception thrown while trying to read configuration and update ManagedServiceFactory. Exception = java.lang.IllegalArgumentException: Unknown, incomplete configuration: missing id field" at ffdc_12.04.18_16.09.42.0.log
- ID 필드가 없는 구성에 keystore 요소가 있는 경우 이 오류가 발생합니다. 최소 SSL 구성을 사용하는 경우 ID 필드를 defaultKeyStore로 설정하십시오.
- sslEnabled 및 sslRef 값이 있는 LDAP 사용자 레지스트리가 지정되지 않은 경우 예외가 발생할 수 있습니다.
- 예를 들어, 다음 예제에서 보는 것처럼 구성에서
sslEnabled가 true로 설정되었지만 sslRef
값이 없습니다.
<ltldapRegistry id="ldap" realm="SampleLdapIDSRealm" host="ccwin12.austin.ibm.com" port="636" ignoreCase="true" baseDN="o=ibm,c=us" bindDN="cn=root" bindPassword="rootpwd" ldapType="IBM Tivoli Directory Server" idsFilters="ibm_dir_server" sslEnabled="true" searchTimeout="8m" />
sslRef 값을 입력해야 합니다. 최소 SSL 구성을 사용 중인 경우, 다음과 같습니다.
sslRef 필드는 defaultSSLConfig로 설정되어야 합니다.<ltkeyStore id="defaultKeyStore" location="key.jks" password="mypassword" />
사용자 정의 SSL 구성을 구성한 경우 해당 구성의 이름을 sslRef 필드에 배치해야 합니다.
- WebSphere Application Server의 JDK를 사용하는 경우, SSL이 Liberty Server에서 사용 가능한 경우 다음 오류가 표시될 수 있습니다.
java.net.SocketException: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory at javax.net.ssl.DefaultSSLSocketFactory.a(SSLSocketFactory.java:11) at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:6) at com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:161) at com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:36) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1184) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:390) at com.ibm.net.ssl.www2.protocol.https.b.getResponseCode(b.java:75) at com.ibm.ws.jmx.connector.client.rest.internal.RESTMBeanServerConnection.loadJMXServerInfo(RESTMBeanServerConnection.java:142) at com.ibm.ws.jmx.connector.client.rest.internal.RESTMBeanServerConnection.<init>(RESTMBeanServerConnection.java:114) at com.ibm.ws.jmx.connector.client.rest.internal.Connector.connect(Connector.java:315) at com.ibm.ws.jmx.connector.client.rest.internal.Connector.connect(Connector.java:103)
이 오류는 WebSphere Application Server SSL 소켓 팩토리가 Liberty에 의해 지원되지 않기 때문에 발생합니다. 다음과 같은 단계를 수행하여 이 문제점을 통과할 수 있습니다.- 다음과 같은 두 개의 비어 있는 항목을 포함한 텍스트 파일(예: my.java.security)을 작성하십시오.
ssl.SocketFactory.provider= ssl.ServerSocketFactory.provider=
- Liberty 서버에 대해 jvm.options 파일을 작성하십시오.
- 방금 작성한 텍스트 파일의 전체 경로를 포함하는 다음 특성을 jvm.options 파일에 추가하십시오.
-Djava.security.properties=fullPathTo/my.java.security
- 이 파일을 더욱 재사용 가능하게 하려면 my.java.security 파일을 서버 디렉토리에 둘 수 있습니다. 그러면 다음과 같은 상대 경로를
사용할 수 있게 됩니다.
-Djava.security.properties=./my.java.security
자세한 정보는 Liberty 환경 사용자 정의의 내용을 참조하십시오.
- 다음과 같은 두 개의 비어 있는 항목을 포함한 텍스트 파일(예: my.java.security)을 작성하십시오.
CORBA/IIOP 문제점 해결
이 절에는 몇 가지 일반적인 CORBA 문제점과 이에 대해 선택할 수 있는 해결책이 설명되어 있습니다.
- WebSphere Application Server의 JDK를 사용하는 경우에는 애플리케이션이 CORBA/IIOP 통신을 사용할 때 다음 오류가 표시될 수 있습니다.
15:21:58.096 com.ibm.rmi.pi.InterceptorManager runPreInit:178 Init Process ORBRas [default] java.lang.ClassNotFoundException: com.ibm.ISecurityLocalObjectBaseL13Impl.CSIClientRI at com.ibm.CORBA.iiop.UtilDelegateImpl.loadClass(UtilDelegateImpl.java:685) at javax.rmi.CORBA.Util.loadClass(Util.java:246) at com.ibm.rmi.pi.InterceptorManager.runPreInit(InterceptorManager.java:172) at com.ibm.rmi.corba.ORB.initializeInterceptors(ORB.java:664) at com.ibm.CORBA.iiop.ORB.initializeInterceptors(ORB.java:1084) at com.ibm.rmi.corba.ORB.orbParameters(ORB.java:1359) at com.ibm.rmi.corba.ORB.set_parameters(ORB.java:1271) at com.ibm.CORBA.iiop.ORB.set_parameters(ORB.java:1694) at org.omg.CORBA.ORB.init(ORB.java:371) ...
이 오류는 WebSphere Application Server ORB(Object Request Broker) 인터셉터를 Liberty에서 지원하지 않기 때문에 발생합니다. 이 문제점은 JDK에서 이러한 인터셉터를 사용하지 않도록 orb.properties 파일을 편집하여 해결할 수 있습니다. 이 파일은 사용자의 <USER_HOME> 디렉토리에서 사본으로 대체되었을 수 있지만 대개 WebSphere <JAVA_HOME>/jre/lib 디렉토리에 있습니다. 다음 예제에는 주석 처리해야 하는 orb.properties 파일의 행이 표시되어 있습니다.
# WS Interceptors #org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.Transaction.JTS.TxInterceptorInitializer #org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ejs.ras.RasContextSupport #org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ISecurityLocalObjectBaseL13Impl.ClientRIWrapper #org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.activity.remote.cos.ActivityServiceClientInterceptor #org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ISecurityLocalObjectBaseL13Impl.CSIClientRI #org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.debug.olt.ivbtrjrt.OLT_RI #org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.wlm.client.WLMClientInitializer # WS ORB & Plugins properties #com.ibm.ws.orb.transport.ConnectionInterceptorName=com.ibm.ISecurityLocalObjectBaseL13Impl.SecurityConnectionInterceptor
로깅 및 추적 문제점 해결
이 절에서는 로깅 및 추적에 대한 몇몇 공통 문제점에 대해 설명합니다.
- java.util.logging -- Java 로깅 프로그래밍 인터페이스.
- Liberty는 logging.properties 파일을 사용한 java.util.logging의 구성을 지원하지 않습니다. 예를 들어, 배치된 애플리케이션 또는 사용자 기능에서 java 코드를 사용하여 java.util.logging 핸들러, 필터 또는 포맷터를 작성하고 추가하십시오.
- Liberty 서버가 로깅 구성 요소의 traceSpecification 속성에 따라 java.util.logging 로거 레벨을 관리하므로, Logger.setLevel 메소드 사용을 피하십시오.
JAX-WS 문제점 해결
이 절은 일부 공통 JAX-WS 문제점과 선택할 수 있는 솔루션을 설명합니다.
- Liberty에서 웹 서비스 애플리케이션을 배치할 때 org.apache.cxf.bus.extension.ExtensionException이 발생했습니다.
- 애플리케이션에 CXF 라이브러리 및 구성이 이미 임베디드되어 있으며 애플리케이션을 Liberty에 배치하고자 하는 경우, server.xml 파일에서 해당 기능을 제거함으로써 jaxws-2.2 서버 기능이 사용되지 않는지 확인해야 합니다.
- Oracle JVM이 있는 IBM 빠른 경로를 실행할 때 java.lang.NoClassDefFoundError 예외가 발생했습니다.
- IBM 빠른 경로 JAXB(Java Architecture for XML Binding)을 사용하기 위해,
com.ibm.xml.xlxp.jaxb.opti.level 사용자 정의 특성이 JAXB 언마샬링(직렬화 해제) 및 마샬링(직렬화)에 대해
최적화 메소드를 사용할 수 있는지 여부를 제어하도록 구성할 수 있습니다. Oracle JVM으로 IBM 빠른 경로 JAXB를
실행할 때 java.lang.NoClassDefFoundError 예외가 발생하는 경우,
com.ibm.xml.xlxp.jaxb.opti.level 특성의 값을 0으로 변경하여
최적화를 끌 수 있습니다. 예를 들어,
명령행에서 -Dcom.ibm.xml.xlxp.jaxb.opti.level=0 특성을 사용하거나
jvm.options 파일에 다음 행을 추가할 수 있습니다.
# Turn off the JAXB optimization -Dcom.ibm.xml.xlxp.jaxb.opti.level=0
- Java Virtual Machine(JVM) 사용자 정의 특성 페이지에서 com.ibm.xml.xlxp.jaxb.opti.level 특성의 자세한 정보를 참조하십시오.
- Oracle JVM과 함께 WebSphere Application Server Traditional 씬 클라이언트를 실행할 때 java.lang.NoClassDefFoundError : com.ibm.CORBA.iiop.ORB 예외가 발생했습니다.
- 이 오류는 Oracle JVM에서 WebSphere Application Server Traditional 씬 클라이언트를 실행하려고
시도하고 jaxws-2.2 기능이 이미 Liberty에서 사용될 때 발생합니다. 이 문제점을
해결하기 위해 다음과 같이 WebSphere Application Server Traditional 씬 클라이언트를 실행할 때
-Dcom.ibm.websphere.thinclient=true 특성을 사용할 수
있습니다.
java -Dcom.ibm.websphere.thinclient=true -cp <classpath_entries_including_tWAS_thinclient_jar> <WebServicesClientEntryClass> <any_more_parameters>
- PM39777: ADMINISTRATIVE THIN CLIENT USING SOAP CONNECTOR AND SUN JDK DOES NOT WORK 페이지에서 com.ibm.websphere.thinclient 특성의 유사 정보를 참조하십시오.
- MTOM 서비스에서 MTOM 클라이언트로 2진 파일을 검색할 때 빈 파일이 리턴되었습니다.
- MTOM 클라이언트가 성공적으로 2진 파일을 MTOM 서비스에 보냈지만 MTOM 서비스에서 다시 동일한 2진 파일을 검색할 때 빈 파일이 리턴되는 경우에 이 시나리오가 발생합니다.
- 임시 해결책으로, 새 DataHandler를 작성하고
2진 파일의 컨텐츠를 채워서 DataHandler를 초기화할 수 있습니다. 예를 들어,
FileDataStore 오브젝트를 사용하여 I/O에서 읽고 새로 작성된 DataHandler를
다시 리턴한 후 다른 웹 서비스에 DataHandler를 전달하십시오.
... File f = new File("received_image"); if (f.exists()) { f.delete(); } FileOutputStream fos = new FileOutputStream(f); img_in.writeTo(fos); FileDataSource fos_out = new FileDataSource(f); DataHandler img_out = new DataHandler(fos_out); return img_out; ...
- javax.xml.ws.soap.SOAPFaultException: Oracle JVM과 함께 xsd:gMonth 형식으로 XMLGregorianCalendar를 사용할 때 언마샬링(Unmarshalling) 오류가 발생했습니다.
- 이 오류는 클라이언트측에서 SOAP 요청의 일부로서 gMonth 형식 상수를 저장하기 위해 XMLGregorianCalendar 클래스를 사용하며 jaxws-2.2 기능이 Oracle JVM과 함께 Liberty에서 사용되는 경우에 발생합니다. 근본 원인은 최신 JAXB RI(Reference Implementation)만 --MM--의 형식을 지원하지만 Oracle JVM이 xsd:gMonth 유형에 새 표준 형식 --MM을 지원하기 때문입니다.
- 이 문제점을 해결하려면 클라이언트 측 및 서버 측 애플리케이션 모두에 대해 Oracle JVM을 IBM JVM으로 변경하면 됩니다.
- wsdlLocation 속성에 의해 지정된 WSDL 파일을 분석할 때 java.io.FileNotFoundException이 발생했습니다.
- 이 오류는 wsdlLocation = "file:/WEB-INF/wsdl/a.wsdl" 코드에서와 같이 WSDL 파일을 지정하고 WSDL 파일이 애플리케이션 내에 패키징될 때 발생합니다. 애플리케이션에서 패키징된 WSDL 파일을 참조하려는 경우 @WebService, @WebServiceProvider, @WebServiceClient 또는 @WebServieRef 어노테이션에 정의된 wsdlLocation 속성의 상대적 URI를 사용해야 합니다.
- wsdlLocation 속성의 상대적 URI는
다음 값 중 하나여야 합니다.
- wsdlLocation = "/WEB-INF/wsdl/a.wsdl"
- wsdlLocation = "WEB-INF/wsdl/a.wsdl"
- messages.log 파일에 다수의 "서비스 작성" 메시지가 있습니다.
- 이 시나리오는 생성된 클라이언트 스텁 클래스에서 getPort
또는 관련 메소드를 호출할 때 발생합니다. Liberty는 기본 로깅 구성으로 구성되며, 모든 정보 메시지는
messages.log 파일에 기록됩니다. 다음과 비슷한 메시지가 여러 개
있습니다.
00000037 org.apache.cxf.service.factory.ReflectionServiceFactoryBean I Creating Service {http://www.echo.org/}EchoService from WSDL: wsjar:file:/wlp/usr/servers/default/workarea/org.eclipse.osgi/bundles/100/data/cache/ com.ibm.ws.app.manager_gen_15a42559-f979-4ee6-b488-9fa1fb212c96/.cache/Echo.war!/WEB-INF/wsdl/Echo.wsdl
- 이러한 정보 메시지가 표시되지 않도록 하려면
server.xml 파일에서 다음과 같이 로깅 구성을 변경할
수 있습니다.
<logging traceSpecification="org.apache.cxf.*=warning=enabled"/>
- SOAPFaultException: 제공된 SOAPAction test가 클라이언트 애플리케이션이 SOAP 조치를 전송할 때 발생한 조작과 일치하지 않습니다.
- 참고: test는 요청 HTTP 헤더에서 soapAction 속성의 값입니다.SOAP 웹 서비스의 각 조작은 WSDL 바인딩이나 어노테이션을 통해 SOAP 조치 문자열과 연관될 수 있습니다. 웹 서비스 클라이언트는 SOAP 조치 문자열을 요청이 포함된 헤더로 전송하여 웹 서비스 제공자의 조작과 일치시킵니다. 다음 두 시나리오 중 하나에서 오류 메시지가 표시됩니다.
- 클라이언트가 전송하는 SOAP 조치가 조작의 SOAP 조치와 일치하지 않는 경우
- WebSphere Application Server Traditional을 JAX-WS 클라이언트로서 사용하며 Liberty를 JAX-WS 서비스로 사용하고 WSDL 파일에 정의된 soapAction이 비어 있는 값 ""과 동일한 경우.
- 이 문제를 해결하려면 다음을 수행하십시오.
- 웹 서비스 클라이언트와 서비스 제공자 모두에 대해 동일한 SOAP 조치를 지정하는지 확인하십시오.
- WSDL 파일에서 정의되는 soapAction 속성에 올바른 값을 제공하거나 WSDL 파일에서 soapAction을 사용하지 마십시오.
- Service.create() 메소드를 사용하여 서비스를 작성할 때 javax.xml.ws.WebServiceException이 발생합니다.
- WSDL 문서가 제공되지 않는 동안 Service.create() 메소드를 사용하여 서비스를 작성하면 이 오류가 발생합니다. Service.create()를 사용하여 포트 번호를 가져올 서비스 및 getPort() 메소드를 작성하려면, addPort() 메소드를 사용하여 바인딩 정보를 제공해야 합니다.
- addPort() 메소드를 사용하는 방법에 대해 다음과 같은 샘플 예제 코드가 제공됩니다.
QName serviceName = new QName("http://test.com/wssvt/acme/InsBusiness/", "MTOM11Service"); QName portName = new QName("http://test.com/wssvt/acme/InsBusiness/", "MTOM11Port"); // Setup the necessary JAX-WS artifacts Service svc = Service.create(serviceName); // Add the port in the service instance svc.addPort(portName, SOAPBinding.SOAP11HTTP_MTOM_BINDING, mtom11URL); port = svc.getPort(portName, MTOMInterface.class);
- @WebResult 어노테이션의 name 속성이 WSDL 문서의 name 속성과 다른 경우 Null 응답이 리턴됩니다.
- SEI 클래스를 사용하여 @WebResult 어노테이션의
name 속성을 정의하고 SEI가 다음과 같이
WSDL 위치를 제공한 경우 이 문제점이 발생합니다.
그러나 제공된 WSDL 문서의 XML 요소 선언은 다음과 같습니다.@WebService(wsdlLocation="WEB-INF/wsdl/WebServiceIfc.wsdl") public interface WebServiceRuntimeIfc { @WebMethod @WebResult(name="nononoreturn") public String echo (String parm); }
그러면 echo() 메소드를 호출할 때 웹 서비스 클라이언트가 NULL 응답을 받습니다.<xs:element name="echoResponse"> <xs:complexType> <xs:sequence> <xs:element name="return" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element>
- 이 문제점을 해결하려면, @WebResult 어노테이션의 name 속성이 WSDL 문서의 name 요소 값과 일치하는지 확인하십시오.
- JAX-WS 클라이언트 애플리케이션이 서버측에서 WSDL 문서 변경사항을 가져오는 데 실패했습니다.
- 이 문제점은 웹 서비스 클라이언트와 서비스 제공자가 Liberty의 서로 다른 두 애플리케이션에 있으며 클라이언트가 서비스 제공자의 WSDL 문서를 동적으로 검색해야 하는 경우에 발생합니다. Liberty가 WSDL 정의를 캐싱하기 때문에 WSDL 문서가 처음 액세스되며, 이것은 WebSphere Application Server Traditional 의 작동과는 다릅니다. Liberty의 WSDL 정의를 캐싱함으로써, 애플리케이션은 자주 WSDL 문서에 연결하여 구문을 분석하지 않아도 됩니다.
- 이 문제점을 해결하려면, 업데이트된 WSDL 정의를 다시 로드할 수 있도록 클라이언트 애플리케이션을 다시 시작해야 합니다.
- WSDL 가져오기 중의 JAXB 경고
- WSDL 파일을 가져오는 중에 다음 경고 메시지가 표시될 수
있습니다.
[WARNING] unknown extensibility element or attribute "wsdl" (in namespace "http://www.w3.org/2000/xmlns/" (http://www.w3.org/2000/xmlns/%27) )
WS-Security 문제점 해결
- 필요한 JAX-WS(jaxws-2.2)와 보안(appSecurity-2.0) 기능이 올바르게 구성되어 있는지 확인하기 위해 server.xml 파일을 검사하십시오.
- WS-Security로 웹 서비스 애플리케이션을 보호하려면 JAX-WS 애플리케이션에 임베디드 WS-Security 정책이 있는 WSDL 파일이 있어야 합니다. wsdl:binding 또는 wsdl:operation 섹션이나 두 섹션 모두에서 임베디드 WS-Security 정책에 대한 PolicyReference가 있어야 합니다.
- UsernameTokens를 생성하기 위한 비밀번호를 검색하거나 키 저장소 파일의 개인 키에 대한 비밀번호를 검색하기 위해 콜백 핸들러를 사용하는 경우에는 비밀번호 콜백 핸들러를 Liberty의 사용자 기능으로 패키징하고 배치해야 합니다.
WS-Security 추적 사용
오류 메시지의 정보를 사용하여 문제점의 원인을 판별할 수 없는 경우에는 Liberty 추적 및 로깅 기능을 사용하여 WS-Security 컴포넌트에 대한 추적을 수집할 수 있습니다. Liberty: 추적 및 로깅을 참조하십시오.
org.apache.ws.security.*=all=enabled:
org.apache.cxf.ws.security.*=all=enabled:
org.apache.cxf.ws.policy.*=all=enabled
org.apache.xml.security.*=all=enabled:
com.ibm.ws.wssecurity.*=all=enabled
이 절에서는 일부 공통 WS-Security 문제점과 사용자가 선택할 수 있는 솔루션을 설명합니다.
- org.apache.cxf.ws.policy.PolicyException: 충족할 수 있는 정책 대체사항이 없습니다.
- 이 오류는 보통 WS-Security 기능 wsSecurity-1.1가 server.xml 파일에
정의되지 않은 경우에 발생합니다. 이 오류를 방지하려면, 다음과 같이 server.xml 파일에서
wsSecurity-1.1 기능을 정의해야 합니다.
<featureManager> <feature>usr:wsseccbh-1.0</feature> <feature>servlet-3.0</feature> <feature>appSecurity-2.0</feature> <feature>jaxws-2.2</feature> <feature>wsSecurity-1.1</feature> </featureManager>
- org.apache.cxf.ws.policy.PolicyException: 사용 가능한 콜백 핸들러와 비밀번호가 없습니다.
- 이 오류는 WS-Security 런타임이 UsernameToken을 생성하거나
키 저장소의 개인 키에 액세스하기 위해 필요한 비밀번호를 검색할 수 없을 때 발생합니다. 이 오류를 방지하려면
다음 구성을 확인하십시오.
- 비밀번호 콜백 핸들러 기능 wsseccbh-1.0이 server.xml 파일에서
사용자 기능으로 정의되어 있는지 확인하십시오.
<featureManager> <feature>usr:wsseccbh-1.0</feature> <feature>servlet-3.0</feature> <feature>appSecurity-2.0</feature> <feature>jaxws-2.2</feature> <feature>wsSecurity-1.1</feature> </featureManager>
- 콜백 핸들러 특성 ws-security.callback-handler가 server.xml 파일의
<wsSecurityClient> 또는 <wsSecurityProvider> 요소에 정의되어 있는지
확인하십시오.
ws-security.callback-handler="<full class name of the callback handler>" example: ws-security.callback-handler="com.ibm.ws.wssecurity.example.cbh.CommonPasswordCallback"
- 비밀번호 콜백 핸들러가 server.xml 파일에 지정된 키 별명이나 사용자 이름에 대한 올바른 비밀번호를 리턴하는지 확인하십시오. 비밀번호는 일반 텍스트여야 하고 인코드되거나 암호화되지 않아야 합니다.
- 비밀번호 콜백 핸들러 기능 wsseccbh-1.0이 server.xml 파일에서
사용자 기능으로 정의되어 있는지 확인하십시오.
- org.apache.ws.security.WSSecurityException: 서명은 필수 요소(soap:Body)를 대신하지 않습니다.
- 이 오류는 웹 서비스 제공자 애플리케이션이 요청 메시지에서 SOAP 본문을 예상하지만 수신된 SOAP 메시지에 서명된 SOAP 본문이 없는 경우에 발생합니다. 이 오류를 방지하려면 웹 서비스 클라이언트가 웹 서비스 제공자 정책과 일치하는 올바른 WS-Security 정책으로 구성되어 있는지 확인하십시오.
- org.apache.ws.security.WSSecurityException: 서명 또는 복호화가 올바르지 않습니다.
- 이 오류는 WS-Security 런타임에서 서명의 유효성을 검증하거나 수신된 SOAP 메시지에서 암호화된 메시지 파트를 복호화하는 데 실패하는 경우에 발생합니다. 이 오류를 방지하려면 server.xml 파일의 <wsSecurityClient> 및 <wsSecurityProvider> 요소에서 WS-Security를 구성할 때 올바른 키가 사용되는지 확인하십시오. 웹 서비스 클라이언트가 Bob의 공개 키를 사용하여 메시지 파트를 암호화하는 경우, 웹 서비스 제공자는 메시지를 복호화하기 위해 Bob의 개인 키에 액세스해야 합니다. 이와 유사하게, 웹 서비스 클라이언트가 Alice의 개인 키를 사용하여 메시지 파트에 서명하는 경우 웹 서비스 제공자는 Alice의 공개 키를 사용하여 서명의 유효성을 검증해야 합니다.
- org.apache.cxf.ws.policy.PolicyException: 이 정책 대체사항에 충족할 수 없습니다.
- 이 오류는 WS-Security 런타임에서 해당 요청을 처리하도록 구성된
WS-Security 정책을 사용하여 수신 SOAP 메시지를 처리할 수 없는 경우에
발생합니다. 이 오류를 방지하려면
이 예외 뒤에 오는 메시지를 보고 이 예외를 야기하는
특정 웹 WS-Security 정책 어설션을 판별하십시오. 예를 들어, 로그 파일에는 다음 메시지가
포함될 수 있습니다.
이 경우에, 웹 서비스 클라이언트에서 사용되는 암호화 알고리즘이 AlgorithmSuite 어설션에 지정된 암호화 알고리즘과 일치하지 않기 때문에 오류가 발생했습니다. 웹 서비스 클라이언트와 웹 서비스 제공자 둘 다의 WS-Security 정책에 지정된 알고리즘 스위트는 동일한 암호화 알고리즘을 지정해야 합니다.Caused by: org.apache.cxf.ws.policy.PolicyException: These policy alternatives can not be satisfied: {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}AsymmetricBinding: The encryption algorithm does not match the requirement {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}InitiatorEncryptionToken {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}RecipientEncryptionToken at org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:167) at org.apache.cxf.ws.policy.PolicyVerificationInInterceptor.handle(PolicyVerificationInInterceptor.java:101)
- javax.xml.ws.soap.SOAPFaultException: 메시지가 만기되었습니다. (WSSecurityEngine: 메시지의 보안 시맨틱이 만기된 시간소인이 올바르지 않습니다.)
- 메시지 시간소인이 만기되거나 메시지가 미래의 시간소인으로 작성된 경우에 이 메시지가 발생합니다.


아카이브 설치에 수정팩 및 임시 수정사항 적용
Installation Manager를 사용하지 않고 아카이브 파일에서 Liberty 런타임 환경을 설치한 경우에는 서비스 업데이트를 적용할 때 특수 조치를 취해야 합니다. 자세한 정보는 Liberty Java 아카이브 설치에 수정팩 적용 및 Liberty 아카이브 설치에 임시 수정사항 적용의 내용을 참조하십시오.
성능 문제점 해결
이 절에서는 몇몇 공통 성능 문제점 및 사용자가 선택할 수 있는 솔루션에 대해 설명합니다.
- 애플리케이션 모니터의 높은 CPU 사용량
이 오류는 애플리케이션 모니터가 apps/ 디렉토리 아래에 다수의 파일을 가지고 있을 때 너무 자주 폴링을 수행하는 경우 발생할 수 있습니다.
이 문제를 방지하기 위해 많은 항목을 변경할 수 있습니다.
- applicationMonitor 요소에서 pollingRate 속성의 값을 늘리십시오.
- server.xml을 업데이트하여 polled가 아닌
updateTrigger를 가진 applicationMonitor 요소를
포함하십시오.
server.xml <applicationMonitor updateTrigger="mbean" />
- apps/ 디렉토리 아래의 파일 수를 줄이십시오.
applicationMonitor 요소에 대한 자세한 정보는 동적 업데이트 제어의 내용을 참조하십시오.
집합체 문제점 해결
이 절은 집합체의 문제점 및 적용해야 하는 솔루션을 설명합니다.
- java.lang.IllegalArgumentException: CWWKX0219E: MBean 'WebSphere:feature=collectiveController,type=CollectiveRepository,name=CollectiveRepository'가 이름 'retrieveMemberRootCertificate'에 의한 조작을 갖지 않습니다.
- 기능 collectiveMember-1.0, 멤버를 갖는 서버는 Liberty의
더 낮은 레벨에 있는 기능 collectiveController-1.0, 제어기를 갖는 서버에 등록할 수 없습니다. 예를 들어,
Liberty의 이 베타 레벨에 있는 멤버는 V8.5.5.2 Liberty에 있는 제어기에 자신을 등록할 수 없습니다.
기본 로깅을 사용할 때 이 문제점은 멤버의 FFDC 로그에서 첫 번째 실패 데이터 캡처(FFDC)로서 보고됩니다.
이 문제점을 수정하려면 제어기를 멤버와 동일하거나 높은 Liberty 레벨로 이동해야 합니다.
SAML 문제점 해결
이 절은 SAML 문제점 및 적용해야 하는 솔루션을 설명합니다.
- java.lang.ArrayIndexOutOfBoundsException: 배열 색인 범위 초과: 0
- 이 예외는 IdP(Identity Provider) 토큰을 제거하지 않고 미요청 서비스 제공자(SP) 시작 요청을 통해 다중 로그인을 시도한 경우에 발생할 수 있습니다.
- 이를 피하려면 <httpSession invalidateOnUnauthorizedSessionRequestException="true" />를 관련된 비요청 server.xml 파일에서 추가하십시오.
- java.lang.IllegalStateException: CWWKS0010E: 호출자 프린시펄을 가져오는 중에 호출자 주제에 WSPrincipal 유형의 프린시펄이 둘 이상 있음을 발견했습니다. 해당 주제에는 하나의 WSPrincipal만 있을 수 있습니다. WSPrincipal의 이름은 다음과 같습니다. {0}
- 이 예외는 SAML 사용자가 이전에 사내 구축 환경의 사용자 레지스트리에 직접 로그인한 경우에 발생할 수 있습니다. 이 문제점을 피하려면 SAML 사용자가 사내 구축 환경의 사용자 레지스트리에 직접 로그인하지 않아야 합니다.
REST API 발견 문제점 해결
IBM REST API 문서 탐색기 "시도하기" 선택이 원격으로 호출되고 0과 같은 응답 코드와 함께 실패하는 경우 완전한 호스트 이름 또는 IP 주소가 GET, PUT, POST 또는 DELETE 조작과 연관된 Curl 및 Request URL에서 IBM REST API 발견 탐색기로 리턴되는지 확인하십시오. 완전한 호스트 이름 또는 IP 주소가 Curl 및 Request URL에 없는 경우 다음 조치를 완료하십시오.
- server.xml에서 변수 요소를 추가하고 완전한 호스트 이름을
지정하십시오. server.xml 파일에서
완전한 호스트 이름을 지정하는 변수 요소를 추가하는 예제는
다음과 같습니다.
<httpEndpoint host="*" httpPort="9080" httpsPort="9443" id="defaultHttpEndpoint"/> <variable name="defaultHostName" value="developer.rtp.raleigh.ibm.com"/>
운영 체제의 전체 컴퓨터 이름을 완전한 호스트 이름으로 지정하십시오.
- 완전한 호스트 이름이 IBM REST API 발견 탐색기의 GET, PUT, POST 또는 DELETE 조작과 연관된 Curl 및 Request URL에서 리턴되는지 확인하십시오. 자세한 정보는 Liberty 서버의 기본 호스트 이름 설정의 내용을 참조하고 IBM InfoSphere Information Server, 버전 11.3.1 제품 문서에서 네트워크 구성에 대해 읽으십시오.