test

Sun Java System Application Server Enterprise Edition 8.2 リリースノート (UNIX 版)

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

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

管理

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

domain1 が存在しない場合、package-appclient スクリプトが動作しない。(ID 6171458)

説明

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

解決方法

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

負荷分散プラグインをインストールすると、既存のプラグインが上書きされる。(ID 6172977)

説明

7.1EE などからすでにロードバランサプラグインがインストールされている Application Server のインストールに対して負荷分散プラグインをインストールすると、プラグインを実行する新しいサーバーインスタンスを作成しても、メッセージの表示なしで既存のロードバランサが 8.2EE プラグインに置き換えられます。

プラグインファイルは、デフォルトで install_dir /plugins/lbplugin ディレクトリの下にインストールされるため、1 つの Application Server インストールで使用できるプラグインは 1 つのバージョンだけになります。コンソールインストーラはアンインストールが実行されていることを示すメッセージを表示しますが、このメッセージは見逃しやすいことに注意してください。

解決方法

だれもがこの問題を経験するわけではありません。この問題が発生した場合は、古い Application Server インストールを削除して、アップグレードインストールではなく新規インストールを実行してください。

JES2 AS7 と比べると、JES3 Application Server 8.2 の asadmin スクリプトにいくつかの変更がある (ID 6189433、6189436)

Application Server 7.x と比べると、Application Server 8.2 の asadmin コマンドにはいくつかの変更が加えられています。たとえば、7.x では、サーバーインスタンスを起動するコマンドは次のとおりです。


asadmin start-instance

8.2 では、同等のコマンドは次のとおりです。


asadmin start-domain --user admin domain1

最新の asadmin コマンド構文の詳細については、次のマニュアルを参照してください。

Application Server のデフォルトポートが変更される (ID 6198555)

説明

JES2/Application Server 7. x から JES5/Application Server 8.2 にアップグレードすると、デフォルトのポートが変更されたために、互換性が失われたりエラーが発生したりすることがあります。

解決方法

Application Server 8.2 で使用されるデフォルトポートの一覧については、このリリースノートの 「その他の要件」を参照してください。

バックアップしたドメインを別の名前で復元できない。(ID 6196993)

説明

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

解決方法

restore-domain で使用するドメイン名は、元の backup-domain コマンドで使用したドメイン名と同じである必要があります。Application Server 8.2 の backup-domain コマンドと restore-domain コマンドが動作するのは、同一マシンで同一ドメインをバックアップおよび復元する場合だけです。

JMX エージェントを追加した Application Server の起動はサポートされていない。(ID 6200011)

説明

J2SE 1.4.x、5.0、またはそれ以降のバージョンは、Application Server で設定できます。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 の管理 GUI や CLI で予期しない結果が発生することがあります。問題は、組み込みの jmx-connector サーバーと新たな jmx-connector サーバーとの間で衝突が発生することにあります。

解決方法

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

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

