Liberty のトラブルシューティングのヒント

一般的な問題の解決策がトラブルシューティング資料に記述されています。

問題の特定と解決に役立つように、本製品には統一されたロギング・コンポーネントがあります。 ロギングおよびトレースを参照してください。

例外メッセージを受け取った場合、 メッセージに関する情報は Liberty: メッセージにあります。

各 Liberty API の Java™ API 文書は、${wlp.install.dir}/dev ディレクトリーのいずれかの javadoc サブディレクトリー内の個別 .zip ファイル内にあります。

Liberty の使用時に適用される主な既知の制約事項の詳細については、『ランタイム環境での既知の問題および制約事項』を参照してください。

JDK がサポート・レベルであることを確認する

容易に説明のつかない問題が起こった場合は、使用中の JDK が Java バージョン 7 以降に準拠したものであり、かつ、現行のサービス・レベルであることを確認してください。 Java の最小サポート・レベルを参照してください。

セキュリティーのトラブルシューティング

このセクションでは、 よくあるセキュリティーの問題と、選択可能な解決策について説明します。

SESN0008E: 匿名で認証されたユーザーが、ユーザー 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}
このエラーは、アプリケーションに必要なロールへの許可がない場合に発生します。 ユーザーまたはユーザーが属するグループが、エラー・メッセージで言及された少なくとも 1 つのロールに必ずマップされるようにしてください。 ibm-application-bnd.xmi/xml ファイルに定義されたユーザーからロールへのマッピングが、server.xml ファイルに定義されたマッピングより優先されます。両方のリソースを検査して、正しいマッピングが定義されていることを確認してください。 Liberty でのアプリケーションの許可の構成を参照してください。
CWWKS9104A: ユーザー {0} の許可が失敗しました。
同じコンテキスト・ルートに applicationwebApplication の両方を指定した場合に、このエラーが発生する可能性があります。 競合した場合、定義された最新構成は無視され、CWWKS9104A などの予期しないエラーが発生します。
「CWWKZ0013E: {0} という 2 つのアプリケーションを開始することはできません」の後に、予期しないセキュリティー動作およびエラーのメッセージ (CWWKS9104A など) が続く。
このエラーは、server.xml (application エレメントを使用) と dropins フォルダーの両方でアプリケーションを指定した場合に発生します。 結果として、アプリケーションのインストールが 2 回試行され、server.xml ファイル内のセキュリティー構成が有効または無効になることがあります。この問題を修正するには、アプリケーションを dropins フォルダーから削除して、別のディレクトリーにコピーする必要があります。dropins フォルダー内に残す必要がある場合は、server.xml ファイル内で以下のコードを使用して、アプリケーション・モニターを無効にする必要があります。
<applicationMonitor dropinsEnabled="false"/>
自分のサーブレットまたは JSP に非認証ユーザーがアクセス可能であった
プリンシパル UNAUTHENTICATED のユーザー (または z/OS® 上の非認証 SAF ユーザー) は、認証が失敗したとき、あるいは、サーブレットまたは JSP が無保護の場合に作成されます。 セキュリティー制約を何も定義していない場合、または特別な対象 EVERYONE をアプリケーションに必要なロールにマップした場合、 サーブレットまたは JSP に非認証ユーザーがアクセスすることが可能になります。 ibm-application-bnd.xmi/xml ファイルと server.xml ファイルでユーザーとロールのマッピングを確認してください。 以下のオプションのいずれかを選択してください。
  • サーブレットまたは JSP が無保護の場合、アプリケーションのデプロイメント記述子にセキュリティー制約を追加します。 認証を参照してください。
  • 非認証ユーザーがアプリケーションにアクセスしないようにする場合、 そのロールのマッピングから特別な対象 EVERYONE を削除します。 Liberty でのアプリケーションの許可の構成を参照してください。
  • 特定ユーザーをサーブレットまたは JSP に許可できない場合には、 ibm-application-bnd.xmi/xml ファイルと server.xml ファイルを調べて、 そのロールに誰がマップされているかを確認します。 ロールは、ユーザー、グループ、または特別な対象にマップすることができます。 ロールが特別な対象 EVERYONE にマップされている場合、すべてのユーザーにアクセスが認可されます。 ロールが特別な対象 ALL_AUTHENTICATED にマップされている場合には、 すべての認証ユーザーにアクセスが認可されます。 サーブレットまたは JSP にアクセス可能なユーザーをさらに制限したい場合には、これらの特別な対象を削除します。 最後に、ユーザーがどんなグループに属するかを確認します。 ユーザーに明示的なアクセス権限がなくても、グループがロールにマップされている可能性があります。 この場合、許可されているグループからユーザーを削除するか、ロール・マッピングからグループを削除します。 Liberty でのアプリケーションの許可の構成を参照してください。
