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

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

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

例外メッセージを受け取った場合、そのメッセージに関する情報は「 メッセージ」に記載されています。

各 Liberty API の Java™ API 資料は、オンラインの IBM® 資料の「 プログラミング・インターフェース (Javadoc) 」セクションに詳述されています。また、 ${wlp.install.dir}/dev ディレクトリーのいずれかの javadoc サブディレクトリーにある別個の .zip ファイルとしても入手できます。

分散: [AIX MacOS Linux Windows] Liberty を使用する場合に適用される主な既知の制約事項の詳細は、以下の 2 つのトピックに記載されています。

IBM i プラットフォームの場合 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} の許可が失敗しました。
同じコンテキスト・ルートに application と webApplication の両方を指定した場合に、このエラーが発生する可能性があります。 競合した場合、定義された最新構成は無視され、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 が機能しない場合は、 webAppSecurity エレメントの同じ LTPA 鍵、パスワード、および ssoCookieName 属性を使用する異なる Liberty サーバーが同じ世界時 (UTC) を持ち、ユーザー・レジストリーを共有していることを確認してください。 また、トークンが期限切れの場合、あるいは、レルムの変更や Cookie が表すユーザーの削除など、不整合な方法でユーザー・レジストリーを変更した後で Web ブラウザーから Cookie が送信された場合、SSO が失敗し、ユーザーは資格情報の再入力を求められます。 Liberty での LTPA Cookie を使用した SSO 構成のカスタマイズを参照してください。
セキュリティー・パブリック API のデバッグ。
WSSecurityHelper および RegistryHelper は、セキュリティーが有効になっていなくてもロードされます。例えば、セキュリティー機能 ( appSecurity-1.0、 appSecurity 、または zosSecurity-1.0 ) が指定されていない場合などです。 セキュリティーが有効でない場合、WSSecurityHelper.isServerSecurityEnabled() メソッドと WSSecurityHelper.isGlobalSecurityEnabled() メソッドはどちらも false を返し、 RegistryHelper.getUserRegistry() メソッドは null を返します。

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

java.lang.NoClassDefFoundError 例外が発生しないようにするには、 まず、WSSecurityHelper.isServerSecurityEnabled() クラスまたは WSSecurityHelper.isGlobalSecurityEnabled() クラスを呼び出すことでセキュリティーが有効かどうかをテストして確認し、 セキュリティーが有効な場合にのみ、他のセキュリティー・パブリック API クラスを呼び出してください。 このコーディング手法の例については、 セキュリティー・パブリック 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 サーバーを調べて、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 に設定します。
LDAP または統合リポジトリーの場合、ログイン、認証、または許可の処理が遅くなります。
ログインに時間がかかる理由はいくつか考えられます。 以下のリストで、いくつかの一般的な原因を確認してください。
  • 参照に関する LDAP 構成が follow に設定されている場合、LDAP 要求で、その他の LDAP インスタンスへの参照があると、それらがすべてフォローされます。 この状態により、ご使用の LDAP 構成によっては、追加で 1 つ以上の LDAP サーバーへの問い合わせが発生する可能性があり、そのために追加の時間がかかります。 例えば、LDAP1 サーバーが LDAP2 サーバーへの参照をフォローし、そこから LDAP3 サーバーへの参照をフォローする可能性があります。 他の LDAP サーバーから追加で情報を取得する必要がない場合は、参照を ignore に設定してください。 また、1 つの LDAP サーバーで、JVM ログに表示されない問題やエラーが発生している可能性もあります。 そのような例には、TCP 読み取りタイムアウトや、LDAP サーバーが参照先 LDAP サーバーに問い合わせる際の DNS の問題などがあります。 このような状態を診断するには、パケットをキャプチャーして、発生している呼び出しの数を確認したり、参照をフォローしている LDAP サーバーが原因の遅延やエラーが存在していないかどうかを確認したりします。
  • ファイアウォールまたはその他のソフトウェアによって、LDAP への接続がクローズされています。 デフォルトで、パフォーマンスを高めるために、LDAP 接続のプールが維持されます。 キャッシュされた接続がリモート側でクローズされると、新しい接続が作成され、コンテキスト・プールにプットバックされます。 このプロセスによって、遅延が発生し、JVM ログに記録されるエラーが発生する可能性があります。 この状態を回避するには、コンテキスト・プールのタイムアウトをリモート接続のクローズ時間よりも小さく設定します。 例えば、ファイアウォールが 10 分で接続をクローズする場合は、接続プールのタイムアウトを 9 分に設定します。 接続障害が発生し、新規接続を作成する代わりに、プールにある接続の有効期限がチェックされ、新しい接続を作成することで、障害ステップをスキップできます。 エラーの例には、以下のようなものがあります。
    java.net.SocketException: Connection reset
    コンテキスト・プール・タイムアウトの設定について詳しくは、 ldapRegistry エレメントの contextPool エレメントを参照してください。
  • 統合リポジトリーでは、レルム内に固有のユーザーが存在することを確認するために、すべてのリポジトリーとレジストリーがチェックされます。 リポジトリーまたはレジストリーの応答が遅い場合は、ユーザーが属しているレジストリーが遅くなくとも、すべての呼び出しが遅くなります。 関与しているすべての基本エントリーが迅速に応答していることを確認してください。
