Web コンテナ

5004315 

Windows で、--precompilejsp=true を使用してアプリケーションを配備すると、そのアプリケーションの JAR ファイルがロックされ、その後の配備取り消しや再配備が失敗することがある。

Windows にアプリケーションを配備するときに JSP のプリコンパイルを要求すると、それ以降、そのアプリケーションの配備取り消しや、そのアプリケーション (または同一モジュール ID を持つ任意のアプリケーション) の再配備を試みても、予期したとおりに動作しません。この問題は、JSP のプリコンパイル処理でアプリケーションの JAR ファイルが開かれたまま閉じられないため、Windows がこれらのファイルを配備取り消しで削除することや、これらのファイルを再配備で上書きすることを許可しないことにあります。 

配備取り消しは、Application Server からアプリケーションが論理的に削除されるという点では成功します。また、asadmin ユーティリティーからエラーメッセージは返されませんが、そのアプリケーションのディレクトリとロックされた jar ファイルはサーバー上に残っています。サーバーのログファイルには、ファイルとアプリケーションディレクトリの削除に失敗した旨のメッセージが出力されます。

配備取り消し後のアプリケーションの再配備が失敗するのは、既存のファイルとディレクトリをサーバーが削除しようとして失敗するからです。これは、最初に配備されたアプリケーションと同じモジュール ID を持つアプリケーションを配備しようとしたときにも発生します。アプリケーションのファイルを保持するディレクトリの名前を、サーバーはモジュール ID から決定するからです。 

同様の理由から、配備取り消しをせずにアプリケーションを再配備しようとすると失敗します。 

診断

アプリケーションを再配備しようとすると、または、配備取り消しを行なってから配備しようとすると、asadmin ユーティリティーは次のようなエラーを返します。 

An exception occurred while running the command. The exception 
message is: CLI171 Command deploy failed : Deploying application in 
domain failed; Cannot deploy. Module directory is locked and can't 
be deleted.

解決法

アプリケーションを配備するときに --precompilejsps=false (デフォルトの設定) を指定すると、この問題は発生しません。そのアプリケーションを最初に使用するときに JSP コンパイルが起動されるため、最初の要求に対する応答時間は、そのあとの要求に比べて長くなります。

また、プリコンパイルを行う場合には、そのアプリケーションを配備取り消しまたは再配備する前に、サーバーを終了して再起動する必要があります。シャットダウンすると、ロックされている JAR ファイルが解放されるため、再起動後の配備取り消しや再配備が成功します。 

6172006 

空の <load-on-startup> 要素を持つ Servlet 2.4 ベースの web.xml を含んだ WAR ファイルを配備できない。

web.xml のオプションの load-on-startup 要素は、サーブレットを宣言する Web アプリケーションの起動の一環として、そのサーブレットをロードおよび初期化すべきことを示します。

この要素のオプションの内容は、Web アプリケーションのその他のサーブレットとの関係で、そのサーブレットをロードおよび初期化する順序を示す整数です。空の <load-on-startup> は、そのサーブレットを含む Web アプリケーションの起動時にそのサーブレットがロードおよび初期化される場合、その順序は意味を持たないことを表します。

web.xml の Servlet 2.4 スキーマでは、空の <load-on-startup> はサポートされなくなりました。つまり、Servlet 2.4 ベースの web.xml を使用する場合は整数値を指定する必要があります。<load-on-startup/> の場合と同様に、空の <load-on-startup> を指定すると、web.xml が web.xml の Servlet 2.4 スキーマに対する妥当性検証に失敗するため、Web アプリケーションの配備も失敗します。

下位互換性の問題もあります。空の <load-on-startup> は、Servlet 2.3 ベースの web.xml では有効です。

解決法

Servlet 2.4 ベースの web.xml を使用する場合は、<load-on-startup>0</load-on-startup> を指定して、サーブレットの読み込み順序が問題にならないことを示します。

6184122 

リソースに制約のあるサーバー上で JSP ページをコンパイルできない。 

JSP ページにアクセスしてもコンパイルに失敗し、サーバーログには「Unable to execute command」というエラーメッセージと次のスタックトレースが記録されます。 

at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher. exec(Execut

e.java:655) at org.apache.tools.ant.taskdefs.Execute. launch(Execute.java:

416) at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:427) at

 org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter. executeEx

ternalCompile(DefaultCompilerAdapter.java:448) at org.apache.tools.ant.tas

kdefs.compilers.JavacExternal.execute (JavacExternal.java:81) at org.apach

e.tools.ant.taskdefs.Javac.compile(Javac.java:842) at org.apache.tools.ant

