6171458 

domain1 がない場合に package-appclient スクリプトが機能しない。

デフォルトでは、$INSTALL/lib/package-appclient.xml に、asenv.conf によってポイントされる domain1 の AS_ACC_CONFIG 変数用にハードコードされた値があります。domain1 を削除して新たなドメインを作成した場合、AS_ACC_CONFIG 変数は新たなドメイン名で更新されません。その結果、package-appclient スクリプトの処理が失敗します。

解決法

次のいずれかを行います。 

1. domain1 はそのままにしておき、その前後に別のドメインを作成します。

2. domain1 を削除し、$INSTALL/lib/package-appclient.xml で domain1 用にハードコードされた値を、新たなドメイン名で置き換えます。

domain1 がない場合、新たなドメインが作成されるたびにこれを行う必要があります。

6196993 

バックアップ取得したドメインを別の名前で復元できない。 

同一の Application Server 上でのドメインのミラー化は、backup-domain および restore-domain コマンドでは行えません。asadmin restore-domain コマンドにはドメインをリネームするオプションがありますが、元の名前とは違う名前でドメインを復元することはできないからです。バックアップ取得したドメインのリネームは正常に行われたように見えますが、そのリネームされたドメインの起動は失敗します。ドメイン設定のエントリは変更されておらず、startserv および stopserv は元のドメイン名を使用してパスを設定するからです。

解決法

restore-domain で使用するドメイン名は、元の backup-domain コマンドで使用したドメイン名と同じである必要があります。Application Server 8.1 での backup-domain および restore-domain コマンドは、同一マシン上の同一ドメインのバックアップおよび復元についてだけ有効です。

6200011 

JMX エージェントを伴う Application Server の起動がサポートされていない。 

Application Server では、J2SE 1.4.x または 5.0 以降を設定できます。J2SE 5.0 プラットフォームの重要な特徴は、JMX エージェントを起動できることです。サーバーの起動時にシステムプロパティーを明示的に設定すると、JMX エージェントがアクティブになります。 

次に例を示します。 

name="com.sun.management.jmxremote" value="true"
name="com.sun.management.jmxremote.port" value="9999"
name="com.sun.management.jmxremote.authenticate" value="false"
name="com.sun.management.jmxremote.ssl" value="false"

JMX プロパティーを設定してからサーバーを起動すると、Application Server VM 内に新たな jmx-connector サーバーが起動します。この場合は、望ましくない副作用の 1 つとして、管理機能が悪影響を受け、Application Server の管理コンソールやコマンド行インタフェースで予期しない結果が発生することがあります。問題は、組み込みの jmx-connector サーバーと新たな jmx-connector サーバーとの間で衝突が発生することにあります。

解決法

jconsole または何らかの JMX 互換クライアントを使用する場合には、Application Server とともに起動する標準の JMX コネクタサーバーを再利用することを検討してください。

サーバーの起動時に、次に示すような行が server.log に作成されます。ここで指定されている JMXService の URL に接続し、資格を正常に指定したあと、同様の管理および設定操作を実行することができます。次に例を示します。

