test

Sun Java System Application Server Enterprise Edition 8.2 トラブルシューティングガイド

第 2 章 よくある問題

ここでは、Application Server の使用時に発生する可能性のある、最も一般的な問題について説明します。

.asadmintruststore ファイルがないためアップグレード時のバグの原因となる

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

解決法

削除された .asadmintruststore ファイルの復元

ドメインの .asadminstrustore ファイルの削除時に、インスタンスが存在している場合があります。そのような場合は、新しい .asadminstrustore ファイルを作成できます。

Procedure新しい .asadmintruststore ファイルを作成する

  1. asadmin start-domain コマンドを使用して、管理するドメインを起動します。

    これはローカルの asadmin コマンドなので、ドメインの起動に ~/.asadmintruststore ファイルは必要ありません。

  2. リモートの asadmin コマンドのいずれかを実行します。

    リモート asadmin コマンドは、---user、---passwordfile (--password)、---host、および ---port オプションをコマンド行に指定する必要のあるコマンドで、ターゲットドメインが稼働していることも必要です。よく使用するリモート asadmin コマンドは、asadmin list です。

  3. 確認画面で「y」と入力して、新しいドメイン証明書を受け入れます。

asadmin start-domain コマンドが失敗する

コマンド asadmin start-domain が、次のいずれかのエラーで失敗します。

Error: CLI143 ... には複数のドメインがあります

説明

引数を指定しないで実行すると、コマンド 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

Error: ドメインを起動できません

説明

このメッセージは 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 プラットフォーム上での自動再起動

ドメインの再起動

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 プラットフォーム上での自動再起動

Microsoft Windows 上で自動的に再起動するには、Windows サービスを作成します。Sun Java System Application Server に同梱されている実行可能ファイル appservService.exe と appserverAgentService.exe を、Microsoft が提供するサービス制御コマンド (sc.exe) と組み合わせて使用します。

ドメインの起動と停止

パスワードファイル 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 コマンドを使ってコンポーネントを開始および停止するようにしてください。

自動再起動時のセキュリティー

起動時に必要となるパスワードとマスターパスワードは、次のいずれかの方法を使って処理します。

ログファイルが見つからない

次の Application Server ログは、インストールの問題のトラブルシューティングに有効です。

