Sun Java System Application Server Enterprise Edition 8.1 2005Q2 リリースノート

- Previous: 第 2 章 Application Server Enterprise Edition 8.1 2005Q2 の概要

# 第 3 章 既知の問題点と制限事項

この章では、Sun Java System Application Server Enterprise Edition 8.1 2005Q2 ソフトウェアに関する既知の問題とそれに関連する回避策について説明します。問題の説明にプラットフォームが明記されていない場合、その問題はすべてのプラットフォームに当てはまります。この内容は次の項目から構成されています。

- 「管理」

- 「Apache とロードバランサプラグイン」

- 「アプリケーションクライアント」

- 「付属の Sun JDBC ドライバ」

- 「コネクタ」

- 「マニュアル」

- 「高可用性」

- 「インストール」

- 「J2EE Tutorial」

- 「ライフサイクル管理」

- 「ロギング」

- 「Message Queue」

- 「監視」

- 「PointBase」

- 「サンプル」

- 「セキュリティー」

- 「アップグレードユーティリティー」

- 「Web コンテナ」

# 管理

ここでは、管理上の既知の問題とその解決方法を示します。

バグ ID | 概要
--- | ---
6171458 | `domain1` がない場合に `package-appclient` スクリプトが機能しない。 デフォルトでは、`$INSTALL/lib/package-appclient.xml` に、`asenv.conf` によってポイントされる `domain1` の `AS_ACC_CONFIG` 変数用にハードコードされた値があります。domain1 を削除して新たなドメインを作成した場合、`AS_ACC_CONFIG` 変数は新たなドメイン名で更新されません。その結果、`package-appclient` スクリプトの処理が失敗します。 解決法 次のいずれかを行います。 `domain1` はそのままにしておき、その前後に別のドメインを作成します。 `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/*
1. 6236544、6275436 | どの Web サービスのエンドポイント URL を使用しても、ロードバランサの設定ファイルが作成されない。 Web サービスの URL をエクスポートする EJB モジュールを含むアプリケーションを使用してロードバランサを設定しても、作成された `loadbalancer.xml` ファイルに、その Web サービスのコンテキストルートが存在しません。 解決法 `loadbalancer.xml` ファイルを編集して、作成されなかった Web モジュールを次のように追加します。
       <web-module context-root="context-root-name"
       disable-timeout-in-minutes="30" enabled="true"/>
context-root-name 値を、EJB として公開された Web サービスのコンテキストルート名に置き換えます。
6288893 | `sun-appserv-admin` を使用して Application Server を再起動すると、`LoginException` エラーが発生する。 解決法 既存の <as_install>`/bin/asant` スクリプトの名前を `asant.bak` に変更します。 <as_install>`/lib/install/templates/ee` (SE/EE バージョンの場合) にある `asant.template` ファイルを <as_install>`/bin/` ディレクトリにコピーし、このファイルの名前を `asant` に変更します。 新しくコピーされた <as_install>`/bin/asant` スクリプトを編集して、`%CONFIG_HOME%` トークンを <as_install>`/config` に置き換えます。 元の `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 リスナーの「サポートされるすべての暗号化方式群」を選択すると、その他チェックボックスは無効になるが、ページを更新すると再び有効 になります (「サポートされるすべての暗号化方式群」ボックスが選択されているにもかかわらず) 一見問題に見えるかもしれませんが、証明書のニックネームを入力し「保存」をクリックした後、変更内容が設定に書き込まれます。 解決方法: 対処の必要はありません。変更内容は保存されています。

# Apache とロードバランサプラグイン

ここでは、Apache Web Server およびロードバランサプラグインに関する既知の問題と、それに関連する解決法を示します。