[#|2004-11-24T17:49:08.203-0800|INFO|sun-appserver-ee8.1|javax.enterprise.
system.tools.admin|_ThreadID=10;|ADM1501: Here is the JMXServiceURL for the 
JMXConnectorServer: [service:jmx:rmi:///jndi/rmi://hostname:8686/management/
rmi-jmx-connector]. This is where the remote administrative clients should 
connect using the JSR 160 JMX Connectors.|#]

詳細については、『 Sun Java System Application Server 8.2 管理ガイド』を参照してください。

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

説明

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

解決方法

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


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

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

説明

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 サービスのコンテキストルート名に置き換えます。

設定内の Java ホームの設定が反映されない。(ID 6240672)

説明

Application Server のドメインまたはサーバーが、関連付けられた設定の java-config 要素の java-home 属性によってポイントされる JDK を使用しません。

解決方法

該当のサーバーインストール内のすべてのドメインに対して Application Server プロセスが使用する JDK は、appserver-installation-dir /config/asenv.conf ファイルによって決まります。使用される JDK は、このファイル内のプロパティー AS_JAVA によって決まります。これはインストール時に設定されます。インストール後に別の JDK を Application Server プロセスが使用するようにするには、別の JDK をポイントするようにこの値を編集します。この変更によって、このインストール内のすべてのドメインが影響を受けることに注意してください。

注 –

asenv.conf ファイルを手動で変更する場合は有効性がチェックされないため、変更時に注意が必要です。AS_JAVA の値を修正する場合は、製品のマニュアルで JDK のバージョンの最低限の要件を確認してください。

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

説明

この問題は %CONFIG_HOME% の間違った値によって発生します。

解決方法

  1. 既存の名前を 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 スクリプトに結合します。

Application Server のマニュアルに .asadmintruststore ファイルが記述されていない。(ID 6315957)

説明

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

解決方法

ドメインのマスターパスワードに特殊文字が含まれる場合、ドメインの起動が失敗する。(ID 6345947)

説明

ドメインのマスターパスワードにパーセント文字 (%) が含まれるときにドメインが起動しません。

解決方法

ドメインのマスターパスワードにパーセント文字 (%) を含めないようにしてください。これは、新しいドメインを作成するとき、および既存のドメインのマスターパスワードを変更するときに適用されます。

magnus.conf および obj.conf でのロードバランサの設定変更が上書きされる (ID 6394181)

説明

セキュリティー保護された http-listener を作成し、lbplugin をインストールしたあとで、webserver_instance_dir/config の下の magnus.conf および obj.conf ファイルが変更され、lbplugin の内容が削除されます。

インストーラは、ロードバランサプラグインのインストールの一部として、Application Server の magnus.conf および obj.conf 設定ファイルを変更します。Application Server 管理コンソールにログインし、ロードバランサがインストールされたインスタンスのインスタンス設定を管理しようとすると、Application Server は、設定の手動編集を検出したことを示す警告メッセージを表示します。この警告は、実際にはインストーラによって加えられた変更を示しています。

解決方法

インストーラによって加えられた変更が上書きされていないことを確認します。

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

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

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

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 になります。

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

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

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

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


Group #-1

次の行に置き換えます。


Group nobody

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

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

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

次の行を置き換えます。

<VirtualHost _default_:9191>

次の行に置き換えます。

<VirtualHost machine_name:9191>

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

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

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

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

説明

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

解決方法

現時点ではありません。

CGI-bin や SHTML 機能などの動的コンテンツ技術がサポートされていない。(ID 6373043)

説明

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

解決方法

代わりに JSP または Web サービスの技術を使用してください。

付属の Sun JDBC ドライバ

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

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

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

PreparedStatement エラーが発生する。(ID 6170432)

説明 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

接続プールの設定の詳細は、『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』 を参照してください。

説明 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

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

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

説明

解決方法

現時点ではありません。

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

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

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

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

java.lang.SecurityException: Sealing violation exception (ID 6554602)

説明

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

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

Note:405446.1 Subject: JDBC Driver 10.2 Uses Sealed JAR files and May Cause SecurityException Sealing Vio

lation

解決方法

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

コネクタ

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

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

説明

このシナリオでは、スタンドアロンまたは埋め込みのコネクタモジュールが 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 に設定) します。

JMS create-jms-resource; CLI によってデフォルト値が正しく設定されない (ID 6294018)

説明

コマンド行から asadmin create-jms-resource コマンドで新しい JMS リソースを作成するときは最小プールサイズと最大プールサイズを指定できないため、asadmin コマンドがデフォルトのプールサイズ値 (最小が 8、最大が 32) を使用してリソースを作成すべきです。ただし、この場合には当てはまりません。代わりに、コマンド行からリソースを作成すると、デフォルトの最小プールサイズと最大プールサイズがそれぞれ 1 と 250 になります。

解決方法

コマンド行から JMS リソースを作成したあとで、管理コンソールを使用して最小プールサイズ値と最大プールサイズ値を変更します。

マニュアル

ここでは、マニュアル上の既知の問題とその解決方法を示します。

Javadoc に矛盾がある。(さまざまな ID)

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

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

説明

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

解決方法

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

ログオプションのマニュアルに誤りがある (ID 6463965)

『Sun Java System Application Server Enterprise Edition 8.2 パフォーマンスチューニングガイド』で、ログオプションについて次のように記述されていますが、これは誤りです。

The Administration GUI provides the following two logging options: (Administration GUI は次の 2 つのログオプションを提供します。)

  • Option 1 – Log stdout ( System.out.print) content to the event log (オプション 1 – stdout (System.out.print) コンテンツをイベントログに記録する)

  • Option 2 – Log stderr ( System.err.print) content to the event log (オプション 2 – stderr (System.err.print) コンテンツをイベントログに記録する)

これらのログオプションは、Application Server Enterprise Edition 8.2 では存在しなくなりました。

Application Server 8.2 の HTTP ファイルキャッシュ機能に関して相反する情報がある (ID 6474799)