ローカルサーバーのアクセスが失敗する (http://localhost:8080)

このエラーが発生したときは次の点をチェックします。

サーバーは起動したか ?

説明

コンソールウィンドウがまだ開いているなら、次のメッセージを探します。

Domain domain Started

このメッセージの domain は、デフォルトドメインの名前です。これは、デフォルトドメインが正常に起動したことを示します。

コンソールウィンドウがすでに閉じているなら、次のログファイルにメッセージがないかチェックします。

install_dir/domains/domain1/logs/server.log

起動が正常に行われた場合は、ログファイルの末尾にコンソールのメッセージに似た、次のようなメッセージが見つかります。

[INFO][...][..][date&time][Application server startup complete .]

サーバーは正しいポートで起動したか ?

説明

サーバーが、想定される番号とは異なるポートで稼働していることがあります。意図的にそのポートにインストールされたか、そのサーバーのインストール時にすでに別のサーバーがデフォルトポートで稼働していたと考えられます。

Procedureサーバーが実際に使用しているポート番号を調べる

  1. サーバーの設定ファイルを検査します。


    install_dir/domains/domain1/config/domain.xml

  2. http-listener 要素を見つけます。

  3. port 属性の値を調べます。

    サーバーの起動時には、必ず正しいポート番号を入力してください。

    注 –

    サーバーのデフォルトポート番号は 8080 ですが、次のような場合には、想定される値に変更が生じます。

    • インストール時に別のポート番号が指定された。

    • 以前のインストールが存在する。

    • 指定したポート番号が、サーバーの起動時に別のアプリケーションによってすでに取得されている場合、ポート番号は、次に利用可能な大きい番号になります。たとえば、サーバーがデフォルトの 8080 ポートですでに稼働している場合、新しい Application Server インスタンスではポート番号 8081 を使用します。2 つのサーバーが稼働しているなら、ポート番号は 8082 に増え、以下同様に変化していきます。

リモートサーバーへのアクセスが失敗する

Application Server の開始ページを開こうとしたとき、最初の画面が表示されません。

次の点をチェックします。

サーバーをローカルで使用できるか ?

説明

サーバーが、Web からはアクセスできないがローカルでは稼働している場合、そのサーバーは実際に稼働しています。

解決法

サーバーがローカルで稼働していることを確認します。

Procedureサーバーがローカルで稼働していることを確認する

  1. サーバーが実行されているマシンにログオンします。

  2. ローカルの Web ページに移動します。たとえば、デフォルトポートが 8080 の場合、次の場所に移動します。


    http://localhost:8080/

    開始ページが表示されるのであれば、サーバーにリモートでアクセスできない原因は Web 接続にあります。開始ページが表示されないときは、「サーバーは起動したか ?」を参照してください。

プロキシの設定が問題を引き起こしていないか ?

説明

通常、サーバーは、自分自身が稼働しているホスト (localhost) から直接アクセス可能です。たとえば、デフォルトポート 8080 を使用すると次のようになります。

http://localhost:8080/

解決法

サーバーホストマシンがプロキシ経由で Web に接続していると、localhost 上で稼働しているサーバーインスタンスにアクセスできないことがあります。この問題を解決するために、次のいずれかを行います。

注 –

localhost マシンのホスト名およびドメインを検索するには、次の手順に従います。

管理コンソールを表示できない

管理コンソールは、管理機能を実行するためのユーザーインタフェースです。管理コンソールを表示できない場合、その理由は次のいずれかと考えられます。

Application Server は稼働しているか ?

説明

管理コンソールを使用する前に、サーバーが稼働している必要があります。

解決法

「サーバーは起動したか ?」を参照して、サーバーが稼動中かどうか調べます。

想定されるポートで管理コンソールが実行されているか ?

説明

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 は稼働しているか ?

説明

Application Server が稼働していなければ、アプリケーションは使用できません。

解決法

「サーバーは起動したか ?」を参照して、サーバーが稼動中かどうか調べます。サーバーアプリケーションを使用する前に、サーバーが稼働している必要があります。

アプリケーションの配備は成功したか ?

説明

アプリケーションを使用するには、その前に配備を正常に行う必要があります。

解決法

次のサーバーのログファイルをチェックします。

install_dir/domains/domain1/server.log

Don't Prompt オプション使用時の無効なユーザーまたはパスワード

「無効なユーザーまたはパスワード」のエラーが表示されますが、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 内で暗号化されているため、読み取れません。)

Procedureユーザー名とパスワードを完全に削除する

  1. サーバーが稼働中であれば停止します。

  2. 適切な WEB-INF ディレクトリに移動します。次に例を示します。


    install_dir/lib/install/applications/adminapp/adminapp_war/WEB-INF

  3. web.xml ファイル内の <security-constraint\> 要素全体をコメントにします。

    あとで再度有効にできるように、要素の削除はしないでください。この操作により、コマンド行操作のセキュリティーが無効になります。

    注 –

    コマンド行で --username (または -u) と --password (または -w) に値を指定することに変わりはありませんが、サーバー側でセキュリティーはまったく要求されないので、ダミーの値でかまいません。

  4. サーバーを起動します。

    この時点で、サーバーにはコマンド行のセキュリティーがありません。

  5. 次のコマンドを実行します。


    asadmin create-file-user --user <dummy\> --password <dummy\>
 --userpassword <new_secret\> --groups asadmin <new_user_id\>

    このコマンドで、次のような新規エントリが作成されます。


    <install_dir\>/domains/domain1/config/keyfile

  6. web.xml ファイル内の <security-constraint\> 要素のコメントを解除します。

  7. サーバーを再起動して、新しいユーザー名 - パスワードを有効にします。

    注 –

    サーバーを起動する際、すべてのリモートコマンド行操作で、ユーザー名とパスワードとして new_user_id および new_secret の指定が必要です。