シングル・サインオン (SSO) が動作しない
SSO が動作しない場合は、同じ LTPA 鍵、パスワード、および webAppSecurity エレメントの ssoCookieName 属性を使用している異なる Liberty サーバーで、世界時 (UTC) が同じであること、およびユーザー・レジストリーを共有していることを確認します。また、トークンが期限切れの場合、あるいは、レルムの変更や Cookie が表すユーザーの削除など、不整合な方法でユーザー・レジストリーを変更した後で Web ブラウザーから Cookie が送信された場合、SSO が失敗し、ユーザーは資格情報の再入力を求められます。Liberty での LTPA Cookie を使用した SSO 構成のカスタマイズを参照してください。
セキュリティー・パブリック API のデバッグ。
WSSecurityHelper および RegistryHelper は、セキュリティーが有効になっていない場合 (例えば、セキュリティー・フィーチャー appSecurity-1.0appSecurity-2.0、または zosSecurity-1.0 が指定されていない場合) でも、ロードされます。セキュリティーが有効でない場合、WSSecurityHelper.isServerSecurityEnabled() メソッドと WSSecurityHelper.isGlobalSecurityEnabled() メソッドはどちらも false を返し、 RegistryHelper.getUserRegistry() メソッドは null を返します。

セキュリティーが有効でない場合、他のセキュリティー・パブリック API クラスはロードされない可能性があります。 これらのクラスにアクセスし、これらのクラスのいずれかでメソッドを呼び出そうとすると、java.lang.NoClassDefFoundError 例外が発生することがあります。

java.lang.NoClassDefFoundError 例外が発生しないようにするには、 まず、WSSecurityHelper.isServerSecurityEnabled() クラスまたは WSSecurityHelper.isGlobalSecurityEnabled() クラスを呼び出すことでセキュリティーが有効かどうかをテストして確認し、 セキュリティーが有効な場合にのみ、他のセキュリティー・パブリック API クラスを呼び出してください。 このコーディング手法の例については、『Liberty のセキュリティー・パブリック API』を参照してください。

注: この動作は WebSphere® Application Server traditional とは異なります。 WebSphere Application Server traditionalでは、セキュリティーが有効かどうかに関係なく、 すべてのクラスが常にロードされます。
Unicode 文字でユーザーを認証できない
名前に Unicode 文字が含まれているユーザーを認証するには、以下の jvm オプションを server start コマンドに追加して、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:Wrong type at constant pool index at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:87)
このエラーが発生する可能性があるのは、OpenID Connect または OAuth プロバイダーが、一部の JDK 7 バージョンでクライアント登録にデータベース・ストアを使用している場合です。

この問題を回避するには、JDK バージョン 7.1 にアップグレードしてください。

LDAP のトラブルシューティング

このセクションでは、 よくある LDAP の問題と、選択可能な解決策について説明します。

FFDC1015I: 発生事象が作成されました: javax.naming.ServiceUnavailableException: myldapserver.mycompany.com:636; socket closed com.ibm.ws.security.registry.ldap.internal.LdapRegistry 298
messages.log のこのメッセージは、構成されている LDAP サーバーに到達できないことを示しています。 LDAP サーバーを検査して、それが稼働していること、および Liberty プロファイル・サーバーからその IP アドレスにアクセスできることを確認してください。
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]
LDAPSSLSettings エレメントで参照されるトラストストアに LDAP サーバーの署名者をコピーせずに、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: FFDC 発生事象が作成されました: "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" ロケーション: ffdc_12.04.18_16.09.42.0.log
ID フィールドが指定されていない keystore エレメントが構成にある場合に、このエラーが発生します。 最小 SSL 構成を使用する場合には、ID フィールドを defaultKeyStore に設定してください。
sslEnabled とともに LDAP ユーザー・レジストリーを使用し、sslRef 値が指定されていない場合、例外が発生することがあります。
例えば、以下の例に示すように、構成で 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 構成を使用している場合を考えます。
<ltkeyStore id="defaultKeyStore" location="key.jks" password="mypassword" />
この場合、sslRef フィールドは、defaultSSLConfig に設定する必要があります。