バグ ID | 概要
--- | ---
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` はセキュリティーポート番号です。

# アプリケーションクライアント

ここでは、アプリケーションクライアントに関する既知の問題とその解決方法を示します。

バグ ID | 概要
--- | ---
6193556 | アプリケーションクライアントアーカイブのライブラリ JAR が MANIFEST ファイルを上書きする。 クライアント JAR (たとえば reporter.jar) 内に最上位レベルの JAR ファイルがある場合、クライアント JAR を配備すると、その JAR の MANIFEST ファイルがクライアント JAR の MANIFEST ファイルを上書きします。 解決法 現時点ではありません。
6373043 | CGI-bin や SHTML などの動的コンテンツ技術はサポートされなくなりました。 解決法 JSP および Web サービス技術を代わりに使用します。

# 付属の Sun JDBC ドライバ

ここでは、Sun の JDBC ドライバに関する既知の問題とその解決方法を示します。

バグ ID | 概要
--- | ---
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 つだけ含まれるようにしてください。

# コネクタ

この節では、J2EE のコネクタアーキテクチャーに関する既知の問題とその解決方法を示します。

バグ ID | 概要
--- | ---
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 | 概要
--- | ---
さまざまな 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);

# 高可用性

ここでは、高可用性データベース (HADB) に関する既知の問題とその解決方法を示します。

バグ ID | 概要
--- | ---
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` オプションでこれらのファイルを参照します。

# インストール

ここでは、インストール上の既知の問題とその解決方法を示します。

バグ ID | 概要
--- | ---
5009728 | 一部の Linux システムで、「完了」ボタンをクリックしたあとにインストールの終了でハングアップする。 この問題は、いくつかの Linux システム上で発生していました。これは Java Desktop System 2 でもっとも一般的に見られますが、Linux Red Hat ディストリビューションでも見られます。 インストールプログラムの最後の画面で「完了」ボタンをクリックすると、インストールプログラムは製品の「バージョン情報」ページまたは製品登録ページを表示するブラウザウィンドウの起動に失敗し、コマンドプロンプトに戻ることなくハングアップします。 解決法 インストールプログラムを起動した端末ウィンドウで `Ctrl+C` を押すことにより、インストールプログラムを終了します。そのあとで、製品の「バージョン情報」ページまたは登録ページを表示するブラウザウィンドウが起動することがあります。ブラウザウィンドウが現れない場合には、ブラウザを起動してから次の URL を入力して「バージョン情報」ページを確認してください。
    file://install_dir/docs-ee/about.html
