ここでは、Application Server の使用時に発生する可能性のある、最も一般的な問題について説明します。
「アプリケーションで Error persistence.support.JDODataStoreException が発生する」
「jar ファイルへのストリームが開いているためにアプリケーションを配備解除または再配備できない (Windows のみ)」
「main スレッドでバンドル版の ANT から java.lang.NoClassDefFoundError がスローされる」
.asadmintruststore ファイルがサーバー管理者のホームディレクトリに存在しないと、そのサーバー上にホストされている特定のアプリケーションをアップグレードしたときに重大なバグが発生する場合があります。
可能であれば、そのサーバーをインストールしたユーザーが asadmin start-domain domain1 コマンドを実行してください。
インストールユーザー以外が実行した場合、.asadmintruststore ファイルが、インストールユーザーのホームディレクトリから、実行ユーザーのホームディレクトリに移動またはコピーされます。
このファイルをインストールユーザーのホームディレクトリから実行中のユーザーのホームディレクトリに (コピーではなく) 移動した場合は、アップグレードまたはインストールしたユーザーのホームディレクトリ (Java ES では、通常 root) に .asadminstruststore ファイルが存在しなくなるため、バグ 6315957、6309079、6310428、および 6312869 で説明されているようなアプリケーションのアップグレードに関する問題が発生する可能性があることに注意してください。
ドメインの .asadminstrustore ファイルの削除時に、インスタンスが存在している場合があります。そのような場合は、新しい .asadminstrustore ファイルを作成できます。
asadmin start-domain コマンドを使用して、管理するドメインを起動します。
これはローカルの asadmin コマンドなので、ドメインの起動に ~/.asadmintruststore ファイルは必要ありません。
リモートの asadmin コマンドのいずれかを実行します。
リモート asadmin コマンドは、---user、---passwordfile (--password)、---host、および ---port オプションをコマンド行に指定する必要のあるコマンドで、ターゲットドメインが稼働していることも必要です。よく使用するリモート asadmin コマンドは、asadmin list です。
確認画面で「y」と入力して、新しいドメイン証明書を受け入れます。
コマンド asadmin start-domain が、次のいずれかのエラーで失敗します。
引数を指定しないで実行すると、コマンド asadmin start-domain は次のエラーで失敗します。
CLI143 There is more than one domain in C:\\Sun\\AppServer\\domains. Please use operand to specify the domain. CLI156 Could not start the domain null.
このエラーは、ドメインのディレクトリに複数のドメインがあり、そのいずれも domain1 という名前ではなく、start-domain コマンドでドメインが 1 つも指定されていない場合に発生します。
start-domain コマンドの実行時にドメインを指定します。
asadmin start-domain domain1
このメッセージは Application Server 8 から出力されます。メッセージ全体は次のいずれかのようになります。
Could not start the domain. There are no domains.
または、
Could not start the domain. No default domain. Need to enter a domain.
このエラーは、同じシステム上に Application Server 8 がインストールされており、PATH 上でその asadmin コマンド (/usr/sbin 内) のほうが、install_dir/bin にある Application Server 8 の asadmin コマンドより前に見つかる場合に発生します。こうした状況になる可能性が特に高いのは、Solaris/Linux システムで、PATH 変数の一部として . が指定されていない場合です。PATH 内に . がないと、カレントディレクトリが install_dir/bin であっても、/usr/sbin 内の asadmin コマンドが先に見つかります。
PATH の中で install_dir/bin を /usr/sbin より前に指定するか、または install_dir /bin ディレクトリに移動してから asadmin にアクセスする場合は、PATH の中で . を /usr/sbin より前に指定します。asadmin を実行する際には必ず install_dir/bin に移動するのであれば、コマンド名に ./ を含めるようにしてもかまいません。次に例を示します。
cd install_dir/bin ./asadmin |
マシンの再起動が必要になった場合など、ドメインまたはノードエージェントが予想外に停止される場合にそなえて、リブート時にドメインまたはノードエージェントが自動的に再起動されるようにシステムを設定することが可能です。
UNIX プラットフォーム上でドメインを再起動するには、適切な asadmin start-domain コマンドを含む行を /etc/inittab ファイルに追加します。/etc/rc.local またはシステム固有の同等のファイルを使用する場合は、目的の asadmin コマンドを /etc/rc.local に記述します。
たとえば、/opt/SUNWappserver ディレクトリにインストールされた Application Server 用の domain1 を password.txt という名前のパスワードファイルを使用して再起動するには、次の行を /etc/inittab または /etc/rc.local に追加します。
das:3:respawn:/opt/SUNWappserver/bin/asadmin start-domain --user admin --passwordfile /opt/SUNWappserver/password.txt domain1
テキストは必ず 1 行で記述してください。先頭の 3 文字はこのプロセスに対する一意の指示子ですが、これは変更可能です。
ノードエージェントを再起動する場合の構文も、これと似ています。たとえば、/opt/SUNWappserver ディレクトリにインストールされた Application Server 用の agent1 を password.txt という名前のパスワードファイルを使用して再起動するには、次の行を /etc/inittab または /etc/rc.local に追加します。
das:3:respawn:/opt/SUNWappserver/bin/asadmin start-node-agent --user admin --passwordfile /opt/SUNWappserver/password.txt agent1
Microsoft Windows 上で自動的に再起動するには、Windows サービスを作成します。Sun Java System Application Server に同梱されている実行可能ファイル appservService.exe と appserverAgentService.exe を、Microsoft が提供するサービス制御コマンド (sc.exe) と組み合わせて使用します。
sc.exe コマンドは Windows XP に同梱されており、C:\\windows\\system32、C:\\winnt\\system32 のいずれかのディレクトリに格納されています。
このマニュアルの執筆時点では、Windows 2000 の sc.exe を次の場所からダウンロードできます。ftp://ftp.microsoft.com/reskit/win2000/sc.zip。sc.exe の使い方の詳細は、次を参照してください。
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndllpro/html/msdn_scmslite.asp。
appservService.exe および appservAgentService.exe の使用方法は次のとおりです。
C:\\winnt\\system32\\sc.exe create service_name binPath= \\"fully_qualified_ path_to_appservService.exe \\"fully_qualified_path_to_asadmin.bat start_command\\" \\"fully_qualified_path_to_asadmin.bat stop_command\\"" start= auto DisplayName= "display_name" |
パスワードファイル C:\\Sun\\AppServer\\password.txt を使用して domain1 を起動および停止する、SunJavaSystemAppServer DOMAIN1 という名前のサービスを作成するには、次のコマンドを実行します。
C:\\windows\\system32\\sc.exe create domain1 binPath= "C:\\Sun\\AppServer\\ lib\\appservService.exe \\"C:\\Sun\\AppServer\\bin\\asadmin.bat start-domain --user admin --passwordfile C:\\Sun\\AppServer\\password.txt domain1\\" \\"C:\\Sun\\AppServer\\bin\\asadmin.bat stop-domain domain1\\"" start=auto DisplayName= "SunJavaSystemAppServer DOMAIN1" |
ノードエージェント agent1 を起動および停止するサービスを作成するには、次のコマンドを実行します。
C:\\windows\\system32\\sc.exe create agent1 binPath= "C:\\Sun\\AppServer\\ lib\\appservAgentService.exe \\"C:\\Sun\\AppServer\\bin\\asadmin.bat start-node-agent --user admin --passwordfile C:\\Sun\\AppServer\\ password.txt agent1\\" \\"C:\\Sun\\AppServer\\bin\\asadmin.bat stop-node-agent agent1\\"" start=auto DisplayName="SJESAS_SE8.1 AGENT1" |
binPath= パラメータの一部として入力された起動コマンドと停止コマンドは、正しい構文で記述されている必要があります。確認するには、それらのコマンドをコマンドプロンプトから実行します。コマンドを実行してもドメインまたはノードエージェントが正常に起動または停止されない場合、そのサービスは正しく動作しません。
また、asadmin の start/stop コマンドと service start/stop を混在させないでください。両者を混在させると、サーバーの状態の同期が取れなくなります。たとえば、サーバーのコンポーネントが実行されていないのに「コンポーネントが開始された」と表示されたりします。こうした状況を避けるには、サービス使用時には常に、sc.exe コマンドを使ってコンポーネントを開始および停止するようにしてください。
起動時に必要となるパスワードとマスターパスワードは、次のいずれかの方法を使って処理します。
Microsoft Windows 上で、ユーザーにパスワードを尋ねるようにサービスを設定します。
サービスコントロールパネルで、作成したサービスをダブルクリックします。
「プロパティ」ウィンドウの「ログオン」タブをクリックします。
「デスクトップとの対話をサービスに許可」にチェックマークを付け、必要なパスワードに対するプロンプトがコンポーネント起動時に表示されるようにします。
ログインしてプロンプトを表示させ、入力時にエントリがエコーバックされないことを確認する必要があります。これがサービスオプションを使用する際のもっとも安全な方法ですが、この方法の場合、ユーザーが関与しないとサービスが利用可能になりません。
デスクトップとの対話オプションを設定しなかった場合、サービスは「開始保留」状態のままになり、ハングアップしたように見えます。この状態から抜け出すには、このサービスのプロセスを終了してください。
Windows または UNIX 上で、--savemasterpassword=true オプションを使ってドメインを作成し、管理パスワード格納用のパスワードファイルを作成します。コンポーネント起動時に、--passwordfile オプションを使ってパスワードが格納されたファイルを指定します。asadmin start コマンドの --password オプションを使って管理パスワードを追加することもできます。この方法は、管理パスワードを平文で格納するため、安全性が低いことに注意してください。
次に例を示します。
ドメイン作成時にマスターパスワードを保存します。この構文では、ユーザーは管理パスワードとマスターパスワードの入力を求められます。
asadmin create-domain --adminport 4848 --adminuser admin --savemasterpassword=true --instanceport 8080 domain1 |
Windows の場合、サービスを作成します。その際、パスワードファイルを使って管理パスワードを提供します。
C:\\windows\\system32\\sc.exe create domain1 binPath= "C:\\Sun\\AppServer\\lib\\appservService.exe \\"C:\\Sun\\AppServer\\bin\\asadmin.bat start-domain --user admin --passwordfile C:\\Sun\\AppServer\\password.txt domain1\\" \\"C:\\Sun\\AppServer\\bin\\asadmin.bat stop-domain domain1\\"" start= auto DisplayName= "SJESAS_PE8.1 DOMAIN1" |
パスワードファイル password.txt のパスは、C:\\Sun\\AppServer\\password.txt です。このファイルには、パスワードが次の形式で格納されています。
AS_ADMIN_password=password |
たとえば、パスワードが adminadmin の場合、次のようになります。
AS_ADMIN_password=adminadmin |
UNIX の場合、inittab ファイルに追加する行の中で、--passwordfile オプションを使用します。
das:3:respawn:/opt/SUNWappserver/bin/asadmin start-domain --user admin --passwordfile /opt/SUNWappserver/password.txt domain1 |
パスワードファイル password.txt のパスは、/opt/SUNWappserver/password.txt です。このファイルには、パスワードが次の形式で格納されています。
AS_ADMIN_password=password |
たとえば、パスワードが adminadmin の場合、次のようになります。
AS_ADMIN_password=adminadmin |
次のようにして、コマンド行のオプションに指定したパスワードを使ってサービスを作成します。
C:\\windows\\system32\\sc.exe create domain1 binPath= "C:\\Sun\\AppServer\\ lib\\appservService.exe \\"C:\\Sun\\AppServer\\bin\\asadmin.bat start-domain --user admin --password adminadmin domain1\\" \\"C:\\Sun\\AppServer\\bin\\ asadmin.bat stop-domain domain1\\"" start=auto DisplayName="SJESAS_PE8.1 DOMAIN1" |
次の Application Server ログは、インストールの問題のトラブルシューティングに有効です。
HTTP サーバーアクセスログ — HTTP サーバーの問題のトラブルシューティング、および Application Server インスタンスに入力される HTTP 要求の処理の追跡に使用
インストール、アンインストールの両方のプログラムでログファイルが作成され、これらのファイルにインストールおよびアンインストールのすべてのイベントが記録されます。これらのログファイルの主な目的は、トラブルシューティング情報を提供することです。
インストールプログラムのメッセージとログファイルに加え、Solaris の pkginfo や showrev、Linux の rpm などのオペレーティングシステムユーティリティーを使用してシステム情報を収集できます。
ログファイルのエントリには、試行されたアクション、アクションの結果、および該当する場合には、失敗の原因についての情報が含まれます。ログファイルに含まれるメッセージエントリの種類は、次のとおりです。
INFO — これらのメッセージは、各インストールタスクが正常に完了したことを示します。
WARNING — これらのメッセージは重大でない失敗を示します。警告メッセージには、通常、失敗の原因および性質についての情報が含まれ、考えられる救済策も示されます。
ERROR — これらのメッセージは重大な失敗を示します。インストールまたはアンインストールの状態は「失敗」と報告されます。エラーメッセージには、通常、発生した問題の性質および原因についての詳細な情報が含まれます。
ドメイン固有のログは、install_dir/domains/domain1/logs/ にあります。一般のサーバーインストールのログファイルは、次の場所にあります。
Solaris、root ユーザーのインストール/アンインストール:
/var/sadm/install/logs
Solaris、root 以外のインストール/アンインストール:
/var/tmp
Linux インストール/アンインストール:
/var/tmp
Windows インストール/アンインストール:
%TEMP%
ログファイル名は製品の配布形態ごとに異なりますが、プラットフォームとは無関係です。
Enterprise Edition の SDK と Application Server 両方の配布では、メインのインストール/アンインストールログファイルは次のようになります。
Install_Application_Server_8PE_<timestamp\>.log Uninstall_Application_Server_8PE_<timestamp\>.log
Enterprise Edition の Application Server のみの配布では、低レベルのインストール/アンインストールログファイルは次のようになります。
Sun_Java_System_Application_Server_Platform_Edition_install.B<timestamp\> Sun_Java_System_Application_Server_Platform_Edition_uninstall.B<timestamp\>
Enterprise Edition の SDK の配布では、低レベルのインストール/アンインストールログファイルは次のようになります。
Java_2_Platform__Enterprise_Edition_1.4_SDK_install.B<timestamp\> Java_2_Platform__Enterprise_Edition_1.4_SDK_uninstall.B<timestamp\>
Enterprise Edition のメインのインストール/アンインストールログファイルは次のようになります。
Install_Application_Server_8EE_<timestamp\>.log Uninstall_Application_Server_8EE_<timestamp\>.log
Enterprise Edition の低レベルのインストール/アンインストールログファイルは次のようになります。
Sun_Java_System_Application_Server_Enterprise_Edition_ install.B<timestamp\> Sun_Java_System_Application_Server_Enterprise_Edition_ uninstall.B<timestamp\>
このエラーが発生したときは次の点をチェックします。
コンソールウィンドウがまだ開いているなら、次のメッセージを探します。
Domain domain Started
このメッセージの domain は、デフォルトドメインの名前です。これは、デフォルトドメインが正常に起動したことを示します。
コンソールウィンドウがすでに閉じているなら、次のログファイルにメッセージがないかチェックします。
install_dir/domains/domain1/logs/server.log
起動が正常に行われた場合は、ログファイルの末尾にコンソールのメッセージに似た、次のようなメッセージが見つかります。
[INFO][...][..][date&time][Application server startup complete .]
サーバーが、想定される番号とは異なるポートで稼働していることがあります。意図的にそのポートにインストールされたか、そのサーバーのインストール時にすでに別のサーバーがデフォルトポートで稼働していたと考えられます。
サーバーの設定ファイルを検査します。
install_dir/domains/domain1/config/domain.xml |
http-listener 要素を見つけます。
port 属性の値を調べます。
サーバーの起動時には、必ず正しいポート番号を入力してください。
サーバーのデフォルトポート番号は 8080 ですが、次のような場合には、想定される値に変更が生じます。
インストール時に別のポート番号が指定された。
以前のインストールが存在する。
指定したポート番号が、サーバーの起動時に別のアプリケーションによってすでに取得されている場合、ポート番号は、次に利用可能な大きい番号になります。たとえば、サーバーがデフォルトの 8080 ポートですでに稼働している場合、新しい Application Server インスタンスではポート番号 8081 を使用します。2 つのサーバーが稼働しているなら、ポート番号は 8082 に増え、以下同様に変化していきます。
Application Server の開始ページを開こうとしたとき、最初の画面が表示されません。
次の点をチェックします。
サーバーが、Web からはアクセスできないがローカルでは稼働している場合、そのサーバーは実際に稼働しています。
サーバーがローカルで稼働していることを確認します。
サーバーが実行されているマシンにログオンします。
ローカルの Web ページに移動します。たとえば、デフォルトポートが 8080 の場合、次の場所に移動します。
http://localhost:8080/ |
開始ページが表示されるのであれば、サーバーにリモートでアクセスできない原因は Web 接続にあります。開始ページが表示されないときは、「サーバーは起動したか ?」を参照してください。
通常、サーバーは、自分自身が稼働しているホスト (localhost) から直接アクセス可能です。たとえば、デフォルトポート 8080 を使用すると次のようになります。
http://localhost:8080/
サーバーホストマシンがプロキシ経由で Web に接続していると、localhost 上で稼働しているサーバーインスタンスにアクセスできないことがあります。この問題を解決するために、次のいずれかを行います。
localhost にアクセスするときはプロキシサーバーをバイパスするようにブラウザを設定します。設定手順については、ブラウザのヘルプシステムを参照してください。
システムの完全修飾ホスト名または IP アドレスを使用します。次に例を示します。
http://myhost.mydomain.com:8080/ |
localhost マシンのホスト名およびドメインを検索するには、次の手順に従います。
Microsoft Windows の場合 — デスクトップで「マイ コンピュータ」を右クリックし、ポップアップメニューから「プロパティ」を選択します。「システムのプロパティ」ダイアログが表示されます。「ネットワーク ID」をクリックするとコンピュータ名が表示されます。
Solaris または Linux の場合 — コマンドプロンプトに hostname と入力します。
管理コンソールは、管理機能を実行するためのユーザーインタフェースです。管理コンソールを表示できない場合、その理由は次のいずれかと考えられます。
管理コンソールを使用する前に、サーバーが稼働している必要があります。
「サーバーは起動したか ?」を参照して、サーバーが稼動中かどうか調べます。
EE および SE の管理コンソールのデフォルトポート番号は 4849 です。PE の管理コンソールでは 4848 です。EE および SE のコンソールの URL には Secure HTTP (https://servername:4849) が必要なことにも注意してください。これに対し、PE のコンソールでは標準 HTTP (http://servername:4848) を使用します。ただし、意図的に別のポート番号にインストールされたか、サーバーの起動時にポートが使用中だったという理由で、想定されていない別のポート番号上で管理コンソールが実行されることもありえます。
「サーバーは正しいポートで起動したか ?」にある、管理コンソールを実行するポートを確認するためのガイドラインを参照し、正しいポート番号と HTTP プロトコルを入力して管理コンソールを呼び出すようにします。
J2EE 1.4 仕様上、セキュリティーマネージャーは省略できません。Application Server で有効になっている必要があります。Application Server にセキュリティーマネージャーを無効にする設定インタフェースはないため、domain.xml 設定ファイルから次の行を削除するという直接的な編集操作を行わないかぎり無効にはできません。
<jvm-option\>-Djava.security.policy=yourPolicy</jvm-option\>
管理コンソールを表示するには、domain.xml ファイルに -Djava.security.policy=yourPolicy オプションが存在する必要があります。
Application Server 経由で特定のアプリケーションを使用できない場合は、次の点をチェックします。
Application Server が稼働していなければ、アプリケーションは使用できません。
「サーバーは起動したか ?」を参照して、サーバーが稼動中かどうか調べます。サーバーアプリケーションを使用する前に、サーバーが稼働している必要があります。
アプリケーションを使用するには、その前に配備を正常に行う必要があります。
次のサーバーのログファイルをチェックします。
install_dir/domains/domain1/server.log
「無効なユーザーまたはパスワード」のエラーが表示されますが、Don't Prompt オプションを指定してシステムをインストールした場合、パスワードは自動的に入力されます。
インストール時に適切なパスワードを指定しなかったか、ドメインの起動時にパスワードが渡されていない可能性があります。
.asadminprefs ファイル内のパスワードをチェックします。UNIX/Linux システムでは、このファイルはサーバーがインストールされた、ユーザーのホームディレクトリにあります。Windows では、C:\\Documents and Settings\\username にあります。ファイルの内容は次のようになっています。
AS_ADMIN_USER=admin AS_ADMIN_PASSWORD=administrator
管理者のユーザー名を忘れた場合は、前記のセクションの説明に従って .adminprefs ファイル内を検索して見つけることができます。install_dir/domains/domain1/config/keyfile を調べることもできます。domain1 はデフォルトドメインです。別のドメインの場合は、パス内の名前を置き換えてください。
管理者のパスワードを忘れた場合は、以前のユーザー名とパスワードを削除して新規に作成し、サーバーを再起動することで、新しいユーザー名とパスワードのペアを使用する必要があります。(パスワードは keyfile 内で暗号化されているため、読み取れません。)
サーバーが稼働中であれば停止します。
適切な WEB-INF ディレクトリに移動します。次に例を示します。
install_dir/lib/install/applications/adminapp/adminapp_war/WEB-INF |
web.xml ファイル内の <security-constraint\> 要素全体をコメントにします。
あとで再度有効にできるように、要素の削除はしないでください。この操作により、コマンド行操作のセキュリティーが無効になります。
コマンド行で --username (または -u) と --password (または -w) に値を指定することに変わりはありませんが、サーバー側でセキュリティーはまったく要求されないので、ダミーの値でかまいません。
サーバーを起動します。
この時点で、サーバーにはコマンド行のセキュリティーがありません。
次のコマンドを実行します。
asadmin create-file-user --user <dummy\> --password <dummy\> --userpassword <new_secret\> --groups asadmin <new_user_id\> |
このコマンドで、次のような新規エントリが作成されます。
<install_dir\>/domains/domain1/config/keyfile |
web.xml ファイル内の <security-constraint\> 要素のコメントを解除します。
サーバーを再起動して、新しいユーザー名 - パスワードを有効にします。
サーバーを起動する際、すべてのリモートコマンド行操作で、ユーザー名とパスワードとして new_user_id および new_secret の指定が必要です。
Microsoft Windows で Application Server の起動時に次のようなメッセージが表示された場合は、サーバーポートの衝突が発生しています。
Address already in use
このエラーは、Application Server ポート (デフォルトは 8080) 上で別のアプリケーションが実行されているか、Application Server の以前のインスタンスが正常な方法でシャットダウンしなかった場合に発生します。
それで次の点をチェックします。
別のアプリケーションがサーバーのポートを使用している場合は、そのアプリケーションを停止してから Application Server を再起動します。
インストーラには、デフォルトポートが使用中の場合に次に利用可能なポートを選択することによってポートの衝突を回避する機能がありますが、それが機能するのは、デフォルトポートを使用するアプリケーションが、Application Server のインストール時に実行されていた場合だけです。
asadmin stop-domain コマンドを使用してサーバーを停止するか、Java プロセスを kill で明示的に終了してから Application Server を再起動します。
同じサーバー上にあり同じクラスタに属する複数のインスタンスをデバッグしているときに、ポートの衝突エラーが発生することがあります。
domain.xml ファイルを変更して、クラスタの java-config 要素にある -Xrunjdwp オプションから address 属性を削除します。これにより、JVM でインスタンス用にランダムデバッグポートが選択されます。インスタンス用に選択されたポート番号は、起動時にサーバーログに表示されます。次に例を示します。
変更前:
debug-options="-Xdebug -Xrunjdwp:transport=dt_socket,server=y, suspend=n,address=9009"
変更後:
debug-options="-Xdebug -Xrunjdwp:transport=dt_socket,server=y, suspend=n"
この問題は、Application Server Enterprise Edition (Platform Edition ではない) ソフトウェアを実行する Windows 2000/XP システムでのみ発生し、Application Server の問題というよりも Windows の既知のセキュリティーバグに原因があります。
Application Server の 2 つ以上のインスタンスを、instanceport オプションに同じポート番号を指定して作成すると、この問題が発生します。次に例を示します。
asadmin create-domain -adminport 5001 <options\> -instanceport 6001 <domain\ asadmin create-domain -adminport 5002 <options\> -instanceport 6001 <domain\>
2 つのドメインを UNIX/Linux システム上で起動すると、ポートの衝突エラーがスローされ、2 つめのインスタンスの起動は失敗します。これに対し、2 つのドメインを Windows 2000/XP 上で起動すると、エラーがスローされずに両方のサーバーインスタンスが起動しますが、指定したポートでは最初のインスタンスしか利用できません。その後、最初のサーバーインスタンスがシャットダウンすると、2 つめのインスタンスが利用可能になります。さらに、両方のインスタンスが稼働している場合、Windows の netstat コマンドでは重複したリスナーがアクティブとして示されますが、要求に応答できるのは最初のリスナーのみです。
Windows システム上のすべてのサーバーインスタンスに、一意のポート番号を割り当てるようにします。
このエラーメッセージは、インストール時に指定した J2SE ディレクトリの削除後にサーバーを起動しようとすると表示されます。一般にこの状況は、J2SE プラットフォームのアップグレードが必要で、そのアップグレードは Application Server のインストール後に行われる、という通知がインストール中になされたあとに発生します。
すべてのドメインで新しい J2SE を使用するには、asenv.conf (Solaris/Linux) または asenv.bat (Windows) 内の AS_JAVA 変数を変更します。
J2SE のバージョンは、ドメインの domain.xml ファイルにある java-config 要素の java-home 属性を変更することによって、ドメインごとに変更できます。
<java-config ... java-home="path" ...\>
これは時間のかかる解決法で、サーバーをアンインストールしてから再インストールします。
com.sun.jdo.api.persistence.support.JDODataStoreException が、主キーの重複を示す入れ子にされた java.sql.SQLException とともに、アプリケーションから出力されます。
アプリケーションで CreateException の発生をチェックしていても、見つかることはありません。Enterprise JavaBeans の仕様上、同じ主キーを持つ 2 つの Bean が同じトランザクションで作成される場合にのみ、CreateException のスローが要求されます。したがって、主キーが重複する 2 つのエンティティー Bean が作成される場合でも、トランザクションロールバックで CreateException がスローされることはありません。
アプリケーションで主キーが重複するエンティティー Bean を作成する場合は、作成を呼び出す前に findByPrimaryKey を呼び出して主キーが存在するかどうかチェックします。
次のようなコマンドで変数を設定すると、予期していない結果が返されます。
asadmin set name={$a-b}
この場合、name は {$a-b} ではなく b に設定されます。シェル構文 ${a=b} は「変数 a が未設定ならば、値 b を代わりに使う、そうでなければ a の値を代わりに使う」と解釈されるからです。これは標準のシェル動作です。たとえば、次の例を考えてください。
asadmin set default-config.http-service.http-listener.http-listener-1.port= ${http-listener-1-port}
この場合、default-config.http-service.http-listener.http-listener-1.port は listener-1-port に設定されますが、この結果には意味がありません。
Windows システムでは、アプリケーションの実行後引き続きそのアプリケーションを配備解除または再配備しようとすると、サーバーでファイルの削除やディレクトリ名の変更を行えないという例外がスローされます。
Windows システムでは、アプリケーションで getClass().getResource または getResourceAsStream メソッドを使用して、アプリケーション内部のリソース、特にアプリケーション内にあるまたはアプリケーションからアクセス可能な jar ファイルのリソースを取得できます。ストリームが開いたままになっていると、それ以降のアプリケーションの再配備または配備解除が失敗する可能性があります。加えて、Java ランタイムは、パフォーマンス上の理由からデフォルトで jar ファイルへのストリームをキャッシュします。
アプリケーションで開いたストリームは必ず閉じてください。さらに、アプリケーションの再配備または配備解除を繰り返し行う必要があり、アプリケーションで getResource または getResourceAsStream を使用して jar ファイルからリソースを取得する必要もある場合は、URL オブジェクトを返す getClass().getResource の使用を検討してください。その後、url.setUseCaches メソッドを呼び出してその jar ファイルのキャッシュを無効にしてから、url.getInputStream() を使用してストリームを取得します。
jar ファイルアクセスのキャッシュを無効にするとパフォーマンスが低下することがありますが、この手法により確実にアプリケーションを配備解除または再配備できます。getClass().getResourceAsStream メソッドを代わりに使用すると、リソースが存在する jar ファイルがキャッシュされ (これがデフォルトの Java ランタイム設定)、サーバーが停止するまで開いたままになることにも注意してください。
Application Server のディレクトリを付属のアンインストールプログラムを利用しないで手動で削除すると、それ以降、同じディレクトリへの Application Server の再インストールが失敗します。これは、/tmp/productregistry ファイルに保存されたインストールディレクトリ情報が、プログラムディレクトリの削除後も残るからです。
/tmp/productregistry ファイルの <location\> プロパティーエントリから Application Server のディレクトリ情報を削除します。たとえば、次の行を変更します。
<location\>/opt/SUNWappserver/jdk</location\>
変更後は次のようになります。
<location\></location\>
Application Server を別のディレクトリに再インストールします。
Application Server がクラッシュすると、サーバーからコアファイルがダンプされ、デフォルトでは -Xrs フラグに基づいて再起動が行われますが、これにより JVM スレッドダンプの生成が妨げられます。
Application Server の server.xml ファイルにある -Xrs フラグをコメントにします。
サーバープロセスを終了させます (UNIX では kill -3、Windows では Ctrl+Break)。
Application Server 外の作業にバンドル版の Ant ディストリビューションを使用すると、main スレッドで java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher がスローされることがあります。
バンドル版の ANT を Application Server 環境外の作業に使用することはお勧めできません。
JES Service Registry (SR) は、JES 5 リリースの一部として Application Server 8.2 Enterprise Edition に配備されます。SR では、クライアント証明書認証を使用して、登録ユーザーを認証します。SR には、Application Server の TrustStore に格納されている RegistryOperator 証明書によって署名された x509 証明書を生成するオプションがあります。
問題は、このクライアント証明書認証手法が、生成される /generated/xml ディレクトリの sun-web.xml ファイルの場所に依存しているということです。配備したアプリケーションを分解して再配備すると、SR 側で sun-web.xml ファイルを検索する場所を知ることはできなくなります。
配備後の配備記述子の変更は推奨されていません。配備後に配備記述子を変更する必要がある場合は、.reload 機能を使用してアプリケーションの再ロードを強制します。Service Registry 製品の場合は、ログイン情報が含まれるようにドメインの web.xml ファイルを変更する必要もあります。ログインで問題が発生している場合は、server.log をチェックして、アプリケーションが本当に再ロードされていることを再確認してください。