カスタム SSL 構成が設定されている場合、その構成の名前を sslRef フィールドに入れる必要があります。

Liberty サーバーで SSL を使用可能にしている場合に、WebSphere Application Server から JDK を使用すると、以下のエラーが表示されることがあります。
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 ではサポートされていないために発生します。以下のステップを実行することで、この問題を解決できます。
  • 以下の 2 つの空の項目が含まれたテキスト・ファイル (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 環境のカスタマイズ』を参照してください。

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) インターセプターが Liberty ではサポートされないために発生します。これらのインターセプターを使用しないように JDK の orb.properties ファイルを編集することで、この問題を解決することができます。このファイルは、WebSphere の <JAVA_HOME>/jre/lib ディレクトリーにありますが、ユーザーの <USER_HOME> ディレクトリーにあるコピーでオーバーライドされている可能性があります。以下の例は、コメント化する必要がある 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.util.logging のハンドラー、フィルター、またはフォーマッターを作成および追加するには、Java コードを使用します。
Liberty サーバーは、ロギング構成エレメントの traceSpecification 属性に従って java.util.logging ロガー・レベルを管理しているため、Logger.setLevel メソッドは使用しないようにしてください。

JAX-WS のトラブルシューティング

このセクションでは、よくある JAX-WS の問題と、選択可能な解決策について説明します。

Liberty での Web サービス・アプリケーションのデプロイ時に、org.apache.cxf.bus.extension.ExtensionException が発生しました。
アプリケーションに CXF ライブラリーと構成が既に組み込まれていて、アプリケーションを Liberty にデプロイする場合は、jaxws-2.2 サーバー・フィーチャーが server.xml ファイルから削除されて使用不可になっていることを確認する必要があります。
Oracle JVM で IBM® ファスト・パスを実行中に、java.lang.NoClassDefFoundError 例外が発生しました。
IBM ファスト・パスの Java Architecture for XML Binding (JAXB) を使用するために、最適化メソッドを JAXB アンマーシャル (デシリアライゼーション) およびマーシャル (シリアライゼーション) に使用可能にするかどうかを制御するよう、com.ibm.xml.xlxp.jaxb.opti.level カスタム・プロパティーを構成できます。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
com.ibm.xml.xlxp.jaxb.opti.level プロパティーの詳細については、『Java 仮想マシンの カスタム・プロパティー』のページを参照してください。
Oracle JVM で WebSphere Application Server traditional のシン・クライアントを実行中に java.lang.NoClassDefFoundError : com.ibm.CORBA.iiop.ORB 例外が発生しました。
このエラーは、Oracle JVM で WebSphere Application Server traditional のシン・クライアントの実行を試行する際に、jaxws-2.2 フィーチャーが Liberty で既に使用可能になっている場合に発生します。この問題を解決するには、次に示すように、WWebSphere 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>
com.ibm.websphere.thinclient プロパティーについての類似情報が、『PM39777: ADMINISTRATIVE THIN CLIENT USING SOAP CONNECTOR AND SUN JDK DOES NOT WORK』のページにあります。
バイナリー・ファイルを取得する際に、MTOM サービスから MTOM クライアントに空のファイルが返されました。
このシナリオは、MTOM クライアントが MTOM サービスへ正常にバイナリー・ファイルを送信したにもかかわらず、同じバイナリー・ファイルを MTOM サービスから取得する際に空のファイルが戻された場合に発生します。
回避策として、DataHandler を新規に作成し、バイナリー・ファイルの内容を入力してその DataHandler を初期化することができます。例えば、FileDataStore オブジェクトを使用して入出力から読み取り、新規作成した DataHandler を返して、その DataHandler を他の Web サービスに渡します。
...
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;
...
The javax.xml.ws.soap.SOAPFaultException: Oracle JVM で XMLGregorianCalendar を xsd:gMonth 形式で使用する際に、アンマーシャル・エラーが発生しました。
このエラーは、Oracle JVM で XMLGregorianCalendar クラスを使用して gMonth 形式の定数をクライアント・サイドの SOAP 要求の一部として保管する際に、Libertyjaxws-2.2 フィーチャーが使用可能になっている場合に発生します。この根本原因は、Oracle JVM は xsd:gMonth タイプ用の新しい標準形式 --MM をサポートしているのに対し、最新の JAXB RI (参照実装) は --MM-- の形式のみをサポートするということです。
クライアント・サイドのアプリケーションとサーバー・サイドのアプリケーションの両方で Oracle JVM を IBM JVM に変更することで、この問題は解決できます。
wsdlLocation 属性で指定された WSDL ファイルを解決する際に、java.io.FileNotFoundException が発生しました。
このエラーは、WSDL ファイルをコード wsdlLocation = "file:/WEB-INF/wsdl/a.wsdl" 内のように指定する際、WSDL ファイルがご使用のアプリケーション内でパッケージ化されている場合に発生します。ご使用のアプリケーションでパッケージ化された WSDL ファイルを参照する場合、@WebService@WebServiceProvider@WebServiceClient@WebServieRef のいずれかのアノテーションで定義された wsdlLocation 属性の相対 URI を使用する必要があります。
wsdlLocation 属性の相対 URI は、次のいずれかの値でなければなりません。
  • wsdlLocation = "/WEB-INF/wsdl/a.wsdl"
  • wsdlLocation = "WEB-INF/wsdl/a.wsdl"