Application Server Enterprise Edition 8.2 のマニュアルでは、『Sun Java System Application Server Enterprise Edition 8.2 パフォーマンスチューニングガイド』の「HTTP ファイルキャッシュ」で HTTP ファイルキャッシュ機能について説明しています。しかし、この機能は Application Server Enterprise Edition 8.2 に含まれていませんでした。この機能は Application Server 9.0 で再導入されたことに注意してください。

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

ほかの欠陥 (6295215 など) により、『Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide』の「Obtaining a Physical Connection from a Wrapped Connection」 (第 11 章)、『Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide』の第 11 章「Using the JDBC API for Database Access」に記載されているコードは正しくなくなりました。具体的には、次の行を


Connection drivercon = ds.getConnection(con);

次のように修正する必要があります。


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

高可用性

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

ダブルネットワークでの HADB 設定。(ID なし)

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

HADB データベースの作成が失敗する。(ID なし)

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

説明

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 倍以上になっていることを確認します。

共有メモリーセグメントがロックされ、ページアウトできない。(ID 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 の要件とサポートされているプラットフォーム」を参照してください。

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

説明

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

解決方法

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

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

説明

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


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) は、すべての参加ホストについて同一にしてください。

createdomain が失敗することがある。(ID 6173886、6253132)

説明

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


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 で識別される) 内のすべてのファイルとディレクトリを削除します。この操作は、新しい設定ファイルを使用してエージェントを再起動する前に、すべてのホスト上で実行する必要があります。

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

説明

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

解決方法

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

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

説明

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

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

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

説明

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

解決方法

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


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

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

clu_trans_srv を中断できない。(ID 6249685)

説明

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

解決方法

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

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

説明

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

解決方法

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

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

説明

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

解決方法

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

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

説明

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

解決方法

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

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

説明

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

解決方法

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

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

説明

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

解決方法

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

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

説明

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

解決方法

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

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

説明

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

解決方法

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

Windows 上で再構築が失敗する。(ID 6291562)

説明

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

解決方法

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

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

説明

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

解決方法

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

大域ゾーンにインストールされた JES5 HADB に疎ローカルゾーンからアクセスできない (ID 6460979)

説明

Application Server を Solaris 大域ゾーンの /usr/SUNWappserver にインストールすると、その Application Server インスタンスとともにインストールされた HADB コンポーネントは疎ローカルゾーンでは利用できません。

問題は、HADB が大域ゾーンの /opt/SUNWhadb にインストールされても、このディレクトリが疎ローカルゾーンから読み込み可能でないことにあります。残念ながら、JES5 の HADB バンドルは再配置できません。

解決方法

Application Server HADB コンポーネントは再配置できないため、HADB へのアクセス元にしたいそれぞれの疎ローカルゾーンに HADB コンポーネントを別途インストールする必要があります。

インストール

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

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

説明

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

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

解決方法

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


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

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

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

説明

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

compat-libstdc++ がない場合に、Application Server を RHLAS 3.0 および RHLAS 4.0 に設定できない (ID 6396102)

説明

Application Server Enterprise Edition 8.2 を Red Hat Linux Advanced Server (RHLAS) 3.0 または 4.0 システムにインストールする場合は、システムに compat-libstdc++ ライブラリがインストール済みでないと失敗します。Application Server では、RHLAS システム上に compat-libstdc++ ライブラリが必要ですが、これはデフォルトではインストールされません。この問題は RHLAS システムでのみ発生します。

解決方法

Application Server ソフトウェアをインストールする前に、http://rpm.pbone.net/index.php3/stat/4/idpl/843376/com/compat-libstdc++-7.3-2.96.118.i386.rpm.html から compat-libstdc++ RPM をダウンロードしてインストールします。

サーバーが 64 ビットモードで実行されていると、lbplugin (libpassthrough.so ) を使用できない (ID 6480952)

説明

Application Server Enterprise Edition 8.2 を 64 ビットモードの Web Server 7.0 とともに実行しているときに、64 ビットバージョンのロードバランサプラグインを実行しようとすると、次のエラーが発生して失敗します。


failure: CORE2253: Error running Init function load-modules: dlopen 
of /export/home/mareks/opt/webserver7/plugins/lbplugin/bin/libpassthrough.so 
failed (ld.so.1: webservd: fatal: /export/home/mareks/opt/webserver7/plugins/
lbplugin/bin/libpassthrough.so: wrong ELF class: ELFCLASS32)
failure: server initialization failed

問題は、Application Server Enterprise Edition 8.2 用の 64 ビットのロードバランサプラグインがなく、64 ビットの Web Server には 64 ビットのプラグインが必要であることにあります。

