Sun Java System Application Server Enterprise Edition 8.2 トラブルシューティングガイド

第 5 章 よくある質問

ここでは、Application Server に関してよく質問される事項について説明します。

サーバー側レルムを 1 つも設定していないとどうなりますか ?

アプリケーションが XML ファイル内で設定されているのに、サーバー側レルムが 1 つも設定されていない場合は、アプリケーションがデフォルトレルムで認証されます。「指定したレルムはありません。」というエラーはスローされません。

PKCS12 証明書をクライアント証明書として使用できますか ?

PKCS12 証明書を、相互認証時の SSL アプリケーションクライアントまたはスタンドアロンクライアントで使用する方法はありますか ?

いいえ。PKCS12 証明書を直接使用することはできません。ただし、JSSE を使用して独自のクライアントを記述することができ、その場合、storetype=PKCS12 (キーストアの読み取り専用、書き込みなし) がサポートされます。

SSL クライアントの TLS/SSL ハンドシェーク情報を見ることはできますか ?

はい。JVM 上で Java デバッグプロパティーを設定してください。アプリケーションクライアントからハンドシェーク情報を見るには、次の設定を付加します。

-Djavax.net.debug=ssl,handshake to the VMARGS variable.

キーストアのパスワードを変更できますか ?

はい。次の J2SE プロパティーを使用して、キーストアのパスワードを変更できます。

-Djavax.net.ssl.keyStorePassword=password
-Djavax.net.ssl.trustStorePassword=password

キーに対する操作を実行するには、キーストアのパスワードが個々のキーのパスワードと一致する必要があることに注意してください。そのため、前述のプロパティーを使用してキーストアのパスワードを変更した後、そのパスワードと一致するように各キーへのパスワードを変更する必要があります。

JAX-RPC 内のセッションをどのように維持できますか ?

JAX-RPC エンドポイントを持つセッションをクライアントで維持することはできません。セッションにはクライアント/サーバーの側面があるため、これを設定する明確な方法はありません。

考えられるのは、クライアントがサービスの呼び出しを行い、サーバーが応答して接続上に Cookie を設定するという方法です。それ以降、クライアントは呼び出しのたびにその同じ Cookie を送り返し、サーバーでそれをチェックすることが可能になります。

Cookie が送り返されても、通常、JAX-RPC スタブには影響を与えません。SESSION_MAINTAIN_PROPERTYtrue に設定すると、サーバーでスタブに設定したすべての Cookie が送り返されます。

サーバー側では、使用するクラスに 1 つのフィールドを追加し、そのフィールドを設定するメソッドを追加する必要があります。エンドポイントでは javax.xml.rpc.server.ServiceLifecycle. を実装し、さらに 2 つのメソッドdestroy() (空でも可) および init(Object context) を追加する必要があります。

エンドポイントに ServletEndpointContext オブジェクト、たとえば、myServletEndpointContext を追加します。init(Object context) メソッドは次のように設定できます。

myServletEndpointContext = (ServletEndpointContext) context;

これで、ビジネスメソッドから myServletEndpointContext.getHttpSession() を使用して HttpSession にアクセスできます。getHttpSession の最初の呼び出しで、セッションが存在していない場合はセッションが作成されます。

このモデルでは、クライアントから呼び出す任意のメソッドで、セッションの取得、セッション属性の設定、セッションからの値の取得などを行うことができます。この時点以降、クライアントから同じ Cookie 情報が送り返されます。

HttpSession オブジェクトの詳細については、http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/HttpSession.html を参照してください。

スタンドアロン Java クライアントからはどのようにネームサービスにアクセスできますか ?

Procedureアプリケーションクライアントからネームサービスにアクセスする

  1. クライアント Java VM 起動時の CLASSPATHappserv-rt.jar を追加します。

    JNDI ブートストラップ機構で、appserv-rt.jar にある jndi.properties という名前のファイルが検索されます。このファイルには、Application Server のネームサービスに関するすべてのブートストラッププロパティーが含まれています。これらのプロパティーは、クライアント起動スクリプトまたはアプリケーションコードに明示的に記述するよりも、appserv-rt.jar から読み取るようにすることをお勧めします。

  2. スタンドアロンクライアントからリモート EJB にアクセスする場合は、配備からクライアント JAR を取り出したり、JAR をクライアント JVM の CLASSPATH に追加したりする必要はありません。Application Server ネームサービスの使用時に静的 RMI-IIOP スタブは必要ないからです。これにより、以前のリリースで必要とされた手順は不要になります。詳しくは、「リモート EJB にアクセスするために RMI-IIOP スタブは必要ですか ?」を参照してください。

  3. 引数を必要としないデフォルトコンストラクタ InitialContext を使用するようにクライアントコードを記述します。次に例を示します。


    InitialContext ic = new InitialContext();

    クライアントから CosNaming サービスを明示的に参照するコーディングが強く推奨されるというのは、よくある誤解です。CosNaming は Application Server オブジェクトの一部の種類にのみ使用されるため、そのように記述しても、JMS キュー、接続ファクトリなどクライアントで必要となる可能性があるリソースの多くにアクセスできるようにはなりません。加えて、CosNaming を明示的に使用すると、Application Server のネームサービスコードの実行が省略されます。これにより、多くの場合、Application Server のネームサービスに組み込まれた便利で付加価値の高い処理をクライアントから利用できなくなります。

  4. 検索時には、ターゲットリソースのグローバル JNDI 名を使用します。java:comp/env をスタンドアロン Java クライアントから使用することはできません。そのようなクライアントは J2EE コンテナの外部で実行するように定義されているからです。java:comp/env を使用できるクライアントコンポーネントは、J2EE アプリケーションクライアントだけです。

  5. クライアントがサーバーインスタンスとは別のホストマシンで実行されている場合は、Java VM 起動時に次のシステムプロパティーを設定します。


    -Dorg.omg.CORBA.ORBInitialHost=hostname_of_target_server
    

    デフォルト値は localhost です。したがって、このプロパティーが必要なのは、クライアントとサーバーのインスタンスが共存していない場合だけです。次に例を示します。


    java -Dorg.omg.CORBA.ORBInitialHost=server1 ... com.foo.MyMainClass
  6. デフォルトでは、クライアントからサーバーのネームサービスを使用するためポート 3700 への接続が試行されます。3700 は Application Server で使用されるデフォルトのネームサービスポートなので、クライアントで追加のポート設定は必要ありません。ポートの衝突が原因で、サーバーインスタンスで別のネームサービスポートが使用される場合もあります。サーバーインスタンスで使用されるネームサービスポートは、domain.xml 内の <iiop-listener id="orb-listener-1" port="3700"\> 要素に示されます。

    クライアントで使用されるネームサービスポートを変更するには、クライアント Java VM 起動時に次のシステムプロパティーを設定します。


    -Dorg.omg.CORBA.ORBInitialPort=naming_port_of_target_server
    

リモート EJB にアクセスするために RMI-IIOP スタブは必要ですか ?

いいえ。以前のリリースの Application Server とは異なり、現在のバージョンは実行時に静的 RMI-IIOP スタブを必要としません。

この要件がなくなったことで、次のような利点が生じます。

アプリケーションロガーのログレベルを変更する方法を教えてください。

アプリケーションでは、それぞれ固有のアプリケーションロガーを使用してメッセージを記録しています。特定のアプリケーションのログレベルを設定するには、次の 2 つの方法のいずれかを使用します。