[#|2004-11-24T17:49:08.203-0800|INFO|sun-appserver-ee8.1| javax.enterpris

e.system.tools.admin|_ThreadID=10;|ADM1501: Here is the JMXServiceURL for

 the JMXConnectorServer: [service:jmx:rmi:///jndi/rmi://hostname:8686/man

agement/ rmi-jmx-connector]. This is where the remote administrative clie

nts should connect using the JSR 160 JMX Connectors.|#]

詳細は、『管理ガイド』を参照してください。

6206176 

UNIX で、Application Server の start および stop スクリプトに関する実行権に過度の制限がかけられている。 

ユーザー「A」としてログインして asadmin restore-domain コマンドを実行すると、そのスクリプトのアクセス権は 744 (rwxr--r--) になります。そのあとでユーザー「B」としてドメインを起動または停止しようとすると、たとえ「B」が root であっても、その試みは失敗します。ユーザー「A」についてだけスクリプトが実行可能だからです。

解決法

スクリプトのアクセス権を次のようにして変更します。 

chmod 755 appserv/domains/domain-name/bin/*

6236544、6275436 

どの Web サービスのエンドポイント URL を使用しても、ロードバランサの設定ファイルが作成されない。 

Web サービスの URL をエクスポートする EJB モジュールを含むアプリケーションを使用してロードバランサを設定しても、作成された loadbalancer.xml ファイルに、その Web サービスのコンテキストルートが存在しません。

解決法

1. loadbalancer.xml ファイルを編集して、作成されなかった Web モジュールを次のように追加します。

   <web-module context-root="context-root-name" disable-timeout-in-minutes="30" enabled="true"/>

2. context-root-name 値を、EJB として公開された Web サービスのコンテキストルート名に置き換えます。

6288893 

sun-appserv-admin を使用して Application Server を再起動すると、LoginException エラーが発生する。

解決法

1. 既存の <as_install>/bin/asant スクリプトの名前を asant.bak に変更します。

2. <as_install>/lib/install/templates/ee (SE/EE バージョンの場合) にある asant.template ファイルを <as_install>/bin/ ディレクトリにコピーし、このファイルの名前を asant に変更します。

3. 新しくコピーされた <as_install>/bin/asant スクリプトを編集して、%CONFIG_HOME% トークンを <as_install>/config に置き換えます。

4. 元の asant.bak ファイルに対して行なった手作業の変更がある場合は、それを新しい asant スクリプトに結合します。

6315957 

Application Server のマニュアルに .asadmintruststore ファイルが記述されていません。このファイルがサーバー管理者の home ディレクトリに存在しないと、そのサーバー上にホストされている特定のアプリケーションをアップグレードしたときに重大なバグが発生する場合があります。

解決法

• 可能であれば、そのサーバーをインストールしたユーザーが asadmin start-domain domain1 コマンドを実行してください。

• そのユーザーがこのコマンドを実行できない場合は、.asadmintruststore を、インストールしたユーザーの home ディレクトリから実行中のユーザーの home ディレクトリに移動またはコピーしてください。

• このファイルをインストールユーザーの home ディレクトリから実行中のユーザーの home ディレクトリに (コピーではなく) 移動した場合は、アップグレードまたはインストールしたユーザーのホームディレクトリ (Java ES では、通常 root) に .asadminstruststore ファイルが存在しなくなるため、バグ 6309079、6310428、および 6312869 で説明されているようなアプリケーションのアップグレードに関する問題が発生する可能性があることに注意してください。

6407140 

start-node-agent で開始したサーバーインスタンスは同期された最新の内容が含まれません。

asadmin start-node-agent コマンドを使用すると、DAS と同期化せずに、リモートサーバーインスタンスが自動的に起動します。

解決法

DAS によって管理されている中央リポジトリと同期化しているリモートサーバーインスタンスを起動する場合は、asadmin start-node-agent コマンドで --startinstances=false オプションを指定します。次に、asadmin start-instance コマンドを使用してリモートサーバーインスタンスを起動します。

6654726 

暗号化方式群を選択する管理コンソール機能が正常に機能しません。 HTTP リスナーの「サポートされるすべての暗号化方式群」を選択すると、その他チェックボックスは無効になるが、ページを更新すると再び有効 になります (「サポートされるすべての暗号化方式群」ボックスが選択されているにもかかわらず) 一見問題に見えるかもしれませんが、証明書のニックネームを入力し「保存」をクリックした後、変更内容が設定に書き込まれます。 

解決方法:

対処の必要はありません。変更内容は保存されています。 

6306784 

『高可用性 (HA) 管理ガイド』に、Apache で openssl を使用する場合の誤った手順が記載されている。

解決法

openssl のコンパイルと作成を行う場合は、次のコマンドを実行します。

cd openssl-0.9.7e

config

make

また、Apache 1.3 では、mod_ssl ソースのディレクトリ名も、使用している Apache のリリースに応じて変わります。たとえば、Apache 1.3.33 の場合、この名前は mod_ssl-2.8.22-1.3.33 になります。

6307976 

『高可用性 (HA) 管理ガイド』に、Apache 2.0 で証明書を使用するための手順が記載されていない。 

解決法

Apache のセキュリティーを実行するには、証明書を使用する必要があります。認証局から証明書を取得するための手順については、modssl FAQ にある証明書に関する情報を参照してください。

6308021 

Apache Web Server をルートとして起動する必要がある。 

解決法

Solaris では、Application Server がルートの下にインストールされている場合、Apache Web Server をルートとして起動する必要があります。Java Enterprise System は、ルートとしてインストールされます。Apache 2.0 の場合、ルートとして起動されたあと、Apache はユーザーが指定した別のユーザーに切り替えて動作します。そのユーザーは、/conf/httpd.conf ファイルで指定します。多くのシステムでは、ルートとして起動するには、httpd.conf ファイルを編集して正しいグループを指定する必要があります。次の行を

Group #-1

次の行に置き換えます。 

Group nobody

ユーザーおよびグループの使用に関する詳細情報は、httpd.conf ファイルに記載されています。

6308043 

Solaris で Apache Web Server 2.0 とともに openssl を使用するための手順への追加。

Apache 2.0 とロードバランサプラグインをインストールした後、ssl.conf と sll-std.conf を次のように編集します。

次の行を 

<VirtualHost _default_:9191>

次の行に置き換えます。 

<VirtualHost machine_name:9191>

ここで machine_name はマシンの名前であり、9191 はセキュリティーポート番号です。

6193556 

アプリケーションクライアントアーカイブのライブラリ JAR が MANIFEST ファイルを上書きする。 

クライアント JAR (たとえば reporter.jar) 内に最上位レベルの JAR ファイルがある場合、クライアント JAR を配備すると、その JAR の MANIFEST ファイルがクライアント JAR の MANIFEST ファイルを上書きします。 

解決法

現時点ではありません。 

6373043 

CGI-bin や SHTML などの動的コンテンツ技術はサポートされなくなりました。 

解決法

JSP および Web サービス技術を代わりに使用します。 

6165970 

TRANSACTION_SERIALIZABLE 遮断レベルを Microsoft SQL Server 向けの付属の Sun ドライバとともに使用するアプリケーションは、2 つの並行トランザクションが実行されていて、その 1 つがロールバックされた場合、準備されているステートメントを使用して更新するときにハングアップすることがある。

希望の遮断レベルを接続に対して設定するには、対応する接続プールをその遮断レベルで作成する必要があります。接続プールの設定の詳細は、『管理ガイド』を参照してください。 

解決法

現時点ではありません。 

6170432 

PreparedStatement エラーが発生する。

説明 #1

1 つのトランザクションで 3000 を超える PreparedStatement オブジェクトを生成する場合、DB2 では次のエラーが発生する可能性があります。

[sunm][DB2 JDBC Driver] No more available statements. Please recreate your package with a larger dynamicSections value.

解決法 #1

次のプロパティーを接続プール定義に追加して、ドライバが DB2 パッケージをより大きな動的セクション値に再バインドするようにします。 

createDefaultPackage=true replacePackage=true dynamicSections=1000

接続プールの設定の詳細は、『管理ガイド』を参照してください。

説明 #2

前述の PrepardStatement エラーに関連して、次のエラーメッセージがスローされることがあります。

[sunm][DB2 JDBC Driver][DB2]Virtual storage or database resource is not available.

解決法 #2

DB2 サーバー設定パラメータ APPLHEAPSZ の値を増やします。適度な値は 4096 です。

説明 #3

遮断レベル TRANSACTION_SERIALIZABLE。アプリケーションが遮断レベル TRANSACTION_SERIALIZABLE を採用し、前述したパラメータの 1 つを使用している場合、そのアプリケーションは接続を取得するときにハングアップすることがあります。

解決法 #3

希望の遮断レベルを接続に対して設定するには、対応する接続プールをその遮断レベルで作成する必要があります。その手順については、『管理ガイド』を参照してください。

6189199 

Sybase Adaptive Server 用の付属の Sun ドライバでの遮断レベルの設定にかかわる問題。 

• TRANSACTION_SERIALIZABLE 遮断レベルを Sybase Adaptive Server 向けの付属の Sun ドライバとともに使用するアプリケーションは、2 つの並行トランザクションが実行されていて、その 1 つがロールバックされた場合、準備されているステートメントを使用して更新するときにハングアップすることがあります。接続ロールバックは次のメッセージとともに失敗し、ロールバックされた接続はそれ以降は使用できません。

  java.sql.SQLException:[sunm][Sybase JDBC Driver]Request cannot be submitted due to wire contention

• Sybase Adaptive Server は TRANSACTION_REPEATABLE_READ 遮断レベルをサポートしません。ただし、DatabaseMetaData をクエリーすると、付属の Sun ドライバは、この遮断レベルがこのデータベースによってサポートされていると返答します。この遮断レベルを使用するアプリケーションは処理に失敗します。

• 付属の Sun ドライバを使用するアプリケーションは、TRANSACTION_READ_UNCOMMITTED 遮断レベルを設定できません。DataBaseMetaData に対する最初のアクセスの時点で、アプリケーションは次の例外をスローします。

  java.sql.SQLException:[sunm][Sybase JDBC Driver][Sybase]The optimizer could not find a unique index which it could use to perform an isolation level 0 scan on table 'sybsystemprocs.dbo.spt_server_info'.

解決法

現時点ではありません。 

6247468 

Solaris 10 および Enterprise Linux 3.0 で、Sun に付属している Oracle JDBC ドライバでは接続を作成できない。 

解決法

Sun JDBC Oracle データソース (com.sun.sql.jdbcx.oracle.OracleDataSource) を使用する場合は、JDBC 接続プールに次のプロパティーを設定します。

<property name="serverType" value="dedicated"/>

このプロパティーの値は、Oracle サーバーのリスナーの設定方法によって異なります。「共有」モードで設定した場合は、上の値を「dedicated」に変更する必要があります。 

6554602 

JDBC 10.2 ドライバを使用して開始するとき、CLASSPATH に複数の JDBC jar ファイルが含まれる場合に java.lang.SecurityException: Sealing violation exception が発生する可能性があります。

Oracle が提供している詳細な説明については、次の Oracle マニュアル ID を参照してください。 

注: 405446
Subject: JDBC Driver 10.2 はシールされた JAR ファイルを使用しており、セキュリティー例外シーリング違反が発生する可能性があります。

解決法

(Oracle 推奨) CLASSPATH には JDBC ドライバ JAR ファイルが 1 つだけ含まれるようにしてください。

6188343 

DAS インスタンスを再起動したあと、cascade が false に設定されている場合にコネクタモジュールの配備取り消しが失敗する。 

このシナリオでは、スタンドアロンまたは埋め込みのコネクタモジュールが DAS とコネクタ接続プールに配備され、その配備済みモジュール用にリソースが作成されます。DAS インスタンスを再起動したあと、cascade が false に設定されている場合にコネクタモジュールの配備取り消しが次の例外で失敗します。 

[#|2004-10-31T19:52:23.049-0800|INFO|sun-appserver-ee8.1|javax.enterprise.system .core|_ThreadID=14;|CORE5023:Error while unloading application [foo]|#]

解決法

DAS インスタンスを再起動したあとは、スタンドアロンまたは埋め込みのコネクタの配備を取り消すために、カスケード式配備取り消しを使用 (cascade オプションを true に設定) します。 

さまざまな ID 

Javadoc に不整合がある。 

いくつかの AMX インタフェースおよびメソッドについて、Javadoc が欠けているか間違っています。 

• NumConnAcquired および NumConnReleased 統計情報の取得メソッドが ConnectorConnectionPoolStats および AltJDBCConnectionPoolStats から抜けている。これらの取得メソッドは、将来のリリースで getNumConnAcquired() および getNumConnReleased() として追加される予定。

• EJBCacheStats 内でメソッド getPassivationSuccesses()、getExpiredSessionsRemoved()、getPassivationErrors()、getPassivations() を呼び出すと、例外がスローされる。これは将来のリリースで解決される予定。

• サーバーを起動したあと、すべての AMX MBeans が登録されて利用できるようになるまでに数秒を要することがある。将来のリリースでは、AMX MBeans が完全にロードされたことを確認できるようになる予定。

• 定数 XTypes.CONNNECTOR_CONNECTION_POOL_MONITOR のスペルが間違っている ("NNN" の部分)。これは将来のリリースで訂正される予定。

6265624 

付属の ANT によって java.lang.NoClassDefFoundError がスローされる。

スレッド「main」で java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher の例外がスローされます。

解決法

付属の ANT を Application Server の外部で使用することはお勧めできません。 

6486123 

ラップ接続からの物理接続の取得に関するマニュアルが正しくなくなった。 

他のバグ (6295215 など) の結果 『Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide』の第 11 章「Using the JDBC API for Database Access」の『Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide』の「Obtaining a Physical Connection from a Wrapped Connection」の節で示されているコードは正しくなくなっています。特に次の行は

Connection drivercon = ds.getConnection(con);

次の行に読み替えてください。 

Connection drivercon = ((com.sun.gjc.spi.DataSource)ds).getConnection(con);

ID なし 

ダブルネットワークでの HADB 設定。 

2 つのサブネット上にダブルネットワークで設定された HADB は、Solaris SPARC 上では正常に動作します。しかし、一部のハードウェアプラットフォームでのオペレーティングシステムまたはネットワークドライバの問題が原因で、Solaris x86 および Linux プラットフォームではダブルネットワークを適切に処理できない場合があります。これにより、HADB について次の問題が発生します。 

• Linux では、メッセージ送信の際に HADB プロセスがブロックされることがある。これにより、HADB ノードが再起動し、ネットワークパーティションが発生する。

• Solaris x86 では、ネットワーク障害が発生した場合、もう一方のネットワークインタフェースへの切り替えを妨げる問題が発生することがある。この問題は常に発生するとは限らないため、ネットワークが 1 つしかないよりも 2 つあった方が安全である。この問題は、Solaris 10 で部分的に解決されている。

• トランキングがサポートされない。

• Windows 2003 では、HADB はダブルネットワークをサポートしていない (ID 5103186)。

ID なし 

HADB データベースの作成が失敗する。 

新しいデータベースを作成すると、使用可能な共有メモリーセグメントが少なすぎるという、次のエラーで失敗することがあります。 

HADB-E-21054:System resource is unavailable:HADB-S-05512:Attaching shared memory segment with key "xxxxx" failed, OS status=24 OS error message:Too many open files.

解決法

共有メモリーが設定されており、その設定が機能していることを確認します。特に、Solaris 8 では、/etc/system ファイルを調べて、変数 shmsys:shminfo_shmseg の値がホストあたりのノード数の 6 倍以上になっていることを確認します。

5052548 

共有メモリーセグメントがロックされ、ページアウトできません。 

HADB 4.3-0.16 以降は、共有メモリーセグメントを作成してそれに接続するときに Intimate Shared Memory を使用するように設定されています (SHM_SHARE_MMU フラグを使用)。このフラグを使用すると、必然的に共有メモリーセグメントが物理メモリーにロックされ、ページアウトできなくなります。このため、ローエンドマシンへのインストールでは、問題が発生する可能性が高くなっています。

したがって、Application Server 7.0 EE の使用時に開発者のマシンで 512M バイトのメモリーと十分なスワップ空間が利用でき、その後 7.1 EE 以降をインストールした場合、デフォルトの clsetup クラスタを設定するときに問題が発生します。このクラスタでは 2 つの HADB ノードが作成されて、それぞれの devicesize は 512 になり、両方のノードに必要な共有メモリーをサポートするのに十分な物理 RAM がないことになります。

解決法

Application Server と HADB を共存させるときは、推奨されている容量のメモリーを使用するようにしてください。詳細については、「HADB の要件とサポートされているプラットフォーム」を参照してください。

5091280 

リソース (ディスクおよびメモリースペース) が利用可能かどうかを hadbm set がチェックしない。

hadbm set を使用してデバイスまたはバッファーのサイズを増やす場合、管理システムは、データベースの作成やノードの追加の際にはリソースが利用可能かどうかをチェックしますが、デバイスまたはメインメモリーのバッファーサイズを変更するときには利用可能なリソースが十分にあるかどうかをチェックしません。

解決法

設定属性 devicesize または buffersize を増やす前に、すべてのホスト上にディスクおよびメモリーの空きスペースが十分にあることを確認してください。

5091349 

packagepath の混在パスがサポートされない。

同一のソフトウェアパッケージを、同じ名前で別のホストの別の位置で登録することはできません。次に例を示します。 

hadbm registerpackage test --packagepath=/var/install1 --hosts europa11
Package successfully registered.
hadbm registerpackage test --packagepath=/var/install2 --hosts europa12
hadbm:Error 22171: A software package has already been registered with 
the package name test.

解決法

HADB は、データベースクラスタ内のノードをまたがる混在パスをサポートしません。HADB サーバーのインストールディレクトリ (---packagepath) は、すべての参加ホストについて同一にしてください。

6173886、6253132 

createdomain が失敗することがある。

複数のネットワークインタフェースを備えたホスト上で管理エージェントを実行している場合に、すべてのネットワークインタフェースが同じサブネット上に存在しないと、createdomain コマンドが失敗することがあります。 

hadbm:Error 22020: The management agents could not establish a 
domain, please check that the hosts can communicate with UDP multicast.

管理エージェントは、特に設定されていないかぎり、UDP マルチキャスト用の「最初の」インタフェース (この「最初」は、java.net.NetworkInterface.getNetworkInterfaces() の結果によって定義される) を使用します。

解決法

もっとも良い解決法は、使用するサブネットを管理エージェントに通知することです。たとえば、設定ファイル内の ma.server.mainternal.interfaces を ma.server.mainternal.interfaces=10.11.100.0 に設定します。あるいは、サブネット間のルーターを、マルチキャストパケットをルーティングするように設定することもできます。このとき、管理エージェントはマルチキャストアドレス 228.8.8.8 を使用します。

管理エージェントの新しい設定を再試行する前に、管理エージェントリポジトリのクリーンアップが必要になる場合があります。ドメイン内のすべてのエージェントを停止し、リポジトリディレクトリ (管理エージェント設定ファイル内の repository.dr.path で識別される) 内のすべてのファイルとディレクトリを削除します。この操作は、新しい設定ファイルを使用してエージェントを再起動する前に、すべてのホスト上で実行する必要があります。

6190878 

HADB インスタンスの削除後にディレクトリをクリーンアップする必要があります。 

HADB インスタンスの削除に続いて configure-ha-cluster コマンドで新しいインスタンスを作成しようとすると、失敗します。問題は、元の HADB インスタンスの古いディレクトリが ha_install_dir/rep/* と ha_install_dir/config/hadb/instance_name に残ることにあります。

解決法

HADB インスタンスの削除後に、手動でこれらのディレクトリを削除するようにしてください。 

6230792、6230415 

HADB の起動、停止、および再設定が失敗またはハングアップすることがある。 

Solaris 10 Opteron では、hadbm コマンドを使用して HADB を起動、停止、または再設定すると、次のいずれかのエラーで失敗またはハングアップする場合があります。

hadbm:Error 22009: The command issued had no progress in the last 
300 seconds.
HADB-E-21070: The operation did not complete within the time limit, 
but has not been cancelled and may complete at a later time.

このエラーは、clu_noman_srv プロセスが使用するファイル (nomandevice) への読み取り/書き込みに不整合があった場合に発生することがあります。この問題は、HADB 履歴ファイルで次のメッセージを検索することにより検出できます。

n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 
does not respond.
n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Have not heard from it in 
104.537454 sec.
n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 
did not start.

解決法

問題を手動で再現できていないため、次の回避策はまだ検証されていません。ただし、影響を受けるノードに対してこのコマンドを実行すれば、問題は解決されます。 

hadbm restartnode --level=clear nodeno dbname

ノードのすべてのデバイスが再初期化されるわけではないことに注意してください。再初期化する前に、ノードの停止が必要になる場合があります。 

6232140 

管理エージェントが、例外「IPV6_MULTICAST_IF failed」で終了する。

複数の NIC カードが実装された、Solaris 8 を実行しているホスト上で起動されている場合、IPv6 と IPv4 が有効になったカードが混在していると、管理エージェントが例外「IPV6_MULTICAST_IF failed」で終了することがあります。

解決法

環境変数 JAVA_OPTIONS を -Djava.net.preferIPv4Stack=true に設定します。次に例を示します。

export JAVA_OPTIONS="-Djava.net.preferIPv4Stack=true"

あるいは、この問題が発生しない Solaris 9 以降を使用します。 

6249685 

clu_trans_srv を中断できない。

Red Hat Enterprise Linux 3.0 の 64 ビットバージョンには、非同期入出力の実行中に clu_trans_srv プロセスを中断不可能なモードに陥らせるバグが存在します。つまり、kill -9 が機能せず、オペレーティングシステムの再起動が必要になります。

解決法

Red Hat Enterprise Linux 3.0 の 32 ビットバージョンを使用します。 

6262824 

hadbm が大文字を含むパスワードをサポートしていない。

パスワードが hadb に格納されるときに、パスワード内の大文字は小文字に変換されます。

解決法

大文字を含むパスワードは使用しないでください。 

6265419 

HADB Version 4.4.2.5 から HADB Version 4.4.1.7 にダウングレードすると、ma が各種のエラーコードで失敗する。 

以前の HADB バージョンにダウングレードすると、管理エージェントが各種のエラーコードで失敗する場合があります。 

解決法

HADB データベースのダウングレードは可能ですが、リポジトリオブジェクトが変更されている場合は管理エージェントをダウングレードできません。ダウングレードのあとも、最新の HADB バージョンの管理エージェントを使用し続ける必要があります。 

6271063 

インストールまたは削除を行なっても、symlink が保持される。

HADB c パッケージ (Solaris: SUNWhadbc、Linux: sun-hadb-c) バージョン <m.n.u-p> のインストールまたは削除に関しては、symlink /opt/SUNWhadb/<m> はいったん作成されると、その後は何も手を加えられません。そのため、切り離された symlink が存在することがあり得ます。

解決法

使用中の場合を除き、インストールの前またはアンインストールのあとに symlink を削除します。

6273681 

大域ゾーンとローカルゾーンの管理エージェントが干渉することがある。 

Solaris 10 では、大域ゾーンで ma-initd スクリプトを使用して管理エージェントを停止すると、ローカルゾーンの管理エージェントも停止されます。 

解決法

管理エージェントを大域ゾーンとローカルゾーンの両方にインストールしないでください。 

6275103 

セッションオブジェクトがタイムアウトし、MA で削除されたとき、hadbm/ma はより適切なエラーメッセージを出力するべきである。

場合によっては、サーバー上のリソース競合の問題によって管理クライアントが切断されることがあります。再接続時、「hadbm:Error 22184:A password is required to connect to the management agent」という紛らわしいエラーメッセージが返されることがあります。

解決法

サーバー上にリソースに関する問題があるかどうかを確認し、適切な処置 (たとえば、リソースの追加) を取ってから、操作を再試行します。 

6275319 

ルート以外のユーザーが HADB を管理できない。 

Java Enterprise System を使用して (ルートとして) インストールすると、ルート以外のユーザーは HADB を管理できなくなります。 

解決法

HADB を管理するには、常にルートとしてログインします。 

6293912 

管理エージェントは特殊用途のインタフェースを使用するべきではない。 

0.0.0.0 のような IP アドレスを含む特殊用途のインタフェースを、管理エージェント内の HADB ノードが使用する有効なインタフェースとして登録するべきではありません。このようなインタフェースを登録すると、IP アドレスの代わりにホスト名を使用して hadbm create コマンドを発行するユーザーによってこのインタフェース上に HADB ノードが設定された場合に、問題が発生する場合があります。その場合、これらのノードは通信できなくなり、create コマンドはハングアップします。

解決法

複数のインタフェースを備えたホスト上で hadbm create を使用する場合は、DDN 形式を使用して IP アドレスを常に明示的に指定します。

6291562 

Windows 上で再構築が失敗する。 

Windows プラットフォームでは、特定の設定および負荷の下で、オペレーティングシステム内で多数の再構築の失敗が発生する場合があります。この問題は、20 を超えるノードが設定されている状況で、複数のテーブルスキャン (select *) を並列に実行している場合に発生しています。症状としては、トランザクションが頻繁に中止され、修復またはリカバリの完了に長い時間がかかるため、システムのさまざまな部分で頻繁なタイムアウトが発生していることが考えられます。

解決法

この問題を修正するには、Windows レジストリ変数 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters をデフォルトの 100 より大きい値に設定します。この値を 0x1000 (4096) に増やすことをお勧めします。詳細は、Microsoft サポートページの記事 811003 を参照してください。

6303581、6346059、6307497 

hadbm start <db_name> を実行すると、入力したパ スワードの一部がマスクされずに表示されます。

マシンに負荷がかかっていると、マスキング機構が機能せず、入力したパスワードの一部の文字が表示されることがあります。これは軽度のセキュリティー上のリスクの原因となるので、パスワードは常にマスクすべきです。 

解決法

パスワードを独自のパスワードファイルに入れて (通常 Application Server 8.1 以降推奨されている方法)、--adminpassword または --dbpasswordfile オプションでこれらのファイルを参照します。

5009728 

一部の Linux システムで、「完了」ボタンをクリックしたあとにインストールの終了でハングアップする。 

この問題は、いくつかの Linux システム上で発生していました。これは Java Desktop System 2 でもっとも一般的に見られますが、Linux Red Hat ディストリビューションでも見られます。 

インストールプログラムの最後の画面で「完了」ボタンをクリックすると、インストールプログラムは製品の「バージョン情報」ページまたは製品登録ページを表示するブラウザウィンドウの起動に失敗し、コマンドプロンプトに戻ることなくハングアップします。 

解決法

インストールプログラムを起動した端末ウィンドウで Ctrl+C を押すことにより、インストールプログラムを終了します。そのあとで、製品の「バージョン情報」ページまたは登録ページを表示するブラウザウィンドウが起動することがあります。ブラウザウィンドウが現れない場合には、ブラウザを起動してから次の URL を入力して「バージョン情報」ページを確認してください。

file://install_dir/docs-ee/about.html

製品を登録するインストールオプションを選択した場合には、「バージョン情報」ページ上の登録ページへのリンクをたどってください。 

6199697 

Windows では、インストール中に imq ディレクトリを作成する必要がある。 

Windows では、Application Server Enterprise Edition をインストールした直後に、ディレクトリ drive:\as\domains\domain1\imq が存在しない旨のメッセージを出力して Message Queue ブローカが起動に失敗します。

domain1 を起動してからブローカを起動した場合には、Application Server によってディレクトリが作成され、この問題は発生しません。

解決法

1. ブローカを作成する前に var_home_dir_location を作成します。次のようにします。

   $imqbrokerd -varhome var_home_dir_location

   例:

   $imqbrokerd -varhome D:\as\domains\domain1\imq

6297837 

Application Server インストーラが、製品名「Sun Java(TM) System Application Server Enterprise Edition 8.1 2005Q4」の中に間違った製品リリース日を表示している。 

解決法

正しい製品名と日付は、「Sun Java(TM) System Application Server Enterprise Edition 8.1 2005Q2」となるべきです。 

6396045 

Application Server はネットワークファイルシステム (NFS) をサポートしていません。 

解決法

なし。 

6193449 

ejb-timer-service プロパティーの minimum-delivery-interval を 9000 に設定した後で ejb-timer-service プロパティーの redelivery-interval-in-mills を 7000 に設定しようとすると、次のエラーで set コマンドが失敗する。

[echo] Doing admin task set
[exec] [Attribute(id=redelivery-interval-internal-in-millis) : 
Redelivery-Interval (7,000) 
should be greater than or equal to Minimum-delivery-interval-
in-millis (9,000)]
[exec] CLI137 Command set failed.

• minimum-delivery-interval は、同一の周期タイマーの最小発生間隔。

• redelivery-interval-in-mills は、失敗した ejbTimeout のあとに再発生を試みるまでタイマーサービスが待機する時間。

これは、再発生間隔のプロパティーを最小発生間隔のプロパティーと関連付けるロジックが間違っていて、GUI または CLI を使用して再発生間隔よりも最小発生間隔が大きくなるような値を設定できないという問題です。 

minimum-delivery-interval-in-millis を、ejb-timer-service プロパティーの redelivery-interval-in-millis 以上の値に設定する必要があります。redelivery-interval-in-millis の値が minimum-delivery-interval-in-millis の値よりも大きいことを確認する Application Server でのチェックに問題があります。

解決法

次のように、これらのプロパティーのデフォルト値を使用します。 

minimum-delivery-interval(default)=7000
redelivery-interval-in-millis(default)=5000

これらデフォルト以外の値を指定するとエラーが発生します。 

6180095 

access, failure についてデバッグ文を設定すると、Application Server の起動でハングアップする。

JVM の java.security.debug オプションを設定すると、サーバーインスタンスの起動がデッドロックで動かなくなります。たとえば、domain.xml で次の設定を行うと、この問題が発生します。

<jvm-options>-Djava.security.debug=access,failure</jvm-options>

現時点ではありません。このフラグは設定しないでください。 

6173308、6189645、6198481、6199510、6208728 

タイミングに依存する特定の場合に、JMS 再接続が正常に完了しない。 

タイミングに依存する場面での再接続の失敗は、さまざまな問題によって引き起こされます。 

解決法

これらの問題は、次の方法で回避できます。 

• 関連するブローカを再起動する

• 関連する Application Server インスタンスを再起動する

6198465 

非同期メッセージリスナーの動作が、appclient で 8.0 から 8.1 Update 2 に変更された。

最新の変更により、非同期メッセージリスナーが app-client コンテナの唯一の稼働しているスレッドである場合、残っている appclient 仮想マシンはデーモンとして存在します。この動作は、ACC で非同期受信を実行する過去のアプリケーションの影響です。この問題は、JMS メッセージリスナーを設定してメインスレッドを終了するアプリケーションクライアントに影響します。

解決法

メインスレッドを終了しないでください。メッセージリスナーがメインスレッドに通知するのを待ってから、メインスレッドを終了します。 

6174518 

HTTP サービスの監視統計には有益な情報を提示しないため、無視する必要があるものがある。 

HTTP サービスの一部の要素の監視統計を参照した場合、示される値のいくつかは現在の値に対応していないか、または常に 0 になっています。特に、次の HTTP サービス統計は Application Server に適用できる情報を表していないため、無視すべきです。 

• http-service

  load1MinuteAverage

  load5MinuteAverage

  load15MinuteAverage

  rateBytesTransmitted

  rateBytesReceived

• pwc-thread-pool (要素)

解決法

これらの監視情報は将来のリリースで削除され、より適切な情報で置き換えられる予定です。 

6191092 

該当する監視名を持つ統計をすべて削除した場合でも、配備を取り消された EJB モジュールに対する監視 MBean が削除されない。 

例:  

EJBModuleMonitorMap().size() = 1  eventhough ejb module is 
undeployed EJBModuleMonitor().getName() = sqe_ejb_s1_01

これは、EJB モジュールとアプリケーションの両方に当てはまります。MBean API 経由のプログラムを使用しても、asadmin list/get を使用しても、空の監視 MBean が残っています。

診断

asadmin list -m "server.applications" shows the following output:
server.applications.MEjbApp
server.applications.__ejb_container_timer_app
server.applications.adminapp
server.applications.admingui
server.applications.com_sun_web_ui
server.applications._export_install_nov-11_domains_domain1_applications
_j2ee-modules_sqe_ejb_s1_01

次のようにして統計を調べることができます。 

bin/asadmin list -m "server.applications._export_install_nov-11_domains
_domain1_applications_j2ee-modules_sqe_ejb_s1_01"
server.applications._export_install_nov-11_domains_domain1_applications_
j2ee-modules_sqe_ejb_s1_01.SQEMessage
server.applications._export_install_nov-11_domains_domain1_applications_
j2ee-modules_sqe_ejb_s1_01.TheGreeter

いったん配備を取り消します。 

_export_install_nov-11_domains_domain1_applications_j2ee-modules_sqe_
ejb_s1_01

ここで list コマンドを実行すると、まだアプリケーションが残っています。 

asadmin list -m "server.applications"
server.applications.MEjbApp
server.applications.__ejb_container_timer_app
server.applications._export_install_nov-11_domains_domain1_applications_
j2ee-modules_sqe_ejb_s1_01
server.applications.adminapp
server.applications.admingui
server.applications.com_sun_web_ui

しかし、何の監視統計も含まれていません。 

asadmin list -m "server.applications._export_install_nov-11_domains_
domain1_applications_j2ee-modules_sqe_ejb_s1_01"
Nothing to list at server.applications.-export-install-nov-11-domains-
domain1-applications-j2ee-modules-sqe-ejb-s1-01.

ある文字列で始まる有効な名前を取得するには、ワイルドカード文字 (「*」) を使用します。たとえば、server で始まるすべての監視可能エンティティーの名前を一覧表示するには、list "server.*" を使用します。

解決法

これは無害です。何の問題もなくモジュールを再配備できます。ルート監視 MBean は削除されませんが、その内容は空です。 

6184797 

アプリケーションの接続プールに対して遮断レベルを設定すると、PointBase で例外が発生する。 

PointBase データベースインストールを指している JDBC 接続プールについて、transaction-isolation-level プール属性をデフォルト (Connection.TRANSACTION_READ_COMMITTED) 以外の任意の値に設定すると、例外が発生します。ただし、その他のデータベースを指すプールについてデフォルト以外の値にこのパラメータを設定しても、例外はスローされません。

解決法

PointBase データベースを指す JDBC 接続プールについては、transaction-isolation-level を設定しないでください。

6204925 

ネットワークサーバードライバと組み込みドライバを一緒に使用すると、PointBase が例外をスローする。 

ネットワークサーバードライバと組み込みドライバを同時に使用すると、PointBase が例外をスローすることがあります。 

解決法

組み込みドライバとネットワークサーバードライバの両方ではなく、どちらか一方だけを使用してください。 

6264969、6275448 

デフォルトの PointBase データベースが上書きされるというアップグレードの問題がある。 

Application Server Enterprise Edition 8.1 2005Q2 Update 2 にアップグレードすると、アップデートリリースパッチによって Pointbase デフォルトデータベースが上書きされます。 

解決法

アップグレードの前に存在していたスキーマまたはデータを、すべて再作成または再入力します。テーブル生成オプションを使用して CMP Beans を含むアプリケーションを配備した場合は、テーブルを再作成するために、アプリケーションの配備の取消しまたは再配備を行う必要があります。 

6195092 

setup-one-machine-cluster が、Windows ではハングアップするが、Solaris では動作する。mqfailover を Ctrl+C でキャンセルし、再実行する必要がある。

install_dir\samples\ee-samples\failover\apps\mqfailover\docs\index.html を参照してから、次のコマンドを実行します。

• コンソール 1

  cd install_dir\samples\ee-samples asant start-mq-master-broker1

• コンソール 2

  cd install_dir\samples\ee-samples asant start-mq-cluster-broker1

• コンソール 3

  cd install_dir\samples\ee-samples asant start-mq-cluster-broker2

• コンソール 4

  cd install_dir\samples\ee-samples asadmin start-domain domain1

別の Enterprise Edition サンプル用に asant setup-one-machine-cluster-without-ha または asant setup-one-machine-cluster-with-ha を実行済みであれば asant configure-mq を、それ以外の場合には asant setup-one-machine-cluster-and-configure-mq を実行します。この場合、次に示すように、コマンドが正常に実行されたように見えます。

start_nodeagent: [echo] Start the node agent cluster1-nodeagent 
[exec] Command start-node-agent executed successfully.

しかし、このあとシステムはハングアップします。 

解決法

現時点ではありません。この問題は、Windows でこの ant ターゲットを使用するすべての Enterprise Edition サンプルに同様に影響します。回避策は、ハングアップしたプロセスを Ctrl+C でキャンセルしてから再実行することです。

6198003 

MQ フェイルオーバーのサンプルアプリケーションを実行する前に、asadmin deploy 命令の後で JMS リソースを作成する必要があることが、マニュアルに明記されていない。

次のエラーがスローされます。 

/opt/SUNWappserver/domains/domain1/config/sun-acc.xml -name 
MQFailoverTestClient -textauth -user j2ee -password j2ee
Nov 18, 2004 10:50:17 PM com.sun.enterprise.naming.NamingManagerImpl 
bindObjects
SEVERE: NAM0006: JMS Destination object not found: jms/durable/TopicA
Nov 18, 2004 10:50:18 PM com.sun.enterprise.naming.NamingManagerImpl 
bindObjects
SEVERE: javax.naming.NameNotFoundException
javax.naming.NameNotFoundException

asadmin deploy コマンドを使用して手動配備を行う場合に JMS リソースを手動で作成する必要があること、そして、サンプルアプリケーションを配備するために用意されている ant ターゲットを使用する必要があることが、マニュアルに明記されていません。

解決法

build.xml スクリプト用に asant deploy ターゲットを使用します。これにより、アプリケーションを実行するために必要とされる JMS リソースが作成されます。

6198239 

Linux で、webservices/security サンプルでの証明書の作成中に実行時エラーが表示される。 

Linux で install_dir/samples/webservices/security のサンプル (basicSSl) を配備するときに、証明書が作成されず、次のようなエラーがスローされます。

generate_certs: [echo] ***Exporting certificate from NSS database 
[exec] Result: 1 [echo] ***Generating Java Keystore from generated 
certificate [exec] keytool error: java.lang.Exception: Input not an 
X.509 certificate [exec] Result: 1 [echo] ***Generating Java trust 
store from generated certificate [exec] keytool error: java.lang.
Exception: Input not an X.509 certificate [exec] Result: 1
.
.
.
generate_certs: [echo] ***Exporting server certificate from NSS database to 
a PKCS12 certificate file [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/
libnss3.so: version `NSS_3.9' not found (required by /opt/sun/appserver/lib/
pk12util) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: 
version `NSS_3.6' not found (required by /opt/sun/appserver/lib/pk12util) 
[exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: version 
`NSS_3.7' not found (required by /opt/sun/appserver/lib/pk12util) [exec] 
Result: 1

問題は、Linux での NSS ライブラリの場所が Solaris での場所と異なることにあります。Linux 上に配備する場合、LD_LIBRARY_PATH が適切な NSS ライブラリを指していることを確認する必要があります。LD_LIBRARY_PATH を環境に設定するか、install_dir/bin/asant シェルラッパースクリプトに設定します。

解決法

次のいずれかを行います。 

• LD_LIBRARY_PATH=/opt/sun/private/lib を設定します。

• 次の行を install_dir/bin/asant スクリプトに追加します。

  LD_LIBRARY_PATH=$AS_NSS:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH

6183318 

Enterprise Edition 上で J2SE 5.0 を使用して WebServiceSecurity アプリケーションを実行できない。

WebServiceSecurity アプリケーションは、次の理由から、J2SE 5.0 では実行できません。

• J2SE 5.0 の PKCS11 は、UNWRAP モードをサポートしない

• J2SE 5.0 の PKCS11 は、PKCS11 による RSA/ECB/OAEPWithSHA1AndMGF1Padding をサポートしない

J2SE チームは、このバグのために「CR 6190389: Add support for RSA-PKCS1 and RSA-OAEP wrap/unwrap mechanisms」をファイルしています。 

解決法

J2SE 1.4.2 で別の JCE プロバイダ (デフォルトで含まれているもの以外) を使用します。この構成では、ハードウェアアクセラレータはサポートされません。 

6269102 

SSL 終了が機能しません。ロードバランサ (ハードウェア) を SSL 終了用に設定すると、リダイレクト中に Application Server がプロトコルを https から http に変更します。

解決法

ハードウェアロードバランサと Application Server の間にソフトウェアロードバランサを追加します。 

6165528 

Enterprise Edition 8 から Application Server Enterprise Edition 8.1 にアップグレードするときに、install_dir/domains ディレクトリ以外のカスタムパスに作成されたドメインが直接アップグレードされない。

アップグレードユーティリティーを実行しているときに、install_dir をソースインストールディレクトリとして指定すると、そのアップグレードプロセスは、install_dir/domains ディレクトリの下に作成されたドメインだけをアップグレードします。その他の場所に作成されたドメインはアップグレードされません。

解決法

アップグレードプロセスを起動する前に、すべてのドメインディレクトリを、それぞれの場所から install_dir/domains ディレクトリに移動します。

6207337 

一部の Linux システムで、「代替アップグレード」を実行しているインストーラが、「アップグレードウィザードの起動」ボタンのクリック後にアップグレードツールの起動に失敗する。 

この問題はさまざまな Linux システムで発生しています。Java Desktop System 2 でもっとも一般的ですが、Red Hat ディストリビューションでも発生しています。 

インストールプログラムの最後の画面で「アップグレードツールの起動」ボタンをクリックすると、そのインストールプログラムはアップグレード処理を完了するためのアップグレードツールの起動に失敗し、コマンドプロンプトに戻ることなくハングアップします。 

解決法

この問題は、コマンド行インストールモードを使用して代替アップグレードを実行している場合には発生しません。 

1. GUI モードで代替アップグレードを実行してこの問題が発生した場合には、インストールプログラムを起動した端末ウィンドウで Ctrl+C を押すことにより、そのインストールプログラムを終了します。

2. その端末ウィンドウから次のコマンドを使用してアップグレードツールを起動します。

   install_dir/bin/asupgrade --source install_dir/domains --target install_dir --adminuser adminuser --adminpassword adminpassword --masterpassword changeit

   adminuser および adminpassword は、アップグレード中のインストールで使用されている値に一致する必要があります。

3. アップグレードツールがアップグレードプロセスを完了したあとは、ブラウザを起動して次の URL を入力することにより、「バージョン情報」ページを参照できます。

   file://install_dir/docs-ee/about.html

製品を登録するインストールオプションを選択した場合には、「バージョン情報」ページ上の登録ページへのリンクをたどってください。 

6296105 

8.0 Platform Edition (PE) から 8.1 Enterprise Edition (EE) UR2 へのアップグレード中およびその後、自己署名付き証明書が信頼されない。 

解決法

アップグレード後、ターゲットの domain.xml から次のエントリを削除し、サーバーを再起動します。

<jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}
/config/keystore.jks</jvm-options>-
<jvm-options>Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}
/config/cacerts.jks</jvm-options>

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 証明書を、それを要求している任意の配備されたアプリケーションに提供します。