Web Server が 64 ビットモードで動作しているか 32 ビットモードで動作しているかは、次のコマンドを使用して判別できます。


wadm get-config-prop --user=admin --config=xxx --password-file=xxx platform

解決方法

Application Server Enterprise Edition 8.2 用の 64 ビットのロードバランサは計画されていません。この問題を回避するには、Web Server 7.0 の逆プロキシ機能を使用するか、32 ビットモードで動作するように Web Server 7.0 を設定してください。手順については、Web Server のマニュアルを参照してください。

「入力行が長すぎます」というメッセージが表示されて、asant deploy を実行できない (Windows 2000) (ID 6485174)

説明

Application Server 8.2 を Windows 2000 のデフォルトの場所にインストールすると、asant deploy の実行時に次のエラーが発生することがあります。


$ C:/Sun/JavaES5/appserver/bin/asant deploy
The input line is too long.
The syntax of the command is incorrect.

問題は、Windows 2000 のコマンド行を 1000 文字より長くすることができず、システム構成によってはデフォルトの ANT_OPTS 環境が原因で asant deploy コマンド行が長くなることにあります。これは Windows 2000 だけの問題です。

解決方法

Windows 2000 で、Application Server を C:\JES5_AS などの非常に短いディレクトリパスにインストールします。

JES5 b12 の AS インストールで、common.properties 内に誤ったサーバーインスタンス AppServer1 がある (ID 6485254)

説明

Windows 上の JES 5 b12 を使用していて、コンポーネント選択パネルの上位レベルで Application Server を選択した場合、ノードエージェントサブコンポーネントもデフォルトで選択されます。その後、インストールプロセスによって、ノードエージェントと、そのノードエージェントに属する AppServer1 というサーバーインスタンスが作成されます。これが正しい動作です。

ただし、ノードエージェントサブコンポーネントの選択を解除した場合でも、ドメインの common.properties ファイルでは AppServer1 インスタンスが作成されます。たとえば次のようになります。


domain.name=domain1
appserver.instance=AppServer1

これ以降、asant を使用してアプリケーションを配備しようとしても失敗します。

解決方法

common.propeties ファイルを編集して、appserver.instance=AppServer1 を appserver.instance=server で置換します。

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

ほかの欠陥 (6295215 など) により、『Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide』の「Obtaining a Physical Connection from a Wrapped Connection」 (第 11 章)、『Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide』の第 11 章「Using the JDBC API for Database Access」に記載されているコードは正しくなくなりました。具体的には、次の行を


Connection drivercon = ds.getConnection(con);

次のように修正する必要があります。


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

Application Server が NFS をサポートしない。(6396045)

このバージョンのソフトウェアでは、Application Server でネットワークファイルシステム (NFS) をサポートしません。

解決方法

ありません。

J2EE Tutorial

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

ライフサイクル管理

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

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

説明