「Creating service」というメッセージが、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"/>
クライアント・アプリケーションが SOAP アクションを送信したときに、SOAPFaultException の「The given SOAPAction test does not match an operation」が発生しました。
注: test は、要求 HTTP ヘッダー内の soapAction 属性の値です。
SOAP Web サービスの各操作は、WSDL バインディングやアノテーションなどで SOAP アクション・ストリングと関連付けることができます。 Web サービス・クライアントは SOAP アクション・ストリングを要求と共にヘッダーとして送信して、Web サービス・プロバイダーの操作に一致させます。このエラー・メッセージは、次のいずれかのシナリオで表示されます。
  • クライアントによって送信された SOAP アクションが、操作の SOAP アクションに一致しない場合。
  • WebSphere Application Server traditional を JAX-WS クライアントとして使用し、Liberty を JAX-WS サービスとして使用し、WSDL ファイルに定義された soapAction が空の値 "" に等しい場合。
この問題を解決するには、次のようにします。
  • Web サービス・クライアントとサービス・プロバイダーの両方に、同じ 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 エレメントと異なるときにヌル応答が戻されました。
次のように、SEI クラスを使用して @WebResult アノテーションの name 属性を定義し、SEI クラスで WSDL ロケーションを指定した場合に、この問題が発生します。
@WebService(wsdlLocation="WEB-INF/wsdl/WebServiceIfc.wsdl")
public interface WebServiceRuntimeIfc {
        @WebMethod
        @WebResult(name="nononoreturn") 
        public String echo (String parm);
}
一方、指定された WSDL 文書内の XML エレメントの宣言は、以下のようになっています。
<xs:element name="echoResponse">
	<xs:complexType>
		<xs:sequence>
			<xs:element name="return" type="xs:string" minOccurs="0"/>
		</xs:sequence>
	</xs:complexType>
</xs:element>
この場合、echo() メソッドが呼び出されたときに、Web サービス・クライアントはヌル応答を受け取ります。
この問題を解決するには、@WebResult アノテーションの name 属性が、WSDL 文書内の name エレメントの値に一致することを確認してください。
JAX-WS クライアント・アプリケーションがサーバー・サイドから WSDL 文書の変更を取得できませんでした。
Web サービス・クライアントとサービス・プロバイダーが Liberty 上の異なる 2 つのアプリケーション内にあって、クライアントがサービス・プロバイダーから WSDL 文書を動的に取得する必要がある場合に、この問題が発生します。これは、Liberty では、WebSphere Application Server traditional の場合の動作と異なり、 WSDL 文書が初めてアクセスされたときに WSDL 定義をキャッシュに入れることが原因です。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 のトラブルシューティング

