トラブルシューティングのヒント
Liberty プロファイルのトラブルシューティングのヒント。
問題の特定と解決に役立つように、本製品には統一されたロギング・コンポーネントがあります。 『ロギングおよびトレース』を参照してください。また、${wlp.install.dir}/bin ディレクトリー内の IBM® Support Assistant Data Collector (ISADC) コマンド・ツールを使用して、ログ・ファイルや構成ファイルなどの診断ファイルを素早く収集したり、トレースを実行したりすることができます。
例外メッセージを受け取った場合、 メッセージに関する情報は メッセージにあります。
各 Liberty プロファイル API の Java™ API 文書は、インフォメーション・センターの プログラミング・インターフェース (API) のセクションに詳述されていて、${wlp.install.dir}/dev ディレクトリーのいずれかの javadoc サブディレクトリー内の個別 .zip ファイル内にもあります。

Liberty プロファイルの使用時に適用される主な既知の制約事項の詳細については、
『ランタイム環境での既知の問題および制約事項』を参照してください。
JDK がサポート・レベルであることを確認する
容易に説明のつかない問題が起こった場合は、使用中の JDK が Java バージョン 6 以降に準拠したものであり、かつ、現行のサービス・レベルであることを確認してください。 『Java の最小サポート・レベル』を参照してください。
- VM オプション -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass を使用可能にします。
- Equinox 構成オプション -Dosgi.classloader.lock=classname を設定することで、 クラス・ロードにクラス名ロックを使用するための Equinox フレームワーク・オプションを設定します。
セキュリティーのトラブルシューティング
このセクションでは、 よくあるセキュリティーの問題と、選択可能な解決策について説明します。
- 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 プロファイル上のアプリケーションの許可の構成』を参照してください。
- 「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.0、appSecurity-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 クラスを呼び出してください。 このコーディング手法の例については、『セキュリティー・パブリック API』を参照してください。
- 注: この動作は 完全プロファイル とは異なります。 完全プロファイルでは、セキュリティーが有効かどうかに関係なく、 すべてのクラスが常にロードされます。
- 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 構成を使用している場合を考えます。
この場合、sslRef フィールドは、defaultSSLConfig に設定する必要があります。<ltkeyStore id="defaultKeyStore" location="key.jks" password="mypassword" />
カスタム 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 プロファイル環境のカスタマイズ』を参照してください。
- 以下の 2 つの空の項目が含まれたテキスト・ファイル (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) インターセプターが Liberty プロファイルではサポートされないために発生します。これらのインターセプターを使用しないように JDK の orb.properties ファイルを編集することで、この問題を解決することができます。このファイルは通常、WebSphere の <JAVA_HOME>/jre/lib directory ディレクトリーにありますが、ユーザーの <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 メソッドは使用しないようにしてください。


アーカイブ・インストールに対するフィックスパックとインテリム・フィックスの適用
Liberty プロファイル・ランタイム環境のインストールを、Installation Manager を使用せずにアーカイブ・ファイルから行った場合は、サービス更新の適用時に特別な手段を実行する必要があります。詳細については、『Liberty プロファイル Java アーカイブ・インストールへのフィックスパックの適用』および『Liberty プロファイル・アーカイブ・インストールへのインテリム・フィックスの適用』を参照してください。
パフォーマンスのトラブルシューティング
このセクションでは、よくあるパフォーマンスの問題と、選択可能な解決策について説明します。
- アプリケーション・モニターによる CPU 使用量が多くなっています。
-
このエラーは、アプリケーション・モニターが apps/ ディレクトリーに多くのファイルを持っており、ポーリング頻度が高すぎる場合に発生する可能性があります。
この問題を回避するために、いくつか変更できることがあります。
- pollingRate 属性の値を増加します。
- server.xml を更新して、polled ではない updateTrigger と共に applicationMonitor エレメントを含めます。
server.xml <applicationMonitor updateTrigger="mbean" />
- apps/ ディレクトリーに含まれているファイルの数を減らします。
applicationMonitor エレメントについて詳しくは、『動的更新の制御』を参照してください。