.taskdefs.Javac.execute(Javac.java:682) at org.apache.jasper.compiler.Comp

iler.generateClass(Compiler.java:396)

解決法

JSP のコンパイルスイッチを「fork」から「false」に設定します。 

これは、次のいずれかの方法で行えます。 

• グローバルに行うには、次のように、${S1AS_HOME}/domains/domain1/config/default-web.xml 内の JspServlet の fork init パラメータを false に設定します。

  <servlet> <servlet-name>jsp</servlet-name> <servlet-class>org.apache.jas per.servlet.JspServlet</servlet-class> .... <init-param> <param-name>fo rk</param-name> <param-value>false</param-value> </init-param> .... </se rvlet>

• Web アプリケーションごとに、sun-web.xml の JSP 設定プロパティー fork を false に設定します。次のようにします。

  <sun-web-app> <jsp-config> <property name="fork" value="false" /> </jsp- config> </sun-web-app>

これらのいずれかを設定することにより、ant が javac コンパイルのための新規プロセスを生成することが防止されます。 

6188932 

Application Server で、auth-passthrough Web Server 6.1 アドオンがサポートされない。

Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Update 2 では、Sun Java System Application Server Enterprise Edition 7.1 で使用できる auth-passthrough プラグイン関数が提供する機能に対するサポートが追加されています。ただし、Application Server Enterprise Edition 8.1 2005Q2 Update 2 での auth-passthrough プラグイン機能の設定方法は異なります。

Application Server Enterprise Edition 7.1 での auth-passthrough プラグイン関数は、次に示す 2 層配備のシナリオで有効でした。

• Application Server インスタンスは、企業ファイアウォールの内側にある 2 番目のファイアウォールによって保護される。

• Application Server インスタンスへの直接のクライアント接続は許可されない。

このようなネットワークアーキテクチャーの場合、クライアントは、service-passthrough プラグイン関数で設定されたフロントエンド Web サーバーに接続し、HTTP 要求を、プロキシされた Application Server インスタンスに転送して処理します。Application Server インスタンスは、要求をクライアントホストから直接にではなく、Web サーバープロキシからしか受信できません。その結果、プロキシされた Application Server インスタンス上に配備され、クライアントの IP アドレスなどのクライアント情報を照会する任意のアプリケーションは、中継された要求の実際の発信元ホストであるプロキシホストの IP を受信します。

Application Server Enterprise Edition 7.1 では、プロキシされた Application Server インスタンス上で、そのインスタンス上に配備された任意のアプリケーションがリモートクライアントの情報を直接使用するように auth-passthrough プラグイン関数を設定できました。その場合は、プロキシされた Application Server インスタンスが、service-passthrough プラグインを実行している中間の Web サーバー経由ではなく、要求を直接受信したかのように見えます。

Application Server Enterprise Edition 8.1 2005Q2 Update 2 では、domain.xml 内の <http-service> 要素の authPassthroughEnabled プロパティーを TRUE に設定することにより、auth-passthrough 機能を有効にすることができます。次に例を示します。

<property name="authPassthroughEnabled" value="true"/>

Application Server Enterprise Edition 7.1 にある auth-passthrough プラグイン関数のセキュリティーに関する同じ注意点が、Application Server Enterprise Edition 8.1 2005Q2 Update 2 にある authPassthroughEnabled プロパティーにも適用されます。authPassthroughEnabled によって、認証目的に使用される可能性のある情報 (要求発信元の IP アドレスや SSL クライアント証明書など) を上書きすることが可能になるため、authPassthroughEnabled を TRUE に設定して Application Server Enterprise Edition 8.1 2005Q2 Update 2 インスタンスへの接続を許可する場合は、その対象を信頼できるクライアントまたはサーバーだけに限定することがきわめて重要です。予防措置として、authPassthroughEnabled を TRUE に設定するのは、企業ファイアウォールの内側にあるサーバーだけにすることをお勧めします。インターネット経由でアクセス可能なサーバーでは、決して authPassthroughEnabled を TRUE に設定しないでください。

プロキシ Web サーバーが service-passthrough プラグインを使用して設定されており、要求を authPassthroughEnabled が TRUE に設定された Application Server 8.1 Update 2 インスタンスに転送するシナリオでは、SSL クライアント認証は Web サーバープロキシ上で有効になり、プロキシされた Application Server 8.1 Update 2 インスタンス上で無効になる可能性があることに注意してください。この場合、プロキシされた Application Server 8.1 Update 2 インスタンスは、SSL 経由で認証されたかのように引き続き要求を処理し、クライアントの SSL 証明書を、それを要求している任意の配備されたアプリケーションに提供します。