製品を登録するインストールオプションを選択した場合には、「バージョン情報」ページ上の登録ページへのリンクをたどってください。
1. 6199697 | Windows では、インストール中に imq ディレクトリを作成する必要がある。 Windows では、Application Server Enterprise Edition をインストールした直後に、ディレクトリ `drive:\as\domains\domain1\imq` が存在しない旨のメッセージを出力して Message Queue ブローカが起動に失敗します。 `domain1` を起動してからブローカを起動した場合には、Application Server によってディレクトリが作成され、この問題は発生しません。 解決法 ブローカを作成する前に `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) をサポートしていません。 解決法 なし。

# J2EE Tutorial

Sun Java System Application Server Enterprise Edition 8.1 2005Q2 で J2EE 1.4 Tutorial を実行するには、次の作業を実行します。

- 「About this Tutorial」の章の「About the Examples」で説明されているファイル例 `/common/build.properties` を編集する場合には、ポート 4848 を 4849 に変更します。

- deploytool を使用する場合、例を配備する前にサーバー `localhost:4849` を追加します。

- 管理コンソールを使用して何らかのリソースを作成する場合には、「ターゲット」タブを使用してサーバーをターゲットとして指定します。コマンド行または `asant` ターゲットを使用する場合、サーバーがデフォルトのターゲットになるため、特別な処置は必要ありません。

# ライフサイクル管理

ここでは、ライフサイクル管理に関する既知の問題とその解決方法を示します。

バグ ID | 概要
--- | ---
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
これらデフォルト以外の値を指定するとエラーが発生します。

# ロギング

この節では、ログに関する既知の問題とその解決方法を示します。

バグ ID | 概要
--- | ---
6180095 | `access, failure` についてデバッグ文を設定すると、Application Server の起動でハングアップする。 JVM の `java.security.debug` オプションを設定すると、サーバーインスタンスの起動がデッドロックで動かなくなります。たとえば、`domain.xml` で次の設定を行うと、この問題が発生します。
    <jvm-options>-Djava.security.debug=access,failure</jvm-options>
現時点ではありません。このフラグは設定しないでください。

# Message Queue

ここでは、Java メッセージキューに関する既知の問題とその解決方法を示します。

バグ ID | 概要
--- | ---
6173308、6189645、6198481、6199510、6208728 | タイミングに依存する特定の場合に、JMS 再接続が正常に完了しない。 タイミングに依存する場面での再接続の失敗は、さまざまな問題によって引き起こされます。 解決法 これらの問題は、次の方法で回避できます。 関連するブローカを再起動する 関連する Application Server インスタンスを再起動する
6198465 | 非同期メッセージリスナーの動作が、`appclient` で 8.0 から 8.1 Update 2 に変更された。 最新の変更により、非同期メッセージリスナーが `app-client` コンテナの唯一の稼働しているスレッドである場合、残っている `appclient` 仮想マシンはデーモンとして存在します。この動作は、ACC で非同期受信を実行する過去のアプリケーションの影響です。この問題は、JMS メッセージリスナーを設定してメインスレッドを終了するアプリケーションクライアントに影響します。 解決法 メインスレッドを終了しないでください。メッセージリスナーがメインスレッドに通知するのを待ってから、メインスレッドを終了します。

# 監視

ここでは、監視上の既知の問題とその解決方法を示します。

バグ ID | 概要
--- | ---
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 は削除されませんが、その内容は空です。

# PointBase

ここでは、PointBase に関する既知の問題とその解決方法を示します。

バグ ID | 概要
--- | ---
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 を含むアプリケーションを配備した場合は、テーブルを再作成するために、アプリケーションの配備の取消しまたは再配備を行う必要があります。

# サンプル

ここでは、Application Server 8.1 製品に付属するサンプルコードに関する既知の問題とその解決方法を示します。

バグ ID | 概要
--- | ---
- 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

# セキュリティー

ここでは、Application Server と Web アプリケーションのセキュリティーおよび証明書に関する既知の問題とその解決方法を示します。

バグ ID | 概要
--- | ---
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 の間にソフトウェアロードバランサを追加します。

# アップグレードユーティリティー

この節では、アップグレードユーティリティーに関する既知の問題とその解決方法を示します。

バグ ID | 概要
--- | ---
6165528 | Enterprise Edition 8 から Application Server Enterprise Edition 8.1 にアップグレードするときに、`install_dir/domains` ディレクトリ以外のカスタムパスに作成されたドメインが直接アップグレードされない。 アップグレードユーティリティーを実行しているときに、`install_dir` をソースインストールディレクトリとして指定すると、そのアップグレードプロセスは、`install_dir/domains` ディレクトリの下に作成されたドメインだけをアップグレードします。その他の場所に作成されたドメインはアップグレードされません。 解決法 アップグレードプロセスを起動する前に、すべてのドメインディレクトリを、それぞれの場所から `install_dir/domains` ディレクトリに移動します。
2. 6207337 | 一部の Linux システムで、「代替アップグレード」を実行しているインストーラが、「アップグレードウィザードの起動」ボタンのクリック後にアップグレードツールの起動に失敗する。 この問題はさまざまな Linux システムで発生しています。Java Desktop System 2 でもっとも一般的ですが、Red Hat ディストリビューションでも発生しています。 インストールプログラムの最後の画面で「アップグレードツールの起動」ボタンをクリックすると、そのインストールプログラムはアップグレード処理を完了するためのアップグレードツールの起動に失敗し、コマンドプロンプトに戻ることなくハングアップします。 解決法 この問題は、コマンド行インストールモードを使用して代替アップグレードを実行している場合には発生しません。 GUI モードで代替アップグレードを実行してこの問題が発生した場合には、インストールプログラムを起動した端末ウィンドウで Ctrl+C を押すことにより、そのインストールプログラムを終了します。 その端末ウィンドウから次のコマンドを使用してアップグレードツールを起動します。
       install_dir/bin/asupgrade --source install_dir/domains --target
       install_dir --adminuser adminuser --adminpassword adminpassword
       --masterpassword changeit
3. adminuser および adminpassword は、アップグレード中のインストールで使用されている値に一致する必要があります。 アップグレードツールがアップグレードプロセスを完了したあとは、ブラウザを起動して次の 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>

# Web コンテナ

ここでは、Web コンテナに関する既知の問題とその解決方法を示します。

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

- Previous: 第 2 章 Application Server Enterprise Edition 8.1 2005Q2 の概要

- © 2010, Oracle Corporation and/or its affiliates