[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(default)=7000
redelivery-interval-in-millis(default)=5000

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

ロギング

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

access.failure のデバッグ文を設定すると、Application Server の起動時にハングする。(ID 6180095)

説明

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

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

解決方法

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

JES3 Application Server 以降ログの場所やインスタンスの場所が変更されている (ID 6189409)

Sun Java System 8.2 では、7.x と比べると、ログやサーバーインスタンスのデフォルトの場所が変更されています。

詳細は、『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』または『Sun Java System Application Server Enterprise Edition 8.2 アップグレードと移行』を参照してください。

メッセージキュー

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

タイミングに依存する特定の場合に、JMS 再接続が正常に完了しない。(ID 6173308、6189645、6198481、6199510、6208728)

説明

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

解決方法

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

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

説明

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

解決方法

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

監視

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

コネクタサービスとコネクタ接続プールの監視レベルを変更できない。(ID 6089026)

説明

「監視レベル」設定ページを使用して、「コネクタサービス」または「コネクタ接続プール」の監視レベルを LOW または HIGH に変更して保存しても、ドメインの domain.xml ファイルのどちらの値も変更されません。しかし、「JMS サービス」の監視レベルを LOW または HIGH に変更して保存すると、「コネクタサービス」と「コネクタ接続プール」の値も同時に変更されます。この問題は、コマンド行から同等のコマンドを実行すると発生しません。

解決方法

監視レベルを変更するときは、「監視レベル」ページの JMS サービスコンポーネントだけを使用してください。

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

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

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

説明

次に例を示します。


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

持続性

ここでは、Java Data Objects およびコンテナ管理による持続性に関する既知の問題とその解決方法を示します。

JDO76018: 循環依存関係が原因で持続オブジェクトをフラッシュできない。(ID 6500961)

説明

この例外は、トランザクションで変更 (または作成) されたインスタンス間に外部キー依存関係のチェーンがあるため、データベースで循環依存関係が生じた場合にスローされます。

解決方法

元の一連の操作を複数のトランザクションに分割します。

PointBase

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

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

説明

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

解決方法

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

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

説明

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

解決方法

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

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

説明

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

解決方法

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

サンプル

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

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

説明

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

別の 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 でキャンセルしてから再実行することです。

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

説明

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


/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 リソースが作成されます。

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

説明

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 シェルラッパースクリプトに設定します。

解決方法

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

8.0 Platform Edition から 8.2 Enterprise Edition へのアップグレード後にサンプルドキュメントが見つからない

説明

Application Server Platform Edition 8.0 から Application Server Enterprise Edition 8.2 にアップグレードしたあとで、サンプルページにアクセスしようとすると、HTTP 404 の「ファイルが見つかりません」というエラーが表示されることがあります。

解決方法

サンプルドキュメントを 8.0 ドメインから 8.2 ドメインにコピーしてください。

サンプルを疎ローカルゾーンで実行すると、実行時に失敗する。(ID 6460970)

説明

Application Server Enterprise Edition 8.2 を Solaris 大域ゾーンにインストールしたあとに続けて Application Server ドメインを疎ローカルゾーンにインストールした場合、疎ゾーンのドメインのファイルアクセス権が配備プロセス中に十分開かれていないと、サンプルアプリケーションを実行するときに問題が発生することがあります。

解決方法

配備プロセス中に、Application Server がクライアント JAR ファイル xmsClient.jar を検出してサンプルの場所 (/usr/SUNWappserver/appserver/samples/webservices/security/ejb/apps/xms/xmsClient.jar ) にコピーできるようにしてください。通常、これはサンプルハーネスによって自動的に実行されますが、xmsClient.jar に対するアクセス権が開かれていないと失敗します。

セキュリティー

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

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

説明

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

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

解決方法

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

SSL 終了が機能しない。(ID 6269102)

説明

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

解決方法

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

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

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

Application Server Enterprise Edition 8 から Application Server Enterprise Edition 8.2 へのアップグレードで、install_dir /domains ディレクトリ以外のカスタムパスに作成されたドメインが直接アップグレードされない。(ID 6165528)

説明

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

解決方法

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

一部の Linux システムで「アップグレードウィザードを起動」ボタンをクリックしたあとに、「同じ場所にアップグレード」を実行するインストーラがアップグレードツールの起動に失敗する。(6207337)

説明

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

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

解決方法

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

Procedureコマンド行インストールモードを使用するには

  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/about.html

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

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

アップグレード後、ターゲットの 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>

Application Server の JES2 から JES5 へのアップグレード後にポートの衝突が発生する

説明

Application Server 7.x から 8.2 に更新すると、古いインストールと新しいインストールの間でポートの衝突 (おそらく、デフォルトポートの 8080 と 8181) が発生することがあります。

解決方法

ポートの衝突を解決するには、Application Server 8.2 で使用するポートを変更してください。

サンプルスクリプトで使用する Derby データベースが間違った場所に作成される。(ID 6377804)

説明

このバグには、次の 2 つの面があります。

  1. Derby データベースを使用するサンプルアプリケーション設定スクリプトを実行すると、Derby データベースが現在のディレクトリまたは <install_root>/bin の下に作成されます。

  2. サンプル build Ant スクリプトによって、管理パスワードファイルを保存する password.txt ファイルが現在のディレクトリの下に作成されますが、このディレクトリはルート以外の疎ゾーンシナリオでは書き込み可能ではありません。

解決方法

  1. Derby データベースの場所 – start-database コマンドで --dbhome オプションを使用して、--dbhome に指定された値の場所にデータベースを作成します。たとえば、次の例は、start-database 用の asadmin コマンドの構文です。


    start-database [--dbhost 0.0.0.0] [--dbport 1527] [--dbhome db_directory] [--echo=false] 
[--verbose=false]

  2. password.txt ファイルの場所 – 設計上、サンプルディレクトリは書き込み可能であると想定されています。これは、すべてのビルドコマンドにそのディレクトリでの password.txt ファイルの作成が含まれているためです。書き込み可能な場所にサンプルの作業用コピーをインストールするようにしてください。

8.0UR1PE から 8.2EE へのアップグレード中に LoginException が発生し、アップグレードプロセスが異常終了する (ID 6445419)

説明

この問題は、デフォルト以外の管理資格を使用してアップグレードインストールを実行すると発生します。

解決方法

ファイルベースのインストーラを使用して 8.xPE から 8.2EE への並列アップグレードを実行するとき、新しい Application Server 用には次の管理資格を使用してください。

アップグレードの実行後に、必要に応じてこれらのパスワードを変更できます。

アップグレードツールが「ソースインストールディレクトリ」フィールドの既存の無効なディレクトリ入力の検出に失敗する (ID 6460122)

説明

アップグレードツールが「ソースインストールディレクトリ」フィールドの既存の無効なディレクトリ入力の検出に失敗するので、ディレクトリ設定は正しいという印象を与えます。

想定では、「ソースインストールディレクトリ」に不正なパスを入力すると「無効なディレクトリ」というメッセージがポップアップ表示されるべきです。「ソースインストールディレクトリ」に /opt/SUNWappserverEE81UR2/ と入力すると、無効なディレクトリというメッセージが正しくポップアップ表示されます。しかし、/opt/SUNWappserverEE81UR2/domains と入力すると、パスが無効でも、アップグレードツールは警告を表示せずにアップグレードプロセスを続けます。この問題は、入力する値によって動作が異なるという点を除けば、ID 6440710 に似ています。

解決方法

Application Server 7 または 8.x から Application Server 8.2 にアップグレードするときは、マニュアルで推奨されている値でソースディレクトリをまずシードする必要があります。上書きアップグレードの場合はドメインルート、並列アップグレードの場合はドメインディレクトリです。

セミコロン (;) 文字の管理ユーザー名/管理パスワードを無効にすべきである (ID 6473341)

説明

Application Server Enterprise Edition 8.2 インストールでは、管理ユーザー名に特殊文字は使用できません。特殊文字を使用すると、ドメインの作成は失敗します。ただし、管理パスワードには特殊文字を使用できます。

解決方法

Application Server 7 から Application Server 8.2 にアップグレードするときに、管理ユーザー名に特殊文字が含まれていないことを確認してください。

Web コンテナ

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

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

説明

Microsoft Windows にアプリケーションを配備するときに JSP のプリコンパイルを要求すると、それ以降、そのアプリケーションの配備取り消しや、そのアプリケーション (または同一モジュール ID を持つ任意のアプリケーション) の再配備を試みても、予期したとおりに動作しません。この問題は、JSP のプリコンパイル処理でアプリケーションの JAR ファイルが開かれたまま閉じられないため、Microsoft 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 ファイルが解放されるため、再起動後の配備取り消しや再配備が成功します。

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

説明

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> を指定して、サーブレットの読み込み順序が問題にならないことを示します。

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

説明

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


at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.
exec(Execute.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.
executeExternalCompile(DefaultCompilerAdapter.java:448) 
at org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute
(JavacExternal.java:81) 
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842) 
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682) 
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:396)