このセクションでは、WS-Security の問題に対する一般的な解決策について説明します。
  1. server.xml ファイルを検査し、JAX-WS (jaxws-2.2) およびセキュリティー (appSecurity-2.0) の必要なフィーチャーが正しく構成されていることを確認してください。
  2. WS-Security で Web サービス・アプリケーションを保護するには、WS-Security ポリシーが組み込まれた WSDL ファイルが JAX-WS アプリケーションに含まれていなければなりません。wsdl:binding または wsdl:operation、あるいはその両方のセクションに、 その組み込み WS-Security ポリシーに対する PolicyReference がなければなりません。
  3. UsernameTokens 生成のためのパスワードの取得、または鍵ストア・ファイルの秘密鍵のためのパスワード取得にコールバック・ハンドラーを使用する場合、パスワード・コールバック・ハンドラーが Liberty にユーザーのフィーチャーとしてパッケージ化され、デプロイされていなければなりません。

WS-Security トレースの使用可能化

エラー・メッセージの情報では問題の原因を判別できない場合、Liberty トレースおよびロギング機能を使用して WS-Security コンポーネントのトレースを収集できます。『Liberty: トレースおよびロギング』を参照してください。

以下のトレース・ストリングを使用すると、トレースを収集して WS-Security 障害をデバッグすることができます。
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.1server.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: 使用可能なコールバック・ハンドラーおよびパスワードがありません。
このエラーは、UsernameToken の生成または鍵ストアの秘密鍵へのアクセスに必要となるパスワードを WS-Security ランタイムが取得できない場合に発生します。このエラーを回避するには、以下の構成を確認します。
  1. パスワード・コールバック・ハンドラー・フィーチャー 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>
  2. コールバック・ハンドラー・プロパティー ws-security.callback-handlerserver.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"
  3. パスワード・コールバック・ハンドラーが、server.xml ファイルに指定されたユーザー名または鍵別名に対して正しいパスワードを返すことを確認してください。 パスワードは平文で、エンコードや暗号化をされていない状態でなければなりません。
org.apache.ws.security.WSSecurityException: 必要なエレメント (soap:Body) が署名によりカバーされていません。
このエラーは、Web サービス・プロバイダー・アプリケーションで、要求メッセージ内の SOAP 本体が署名済みであることが想定されているにもかかわらず、受信した SOAP メッセージの SOAP 本体が署名されていない場合に発生します。このエラーを回避するには、ご使用の Web サービス・クライアントが、Web サービス・プロバイダーのポリシーと一致する正しい WS-Security ポリシーで構成されていることを確認してください。
org.apache.ws.security.WSSecurityException: 署名と暗号化解除のいずれかが無効です。
このエラーは、WS-Security ランタイムが署名の検証に失敗した場合、もしくは受信した SOAP メッセージの暗号化メッセージ・パーツを暗号化解除できなかった場合に発生します。このエラーを回避するには、server.xml ファイルの <wsSecurityClient> および <wsSecurityProvider> エレメントで WS-Security を構成する際に、正しいキーが使用されていることを確認してください。Web サービス・クライアントが Bob の 公開鍵を使用してメッセージ・パーツを暗号化する場合、Web サービス・プロバイダーはそのメッセージを暗号化解除するためには、Bob の秘密鍵へのアクセス権限を持っていなければなりません。同様に、Web サービス・クライアントが Alice の秘密鍵を使用してメッセージ・パーツに署名する場合、Web サービス・プロバイダーはその署名を検証するためには Alice の公開鍵を使用しなければなりません。
org.apache.cxf.ws.policy.PolicyException: これらのポリシー代替は満足できません。
このエラーは、WS-Security ランタイムが、その要求を処理するように構成された WS-Security ポリシーを使用して着信 SOAP メッセージを正常に処理できない場合に発生します。このエラーを回避するには、この例外の後に続くメッセージを確認し、この例外の原因となっている特定の 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)
この場合、エラー発生の原因は、 Web サービス・クライアントが使用する暗号化アルゴリズムが AlgorithmSuite アサーションの指定する暗号化アルゴリズムと一致しないことです。Web サービス・クライアントと Web サービス・プロバイダーの両方の WS-Security ポリシーで指定されたアルゴリズム・スイートには同じ暗号化アルゴリズムを指定する必要があります。
javax.xml.ws.soap.SOAPFaultException: メッセージの有効期限が切れました (WSSecurityEngine: タイム・スタンプが無効です。メッセージのセキュリティー・セマンティクスの有効期限が切れました)。
このメッセージは、メッセージのタイム・スタンプの有効期限が切れている場合や、メッセージが将来のタイム・スタンプで作成されている場合に発生します。