Windows 上でサーバーが起動しない (ポートの衝突)

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 でインスタンス用にランダムデバッグポートが選択されます。インスタンス用に選択されたポート番号は、起動時にサーバーログに表示されます。次に例を示します。

2 つのサーバーインスタンスが Windows 上の同じポートにバインドされる

説明

この問題は、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 システム上のすべてのサーバーインスタンスに、一意のポート番号を割り当てるようにします。

Error: 指定したパスがシステムで見つからない

説明

このエラーメッセージは、インストール時に指定した J2SE ディレクトリの削除後にサーバーを起動しようとすると表示されます。一般にこの状況は、J2SE プラットフォームのアップグレードが必要で、そのアップグレードは Application Server のインストール後に行われる、という通知がインストール中になされたあとに発生します。

解決法 1

すべてのドメインで新しい J2SE を使用するには、asenv.conf (Solaris/Linux) または asenv.bat (Windows) 内の AS_JAVA 変数を変更します。

解決法 2

J2SE のバージョンは、ドメインの domain.xml ファイルにある java-config 要素の java-home 属性を変更することによって、ドメインごとに変更できます。

<java-config ...
java-home="path"
...\>

解決法 3

これは時間のかかる解決法で、サーバーをアンインストールしてから再インストールします。

アプリケーションで Error persistence.support.JDODataStoreException が発生する

説明

com.sun.jdo.api.persistence.support.JDODataStoreException が、主キーの重複を示す入れ子にされた java.sql.SQLException とともに、アプリケーションから出力されます。

アプリケーションで CreateException の発生をチェックしていても、見つかることはありません。Enterprise JavaBeans の仕様上、同じ主キーを持つ 2 つの Bean が同じトランザクションで作成される場合にのみ、CreateException のスローが要求されます。したがって、主キーが重複する 2 つのエンティティー Bean が作成される場合でも、トランザクションロールバックで CreateException がスローされることはありません。

解決法

アプリケーションで主キーが重複するエンティティー Bean を作成する場合は、作成を呼び出す前に findByPrimaryKey を呼び出して主キーが存在するかどうかチェックします。

asadmin set コマンドを使用すると予期していない結果になることがある

説明

次のようなコマンドで変数を設定すると、予期していない結果が返されます。

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 に設定されますが、この結果には意味がありません。

jar ファイルへのストリームが開いているためにアプリケーションを配備解除または再配備できない (Windows のみ)

説明

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 のディレクトリを付属のアンインストールプログラムを利用しないで手動で削除すると、それ以降、同じディレクトリへの Application Server の再インストールが失敗します。これは、/tmp/productregistry ファイルに保存されたインストールディレクトリ情報が、プログラムディレクトリの削除後も残るからです。

解決法 1

/tmp/productregistry ファイルの <location\> プロパティーエントリから Application Server のディレクトリ情報を削除します。たとえば、次の行を変更します。

<location\>/opt/SUNWappserver/jdk</location\>

変更後は次のようになります。

<location\></location\>

解決法 2

Application Server を別のディレクトリに再インストールします。

サーバークラッシュ後に JVM スレッドダンプを生成できない

説明

Application Server がクラッシュすると、サーバーからコアファイルがダンプされ、デフォルトでは -Xrs フラグに基づいて再起動が行われますが、これにより JVM スレッドダンプの生成が妨げられます。

解決法

ProcedureJVM スレッドダンプを有効にする

  1. Application Server の server.xml ファイルにある -Xrs フラグをコメントにします。

  2. サーバープロセスを終了させます (UNIX では kill -3、Windows では Ctrl+Break)。

main スレッドでバンドル版の ANT から java.lang.NoClassDefFoundError がスローされる

Application Server 外の作業にバンドル版の Ant ディストリビューションを使用すると、main スレッドで java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher がスローされることがあります。

解決法

バンドル版の ANT を Application Server 環境外の作業に使用することはお勧めできません。

分解したアプリケーションファイルを変更しても /generated/xml ディレクトリは更新されない

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 をチェックして、アプリケーションが本当に再ロードされていることを再確認してください。