解決方法

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

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

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

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

説明

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

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

このようなネットワークアーキテクチャーの場合、クライアントは、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.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.2 にある authPassthroughEnabled プロパティーにも適用されます。authPassthroughEnabled によって、認証目的に使用される可能性のある情報 (要求発信元の IP アドレスや SSL クライアント証明書など) を上書きすることが可能になるため、authPassthroughEnabled を TRUE に設定して Application Server Enterprise Edition 8.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 証明書を、それを要求している任意の配備されたアプリケーションに提供します。

--enabled=false で作成された HTTP リスナーが無効にならない。(ID 6190900)

説明

--enabled=false フラグで httplistener を作成すると、リスナーは無効になりません。フラグ --enabled は、リスナーの作成と同時に使用すると効果がありません。

解決方法

リスナーを使用可能状態で作成して、あとで手動で無効にしてください。

verify_file_user_exists_common が実行されないために、Windows での再配備が失敗する。(ID 6490227)

説明

Windows で、配備前にユーザーを作成するアプリケーションを再配備すると、verify_file_user_exists_common が呼び出されても実行されないために create-file-user コマンドが失敗することがあり、ユーザーがすでに存在することを通知することに失敗します。deploy ターゲットの実行はこの時点で停止し、配備と配備取消しが失敗します。

解決方法

まず keydel ターゲットを使用してファイルユーザーを削除し、次に deploy ターゲットをもう一度実行します。


asant keydel
asant deploy