LDAP サーバーにアクセスしているときに、接続例外が発生することがあります。 例えば、「java.net.SocketException: 接続がリセットされました (java.net.SocketException: Connection reset)」です。
ファイアウォールまたはその他のソフトウェアによって、LDAP への接続がクローズされています。 デフォルトで、パフォーマンスを高めるために、LDAP 接続のプールが維持されます。 キャッシュされた接続がリモート側でクローズされると、新しい接続が作成され、コンテキスト・プールにプットバックされます。 このプロセスによって、遅延が発生し、JVM ログに記録されるエラーが発生する可能性があります。 この状態を回避するには、コンテキスト・プールのタイムアウトをリモート接続のクローズ時間よりも小さく設定します。 例えば、ファイアウォールが 10 分で接続をクローズする場合は、接続プールのタイムアウトは 9 分に設定できます。 接続障害が発生し、新規接続を作成する代わりに、プールにある接続の有効期限がチェックされ、新しい接続を作成することで、障害ステップをスキップできます。

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. 例外 = 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 とともに 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 構成を使用している場合は、sslRef フィールドを defaultSSLConfig に設定する必要があります。

PKCS12 鍵ストアを使用している場合、最小構成は以下のようになります。
<ltkeyStore id="defaultKeyStore" location="key.p12"
password="mypassword" />
JKS 鍵ストアを使用している場合、最小構成は以下のようになります。
<ltkeyStore id="defaultKeyStore" location="key.jks"
password="mypassword" />

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

WebSphere Application Serverから JDK を使用する場合、 Liberty サーバーで SSL が有効になっていると、以下のエラーが表示されることがあります。
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 Object Request Broker (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 の問題と、選択可能な解決策について説明します。

org.apache.cxf.bus.extension.ExtensionException は、Web サービス・アプリケーションを Libertyにデプロイするときに発生しました。
アプリケーションに既に組み込まれている CXF ライブラリーと構成があり、アプリケーションを Libertyにデプロイする場合は、 server.xml ファイルからフィーチャーを削除して、 jaxws-2.2 サーバー・フィーチャーが使用不可になっていることを確認する必要があります。
Oracle JVM で IBM ファースト・パスを実行中に、 java.lang.NoClassDefFoundError 例外が発生しました。
IBM fastpath Java Architecture for XML Binding (JAXB) を使用するには、 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 仮想マシンのカスタム・プロパティー」 ページで、 com.ibm.xml.xlxp.jaxb.opti.level プロパティーの詳細情報を参照してください。
Oracle JVM で WebSphere Application Server traditional のシン・クライアントを実行中に java.lang.NoClassDefFoundError : com.ibm.CORBA.iiop.ORB 例外が発生しました。
このエラーは、 WebSphere Application Server traditional シン・クライアントを Oracle JVM で実行しようとしたときに、 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 クライアントに空のファイルが返されました。
このシナリオは、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 形式で使用する際に、アンマーシャル・エラーが発生しました。
このエラーは、 XMLGregorianCalendar クラスを使用して gMonth フォーマット定数をクライアント・サイドの SOAP 要求の一部として保管し、 Oracle JVM を使用する Liberty で jaxws-2.2 フィーチャーが有効になっている場合に発生します。 根本原因は、 Oracle JVM が xsd:gMonth タイプの新しい標準形式 -- MM をサポートしているのに対し、最新の JAXB RI (参照実装) は -- 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"/>
クライアント・アプリケーションが 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 が 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 のトラブルシューティング

このセクションでは、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:
org.apache.cxf.ws.security.*=all:
org.apache.cxf.ws.policy.*=all:
org.apache.xml.security.*=all:
com.ibm.ws.wssecurity.*=all

このセクションでは、よくある 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: 使用可能なコールバック・ハンドラーおよびパスワードがありません。
このエラーは、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-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"
  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: タイム・スタンプが無効です。メッセージのセキュリティー・セマンティクスの有効期限が切れました)。
このメッセージは、メッセージのタイム・スタンプの有効期限が切れている場合や、メッセージが将来のタイム・スタンプで作成されている場合に発生します。
IBM i プラットフォームの場合分散: [AIX MacOS Linux Windows]

アーカイブ・インストールに対するフィックスパックとインテリム・フィックスの適用

Installation Managerを使用するのではなく、アーカイブ・ファイルから Liberty ランタイム環境をインストールした場合は、サービス更新を適用する際に特別な措置を取る必要があります。 詳しくは、 Liberty Java アーカイブ・インストールへのフィックスパックの適用 および Liberty アーカイブ・インストールへの暫定修正の適用を参照してください。

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

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

アプリケーション・モニターによる 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を持つサーバー (メンバー) は、以前のレベルの Libertyのコントローラーであるフィーチャー collectiveController-1.0を持つサーバーに登録できません。 例えば、このベータ・レベルの 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. 分散: [AIX MacOS Linux Windows] ご使用のオペレーティング・システムに完全修飾ホスト名として完全なコンピューター名を指定します。
  3. 完全修飾ホスト名が、IBM REST API Discovery Explorer の GET、PUT、POST、または DELETE の各操作に関連付けられた Curl および要求 URL に返されることを確認します。 詳しくは、 Liberty サーバーのデフォルト・ホスト名の設定 を参照し、 IBM InfoSphere® Information Serverバージョン 11.3.1 製品資料でネットワークの構成に関する情報をお読みください。

組み込み Liberty サーバーでアプリケーションが開始しない場合のトラブルシューティング

組み込み Liberty サーバーを開始する Java プロセスが、 libertyInstallDir/bin/tools/ws-javaagent.jarを指す -javaagent JVM 引数を使用して開始されたことを確認します。 -javaagent JVM 引数が使用されていない場合は、サーバー・ランタイムは開始されますが、明確な例外なしに、アプリケーションは開始に失敗します。