パフォーマンスのトラブルシューティング

このセクションでは、よくあるパフォーマンスの問題と、選択可能な解決策について説明します。

アプリケーション・モニターによる CPU 使用量が多くなっています。

このエラーは、アプリケーション・モニターが apps/ ディレクトリーに多くのファイルを持っており、ポーリング頻度が高すぎる場合に発生する可能性があります。

この問題を回避するために、いくつか変更できることがあります。

  1. applicationMonitor エレメント内の pollingRate 属性の値を増やします。
  2. server.xml を更新して、polled ではない updateTrigger と共に applicationMonitor エレメントを含めます。
    server.xml                                                                      
    <applicationMonitor updateTrigger="mbean" /> 
  3. apps/ ディレクトリーに含まれているファイルの数を減らします。

applicationMonitor エレメントについて詳しくは、『動的更新の制御』を参照してください。

集合のトラブルシューティング

このセクションでは、集合に関する問題と、適用する必要のある解決策について説明します。

java.lang.IllegalArgumentException: CWWKX0219E: MBean 'WebSphere:feature=collectiveController,type=CollectiveRepository,name=CollectiveRepository' に 'retrieveMemberRootCertificate' という名前の操作はありません
フィーチャー collectiveMember-1.0 を持つサーバー (メンバー) を、 フィーチャー collectiveController-1.0 を持つサーバー (コントローラー) (下位レベルの Liberty) に登録することはできません。例えば、このベータ・レベルの Liberty のメンバーは、自身を V8.5.5.2 Liberty のコントローラーに登録することはできません。

デフォルトのロギングでは、この問題は、当該メンバーの FFDC ログに「初期障害データ・キャプチャー機能 (FFDC)」としてレポートされます。

この問題を修正するには、当該コントローラーを、同一またはそれ以上のレベルの Liberty にそのメンバーとして移動する必要があります。

SAML のトラブルシューティング

このセクションでは、SAML に関する問題と、適用する必要のある解決策について説明します。

java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 0
ID プロバイダー・トークン (IdP) を削除せずに非送信請求サービス・プロバイダー (SP) 開始要求を通じて複数のログインを試行すると、この例外が発生する可能性があります。
これを回避するには、関連する非送信請求 server.xml ファイルに <httpSession invalidateOnUnauthorizedSessionRequestException="true" /> を追加します。
java.lang.IllegalStateException: CWWKS0010E: 呼び出し元のプリンシパルを取得する際に、呼び出し元サブジェクトで、タイプ WSPrincipal のプリンシパルが複数検出されました。 サブジェクトには 1 つの WSPrincipal しか存在できません。 WSPrincipal の名前: {0}
SAML ユーザーが以前にオンプレミスのユーザー・レジストリーに直接ログインした場合に、この例外が発生する可能性があります。 この問題を回避するには、 SAML ユーザーがオンプレミスのユーザー・レジストリーに直接ログインしないでください。

REST API Discovery のトラブルシューティング

IBM REST API Discovery Explorer の「試す (Try it out)」の選択がリモートから呼び出され、0 に等しい応答コードで失敗する場合、完全修飾ホスト名または IP アドレスが GET、PUT、POST、または DELETE の各操作に関連付けられた Curl および要求 URL で IBM REST API Discovery Explorer に返されるようにします。 完全修飾ホスト名または IP アドレスが Curl および要求 URL にない場合 、以下のアクションを実行します。

  1. server.xml に可変エレメントを追加し、完全修飾ホスト名を指定します。 以下に、server.xml ファ イルに完全修飾ホスト名を指定する可変エレメントを追加する例を示します。
     <httpEndpoint host="*" httpPort="9080" httpsPort="9443" id="defaultHttpEndpoint"/>          
    <variable name="defaultHostName" value="developer.rtp.raleigh.ibm.com"/>
  2. 完全修飾ホスト名が、IBM REST API Discovery Explorer の GET、PUT、POST、または DELETE の各操作に関連付けられた Curl および要求 URL に返されることを確認します。詳しくは Liberty サーバーのデフォルト・ホスト名の設定を参照し、IBM InfoSphere Information Server バージョン 11.3.1 製 品資料のご使用のネットワーク構成についてお読みください。

トピックのタイプを示すアイコン 参照トピック

ファイル名: rwlp_trouble.html