ここでは、Application Server に関してよく質問される事項について説明します。
アプリケーションが XML ファイル内で設定されているのに、サーバー側レルムが 1 つも設定されていない場合は、アプリケーションがデフォルトレルムで認証されます。「指定したレルムはありません。」というエラーはスローされません。
PKCS12 証明書を、相互認証時の SSL アプリケーションクライアントまたはスタンドアロンクライアントで使用する方法はありますか ?
いいえ。PKCS12 証明書を直接使用することはできません。ただし、JSSE を使用して独自のクライアントを記述することができ、その場合、storetype=PKCS12 (キーストアの読み取り専用、書き込みなし) がサポートされます。
はい。JVM 上で Java デバッグプロパティーを設定してください。アプリケーションクライアントからハンドシェーク情報を見るには、次の設定を付加します。
-Djavax.net.debug=ssl,handshake to the VMARGS variable.
はい。次の J2SE プロパティーを使用して、キーストアのパスワードを変更できます。
-Djavax.net.ssl.keyStorePassword=password -Djavax.net.ssl.trustStorePassword=password
キーに対する操作を実行するには、キーストアのパスワードが個々のキーのパスワードと一致する必要があることに注意してください。そのため、前述のプロパティーを使用してキーストアのパスワードを変更した後、そのパスワードと一致するように各キーへのパスワードを変更する必要があります。
JAX-RPC エンドポイントを持つセッションをクライアントで維持することはできません。セッションにはクライアント/サーバーの側面があるため、これを設定する明確な方法はありません。
考えられるのは、クライアントがサービスの呼び出しを行い、サーバーが応答して接続上に Cookie を設定するという方法です。それ以降、クライアントは呼び出しのたびにその同じ Cookie を送り返し、サーバーでそれをチェックすることが可能になります。
Cookie が送り返されても、通常、JAX-RPC スタブには影響を与えません。SESSION_MAINTAIN_PROPERTY を true に設定すると、サーバーでスタブに設定したすべての 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 VM 起動時の CLASSPATH に appserv-rt.jar を追加します。
JNDI ブートストラップ機構で、appserv-rt.jar にある jndi.properties という名前のファイルが検索されます。このファイルには、Application Server のネームサービスに関するすべてのブートストラッププロパティーが含まれています。これらのプロパティーは、クライアント起動スクリプトまたはアプリケーションコードに明示的に記述するよりも、appserv-rt.jar から読み取るようにすることをお勧めします。
スタンドアロンクライアントからリモート EJB にアクセスする場合は、配備からクライアント JAR を取り出したり、JAR をクライアント JVM の CLASSPATH に追加したりする必要はありません。Application Server ネームサービスの使用時に静的 RMI-IIOP スタブは必要ないからです。これにより、以前のリリースで必要とされた手順は不要になります。詳しくは、「リモート EJB にアクセスするために RMI-IIOP スタブは必要ですか ?」を参照してください。
引数を必要としないデフォルトコンストラクタ InitialContext を使用するようにクライアントコードを記述します。次に例を示します。
InitialContext ic = new InitialContext(); |
クライアントから CosNaming サービスを明示的に参照するコーディングが強く推奨されるというのは、よくある誤解です。CosNaming は Application Server オブジェクトの一部の種類にのみ使用されるため、そのように記述しても、JMS キュー、接続ファクトリなどクライアントで必要となる可能性があるリソースの多くにアクセスできるようにはなりません。加えて、CosNaming を明示的に使用すると、Application Server のネームサービスコードの実行が省略されます。これにより、多くの場合、Application Server のネームサービスに組み込まれた便利で付加価値の高い処理をクライアントから利用できなくなります。
検索時には、ターゲットリソースのグローバル JNDI 名を使用します。java:comp/env をスタンドアロン Java クライアントから使用することはできません。そのようなクライアントは J2EE コンテナの外部で実行するように定義されているからです。java:comp/env を使用できるクライアントコンポーネントは、J2EE アプリケーションクライアントだけです。
クライアントがサーバーインスタンスとは別のホストマシンで実行されている場合は、Java VM 起動時に次のシステムプロパティーを設定します。
-Dorg.omg.CORBA.ORBInitialHost=hostname_of_target_server |
デフォルト値は localhost です。したがって、このプロパティーが必要なのは、クライアントとサーバーのインスタンスが共存していない場合だけです。次に例を示します。
java -Dorg.omg.CORBA.ORBInitialHost=server1 ... com.foo.MyMainClass |
デフォルトでは、クライアントからサーバーのネームサービスを使用するためポート 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 |
いいえ。以前のリリースの Application Server とは異なり、現在のバージョンは実行時に静的 RMI-IIOP スタブを必要としません。
この要件がなくなったことで、次のような利点が生じます。
リモート EJB またはリモート EJB のクライアントを含むアプリケーションの配備および再配備時間の短縮
スタブ CLASSPATH 設定の問題が原因で発生する実行時エラーの減少
加えて Application Server では、RMI-IIOP 相互運用性を完全に維持しながら、実行時のパフォーマンスに大きな影響を与えることなくこれらの利点が実現します。
現在でも RMI-IIOP スタブが必要とされるシナリオは、スタンドアロンクライアントで CosNaming ネームサービス用に InitialContext を明示的にインスタンス化する場合だけです。これは、Application Server のネームサービスを使用するための推奨される手法ではありません。ただし、この種のスタンドアロンクライアントとの互換性を維持するため、RMI-IIOP スタブを以前のリリースと一致する方法で強制的に生成する配備時オプションが用意されています。これを使用するには、次のように設定します。
--generatermistubs=true
この設定は、asadmin または管理コンソールを使用して配備する際に行えます。RMI-IIOP スタブは、以前のリリースの場合と同様に client.jar ファイルに格納されます。
アプリケーションでは、それぞれ固有のアプリケーションロガーを使用してメッセージを記録しています。特定のアプリケーションのログレベルを設定するには、次の 2 つの方法のいずれかを使用します。
管理 GUI のログレベル設定ページで、ロガー名を表すプロパティー name、および FINEST、FINER、FINE、CONFIG、INFO、WARNING、SEVERE の 7 つのログレベルのいずれかまたは OFF を表すプロパティー value から成るプロパティーを追加します。
たとえば、com.X.Y という名前のアプリケーションロガーのログレベルを FINEST に変更するには、プロパティー name を com.X.Y に、プロパティー value を FINEST に設定します。変更は domain.xml ファイルに反映され、ただちに有効になります。サーバーの再起動は必要ありません。
次に示すように、domain.xml 内の <module-log-levels\> 要素にプロパティーを直接追加します。
<module-log-levels admin="INFO" classloader="INFO" cmp="INFO" cmp-container="INFO" configuration="INFO" connector="INFO" corba="INFO" deployment="INFO" ejb-container="INFO" javamail="INFO" jaxr="INFO" jaxrpc="INFO" jdo="INFO" jms="INFO" jta="INFO" jts="INFO" mdb-container="INFO" naming="INFO" node-agent="INFO" resource-adapter="INFO" root="INFO" saaj="INFO" security="INFO" server="INFO" synchronization="INFO" util="INFO" verifier="INFO" web-container="INFO"\> <property name="com.X.Y" value="FINEST" /\> </module-log-levels\>