- 環境設定ツールを使用して環境設定を行う時の注意事項について説明します。
- Unix での Webコンテナ起動環境において、環境変数 "LANG" が日本語環境に設定されていないと 運用管理画面のエラー画面が文字化けすることがあります。
確認方法：
su - Webコンテナ起動ユーザ名 -c env | grep LANG
- 運用管理コンソールの Web Applicationの管理から、Webアプリケーション(WARファイル)を転送できますが、ここで存在しないファイルを指定すると、ドメインの
applications/j2ee-modules 配下に 0バイトのファイルが作成されます。 運用管理コンソールの Web Applicationの管理から削除を行ってください。
- 統合運用管理ツールからは、Webアプリケーションのreloadができません。
クラスファイルの変更等がある場合には、Webアプリケーションを配備解除し、WARファイルを再配備してください。配備解除、再配備には運用管理コマンドもしくは、統合運用管理ツールを利用してください。
- 統合運用管理ツールから、従来の Web版運用管理コンソール（http://host_name:4848/admin/）が表示していた統計情報は参照できません。単位時間あたりの統計情報を参照したい場合は、引き続き
Web版運用管理コンソールをご利用ください。
- Sun Java System Web Server 6.1（以降、Sun JSW と記述）と連携したとき、Sun JSW のエラーログに以下のようなログが記録されます。
After get int 7/9/8192 0 0 0 0 - 0 0 0 ff - ff ff ff 0 - 2f 1 0 6 7
[https-localhost]: info: CORE3282: stdout: 0 0 0 0 - 0 0 0 0 --- 0 0 ff ff
- ff ff 0 2f [https-localhost]: info: CORE3282: stdout: ERROR
これは、Sun JSW から Webコンテナに対して不要なアクセスが発生しているためですが、Webコンテナの動作に問題はありません。 このメッセージを記録しないようにしたいときは、Sun
JSW の管理コンソールにアクセスし、「Log > Error Log Preferences」画面で Log Level を "warning"
に設定してください。
- IIS + Webコンテナの環境で、IIS の基本認証の設定ができていないと運用管理コンソールにログインできません。以下の作業を行ってください。
- IIS で基本認証を有効にする
IIS 5.0 の場合
IIS の「インターネット サービス マネージャ」を起動し、動作させている Webサーバのプロパティ画面を開きます。 このプロパティ画面で「ディレクトリ セキュリティ」画面を表示し、「匿名アクセスおよび認証コントロール」の「編集」ボタンを押下して「認証方法」画面を表示します。
「認証方法」画面で、「基本認証」を有効にし、「統合 Windows認証」を無効にします。その他の項目はそのままで結構です。
IIS 6.0 の場合
IIS の「インターネット サービス マネージャ」を起動し、動作させている Webサーバのプロパティ画面を開きます。 このプロパティ画面で「ディレクトリ セキュリティ」画面を表示し、「認証とアクセス制御」の「編集」ボタンを押下して「認証方法」画面を表示します。
「認証方法」画面で、「基本認証」を有効にし、「統合 Windows認証」を無効にします。その他の項目はそのままで結構です。
- アカウント情報を作成/修正する
IIS で基本認証を行う場合、Windowsシステムに認証を行うユーザが登録されている必要があります。 以下のいずれかの方法が対応してください。
- Windowsシステムに、Webコンテナの認証に使うユーザを登録する。ユーザ名とパスワードはドメイン作成時に指定したものです。
- ドメインの管理ユーザにシステムのログインユーザを設定する。
ドメインの管理ユーザのユーザ名とパスワードを、システムのログインユーザと同じものに設定します。
- IIS + Webコンテナの環境で、リクエストURLに「/scripts/jrun.dll/」という文字列が先頭に付加されている場合にJSPファイルを実行するとエラー(404)が発生します。
この現象は IIS ＋ Jrun の環境を過去に構築した事があると発生します。 IIS の script ディレクトリに「jrun.ini」があるので、その中で「scripts/jrun.dll」の文字列が付加されていれば、「jrun.ini」を削除(待避)してください。
また、コンテキストの動的反映がOFF（ajp13_originalを指定）でマシン再起動などで WebOTX のドメインと外部Webサーバが同時に起動するような場合、タイミングによっては 404エラーが発生する場合があります。ドメインは起動時に毎回配備されているアプリケーションの内容をプラグインの連携設定用ファイルに書き出しますが、ドメインがこの連携設定用ファイルを更新するタイミングで外部Webサーバのプラグインがアクセスしてしまう場合があるためです。
このような現象が発生する場合は外部Webサーバの起動タイミングを数秒遅らせる等の対応をお願いします。
- IIS と連携している時、Webサイトの設定でディレクトリセキュリティの「認証方法」で“匿名アクセスを有効にする”のチェックを外している場合、servlets-examples
など一般の Webアプリケーション へのアクセス時にも認証が必要となります。これは、IIS へのアクセスに関して認証が要求されているという事ですので、システムに存在するいずれかのユーザでログインしてください。
- IIS 6.0 と連携する場合、通常の IIS との連携のための設定に加えて次の設定が必要です。
- インターネットインフォメーションサービスの運用画面で左のツリーから「Webサービスの拡張」を選択します。右画面に Webサービスの拡張状態が表示されますので、タスクとして「新しい
Webサービス拡張を追加...」を押下します。 開いた「新しい Webサービス拡張」画面で「拡張名」に“Webコンテナ用ISAPIモジュール”と入力します。また、必要なファイルに、WebOTX Application Serverのインストールディレクトリ配下の
bin\win32\i386\isapi_redirect.dll を指定します。そして「拡張の状態を許可済みに設定する」をチェックしてください。
- IIS連携時に、JKコネクタ（Webサーバプラグイン）のログが指定しているディレクトリに出力されない場合があります。
次の処理を行ってください。
- <INSTALL_DIR>\domains\<ドメイン名>\logsの「プロパティ」を開き、「セキュリティ」タブで「追加」ボタンをクリックします。
- 「ユーザーまたはグループの選択」ダイアログで自マシンの NETWORK SERVICE を選択し OK します。
- 「詳細設定」ボタンをクリックします。
- 「セキュリティの詳細設定」ダイアログの「アクセス許可」タブで「追加」ボタンをクリックします。
- 「ユーザーまたはグループの選択」ダイアログで自マシンの NETWORK SERVICE を選択し OK します。
- 「アクセス許可エントリ」ダイアログの「適用先」で「このフォルダとサブフォルダ」を選択し、「アクセス許可」で「ファイルの作成/データの書き込み」と「フォルダの作成/データの追加」をチェックして
OK します。
- 「セキュリティの詳細設定」ダイアログ、「プロパティ」を OK して閉じます。
- Sun ONE Web Server と連携する時は、事前に Sun ONE Web Server 付属 (内蔵) の Servlet/JSP
コンテナを無効にする必要があります。設定方法は、Sun ONE Web Server のドキュメントを参照してください。
さらに、内蔵の Servlet/JSP コンテナを無効にした後で、Webサーバの設定ファイルから次の記述を手動で削除（またはコメントアウト）してください。
<Object name="servlet">
ObjectType fn="force-type" type="text/html"
Service fn="NSServletService"
</Object>
|
- Webサーバの連携解除について
Webコンテナをアンインストールしても 連携する Webサーバの設定が残っています。そのまま Webサーバを使い続けた場合、システムによっては Webサーバが正常に起動しなくなる可能性があります。特に
Unix 環境で Webサーバを自動起動に設定している場合、最悪 Unix が起動しなくなる恐れがあります。
連携する Webサーバごとの設定解除方法を次に説明します。
[ Sun Java System Web Server (Sun ONE) の場合 ]
Webコンテナをアンインストールした後、Sun Java System Web Server (Sun ONE) のインストールディレクトリの「使用する
Webサーバ名」のディレクトリ（https-<使用するサーバ名>）の config 配下にある obj.conf を修正します。以下のキーワードに囲まれた行を削除します。"TM_WS_PLUGIN_INIT"
は、同じディレクトリの magnus.conf にあります。
# TM_WS_PLUGIN_INIT-start
Init fn="load-modules" funcs="jk_init,jk_nametrans,jk_service" shlib="<WEBOTX_HOME>/bin/<NSAPIモジュール名>"
Init fn="jk_init" worker_file="<WEBOTX_DOMAIN_HOME>/config/WebCont/workers.properties" worker_mount_file="<WEBOTX_DOMAIN_HOME>/c
onfig/WebCont/uriworkermapNS.properties-auto" log_level="error" log_file="<WBOTX_DOMAIN_HOME>/logs/nsapi.log"
# TM_WS_PLUGIN_INIT-end
# TM_WS_PLUGIN_MAP-start
NameTrans fn="jk_nametrans" name="servlet"\
# TM_WS_PLUGIN_MAP-end
# TM_WS_PLUGIN_EXEC-start
<Object name="servlet">
ObjectType fn=force-type type=text/html
Service fn="jk_service" worker="ajp13" path="/*"
</Object>
# TM_WS_PLUGIN_EXEC-end
|
※なお、Sun Java Web Server の管理コンソールから設定ファイルを更新するなどしてコメントが無くなっている場合や、同じ定義が複数記述されている場合も
ありますので、上記内容を手がかりに記述を削除してください。
- Windows2000 + IIS5.0 の環境で、イベントビューワに次のログが出力されますが、これは互換性を注意する情報であり動作に問題はありません。
「IISの以前のバージョンとの互換性のため、フィルタ、 C:\Programfiles\NEC\WebOTX\bin\win32\i386\isapi_redirect.dll
はレジストリからグローバルフィルタとして読みこまれました。 インターネットサービスマネージャでフィルタを制御するには、レジストリからフィルタを削除して、インターネットサービスマネージャでグローバルフィルタとして追加してください。」
- Sun Java System Web Server (Sun ONE) と連携する時、Webコンテナの連携設定が終わった後でそれぞれの Webサーバの運用管理を使用して
Webサーバの設定を更新した場合、Webコンテナの連携設定部分を示すコメントが失われてしまう事があります。このコメントが失われると、以降 Webコンテナの連携設定の更新が正常に行えません。このため、これらの
Webサーバと連携する場合、事前に Webサーバの設定ファイルのバックアップを取っておいてください。
Webコンテナの連携設定が行えなくなった場合は、Webサーバの設定ファイルをリストアし、もう一度 Webコンテナの環境設定をやり直してください。
もし Webサーバの設定ファイルが不正になりバックアップもない場合は、次の方法で修正してください。
Webサーバの設定ファイル内の Webコンテナ独自のコメント（# で始まる。以下を参照）に囲まれていない、次のキーワードで始まる行をすべて削除した後、環境設定を行ってください。
Sun Java System Web Server (Sun ONE) と連携した場合：
設定ファイルは、Sun Java System Web Server (Sun ONE) のインストールディレクトリの「使用する Webサーバ名」のディレクトリ（https-<使用するサーバ名>）の
config 配下にある obj.conf です。"TM_WS_PLUGIN_INIT" は、同じディレクトリの magnus.conf
にあります。
#TM_WS_PLUGIN_INIT-start から -end
Init fn="load-modules" funcs="jk_init,jk_service" shlib=...
|
#TM_WS_PLUGIN_INIT-start から -end
Init fn="jk_init" worker_file=...
|
#TM_WS_PLUGIN_MAP-start から -end
NameTrans fn="assign-name" from=...
|
#TM_WS_PLUGIN_EXEC-start から -end
<Object name="servlet">
ObjectType fn=force-type type=text/html
Service fn="jk_service" worker="ajp13" path="/*"
</Object>
|
- 内蔵Webサーバ（JavaベースのWebサーバ）以外（WebOTX Web Server、IISなど）のWebサーバと連携したときには、複数のvirtual
serverは利用できません。
- Webサーバと連携中に配備解除したWebアプリケーションにアクセスするなどした場合(通常は HTTP404エラー)、ブラウザの設定によりダウンロード処理が始まることがあります。
ブラウザの設定を変更することで回避することができます。
例) IE6の場合
メニューより「ツール」-「インターネットオプション」-「詳細設定」で「ブラウズ」-「HTTPエラーメッセージを簡易表示する」のチェックをONにする。
- Webアプリケーションにルートコンテキスト(/)を割当てて配備した場合、ドメインを再起動しないとアクセスできません。また、別のWebアプリケーションをルートコンテキスト("/")へ配備した場合も、ドメインの再起動が必要です。
Webアプリーションの配備後にドメインを再起動してください。外部のWebサーバ（Aapche等）と連携している場合には、外部のWebサーバも再起動が必要です。
- Webアプリケーションにルートコンテキスト(/)を割当てて配備した場合、そのWebアプリケーションは停止できません。
- Servlet API 仕様 2.4 に準拠したWebアプリケーションで、web.xml に空の <load-on-startup>要素を含む場合は、そのWebアプリケーション（war）は配備できません。
- 既存の Servlet API 仕様 2.2 および 2.3 に準拠した Webアプリケーションを利用する時の注意点を以下に説明します。
- commons-logging.jar を含む場合
WARファイル内に commons-logging.jar を含む場合、その WARファイルをそのまま配備すると 404 エラーが発生して正常に動作しません。これは、WARファイルの
WEB-INF/lib に commons-logging.jar が存在すると、クラスローダの関係で Webコンテナから commons-logging.jar
が参照できなくなるためです。これを回避するには、
- commons-logging.jar を WARファイル内から削除する
- WARファイル内に nec-web.xml を追加する
のいずれかの対処が必要になります。
commons-logging.jar は WebOTX Application Server に最初から同梱されていますので、特に理由がないのであれば、WARファイル内から
commons-logging.jar を削除することで問題を回避できます（１）。
または、WARファイル内に以下の記述内容を持つ nec-web.xml という名前のファイルを追加します（<コンテキストパス>
部分は Webアプリケーションに合わせて設定してください）。このファイルは WEB-INF 直下に追加します（２）。
<nec-web-app xmlns="http://java.sun.com/xml/ns/j2ee">
<context-root>コンテキストパス</context-root>
<class-loader delegate="true"/>
</nec-web-app>
- WebOTX Developer V7.1に付属する「ファイル転送サンプル」を実行する場合、実行に先立って次のポリシーをドメインディレクトリの config/server.policy
に追加してください。
grant {
permission java.io.FilePermission
"${com.nec.webotx.instanceRoot}${/}applications${/}j2ee-modules${/}fileupdownload${/}-", "read,write,delete";
};
- Webアプリケーションを配備すると、内部では Webアプリケーション名とコンテキストルートの２つで Webアプリケーションを識別します。これらは、配備済みの
Webアプリケーションと同じ名称を指定する事はできません。Webアプリケーション毎に一意の指定をしてください。
- JSP を含む Webアプリケーション を実行すると、パーミッションエラーで JSP のコンパイルが失敗する事があります。この場合、使用する JDK
のバージョンに合ったクラスが使用されているかを確認してください。具体的には、利用している JDK に付属の tools.jar が使用されているかを確認します。異なったバージョンの
tools.jar がクラスパスに指定されていると正しくコンパイルできない恐れがあります。
- Webコンテナで設定できる「セッションIDの管理」ですが、この動作は次のようになります。なお、使用するブラウザによっては必ずしも下記の通りにはならない事もあります。
ブラウザ Webコンテナ
1) Cookie有効 クッキーを使用 → Cookieによってセッション管理される
2) Cookie有効 URL Rewritingを使用 → Cookieによってセッション管理される
3) Cookie無効 クッキーを使用 → URLによってセッション管理される
4) Cookie無効 URL Rewritingを使用 → URLによってセッション管理される
- JSPページから、同じ Webアプリケーション内のクラスを参照する場合、そのクラスはパッケージ化（package 宣言）されている必要があります。
- Webアプリケーションの web.xml 内の display-name 要素に極端に長い文字列を指定している場合、「Web Applicationの管理／一覧」画面が乱れる事があります。この場合、display-name
の値を短くするか、運用管理コンソールの画面を大きくするかしてください。
- Webアプリケーションの web.xml の XML宣言部分にエンコーディングとして "SJIS" を指定した場合、Webアプリケーションが正しく読み込めない場合があります。この場合、エンコーディングとして
"Shift_JIS" を指定してください。
- Webアプリケーションを運用管理コンソールから、一時停止し、このWebアプリケーションに含まれるHTMLファイルにアクセスした場合、一時停止中にも関わらずエラーにならないことがあります。JavaServletやJSPにアクセスした場合には、エラーになります。
- あるサイズ以上（数百KBから数MB）の WARファイルを Webコンテナの転送すると、次のエラーが発生する事があります。
"Internal server error. reason: JNDI information get error:
error in opening zip file"
|
この場合、次の JavaVM オプションを指定してください。このオプションを指定しても同じエラーが発生する場合は、より大きな値を試してください。
- 転送ファイル名に２バイト文字を指定すると、一部文字化けする文字(外字域、機種依存域、等)があります。文字化けしない文字に変更し処理を行ってください。
- ServletContextListener、ServletContextAttributeListener、HttpSessionActivationListener内でJNDI（名前環境のルックアップ等）を利用すると、Exceptionが発生する場合があります。
- エラーページに page ディレクティブで contentType や pageEncodingを指定するとエラーページの表示で文字化けします。エラーページでは
page ディレクティブを指定しないようにしてください。指定しなければ、文字化けさせずに表示できます。
- サンプルjsp-examples.warの「JSP 2.0 Examples」−「New JSP XML Syntax (.jspx)」−「XHTML
Basic Example」は、IEで実行するとエラーになります。 動作確認するには、FireFox 等他の Webブラウザをご利用ください。
- V6.22以降のリリースでは、外部Webサーバ連携時に表示するドキュメントルートが、V6.20、および
V6.21 と異なります。 V6.20 および V6.21 では、デフォルトの状態ではドメインの docroot 配下をドキュメントルートとして表示しますが、V6.22 以降のリリースでは、連携した
Webサーバのドキュメントルートを表示します。
WebOTX Webサーバを使用している場合、ドメインのドキュメントルートと、WebOTX Webサーバのドキュメントルートが同じであるため、V6.20 および V6.21 と動作は代わりません。
V6.22 以降のリリースで V6.20 および V6.21 と同じようにドメインの docroot 配下を表示するには、JavaVM のオプションに「-Dwebotx.webcontainer.serverconfig.NoRoot=false」を設定してドメインとWebサーバを再起動してください。
- root 以外の運用管理ユーザでドメインを運用している時に、WebOTX Application Server 付属のサンプルを autodeploy で配備する場合には、まず最初に
WARファイルに運用管理ユーザが読み書きできるパーミッションを与えてください。
- Servlet 2.3仕様のWebアプリケーションの配備解除で、次の様なエラーログが出力されますが、処理には問題ありません。
java.lang.ClassCircularityError: /com/nec/webotx/enterprise/development/Group
- V6.2以降のリリースでは、WebOTX WebServer 2.0 と連携している場合の「プラグインのログ出力場所」「プラグインのログ出力内容」「プラグインの指定可能なログレベル」「プラグインによる負荷分散の設定方法」が、V6.1
と異なります。
| 項目 |
V6.1 |
V6.2以降 |
| プラグインのログ出力場所 |
(domain)/logs/WebServer/error_log
(Windowsはerror.log) |
(domain)/logs/mod_jk-20.log |
| プラグインのログ出力内容 |
詳細はお問い合わせください。 |
| プラグインのログレベル |
[logger.apache2]
level=ログレベル
DEBUG、INFO、ERROR、EMERGが指定可能 |
JkLogLevel ログレベル
trace、debug、info、warn、error、emerg が指定可能 |
| プラグインによる負荷分散の設定 |
詳細はお問い合わせください。 |
- 外部Webサーバと連携した場合、logsディレクトリに"jk_runtime_status"と"jk_runtime_status.lock"というファイルが生成されます。これらは、JKコネクタ（Webサーバプラグイン）の制御ファイルです。
- 複数の運用管理コンソールから、Webアプリケーションを同時配備するとエラーになる場合があります。再度、配備し直してください。
また、同じWebアプリケーションの配備中に、連続して再配備するとエラーとなります。
- 運用管理コンソールで、サービスのホストに表示されているルートコンテキスト("/")を選択して、ルートコンテキスト("/")に関するプロパティを表示し、保存を行うと"Web
Application"の一覧にルートコンテキスト("/")が表示されなくなります。
- Webコンテナを Sun Microsystems社の Webサーバと連携している場合は、連携のための定義ファイルに対して、Webコンテナにリクエストを転送するプラグインモジュールのキャッシュサイズの設定を追加する必要があります。
この設定を行わなければ、同時に複数のリクエストが来た場合にプラグインモジュールのリクエスト転送処理が間に合わなくなります。そして、リクエストが「Internal
Server Error(500)」エラーで返却されます。
以下で説明する手順に従ってキャッシュサイズの設定を追加してください。
- <INSTALL_DIR>/domains/<ドメイン名>/config/WebCont 配下にある workers.properties
をエディタで開きます。
- workers.properties ファイル内にパラメータ「worker.ajp13.cachesize」を追加します。
worker.ajp13.cachesize=150
指定する値は、利用する Webサーバの最大同時リクエスト処理数と同じかそれ以上に設定してください。
※ worker.ajp13.xxx で定義される他のパラメータと同じブロックにこの定義を挿入してください。特に、「worker.list」より後に追加するよう注意してください。
このファイルは環境設定ツールを実行すると初期状態に戻りますので注意してください。
なお、WebOTX Web Server 1.3、および WebOTX Web Server 2.0 ではこの設定は不要です。
- 外部Webサーバ連携時は、Webサーバ側に配置したコンテンツにアクセスすることによりWebサーバプラグインのログにエラーが出力される場合があります。 アクセスしたコンテンツがWebコンテナにないかクエリを行い、その結果、コンテンツがないためにエラーログが出力されます。動的反映を無効にするか、Webサーバ起動時に１回だけクエリする設定(queryonce)によりエラーログを抑制することができます。
-
外部Webサーバ連携時、JkMountディレクティブの記述の仕方によってはリクエストが正常に振り分けられない事があります。
外部Webサーバと連携している時、JkMount の記載方法によっては正常に振り分けられません。
例えば、次のような場合です。
JkMount /sample/* ajp13
JkMount /sample/aaa ajp13
上記の記述では、どちらの条件にもマッチするため正常に振り分けられません。
複数のアプリケーションを異なるドメインに配置している時（例えば /sample/aaa と /sample/bbb を異なるドメインに配備した場合）、次のような設定をしても正常に振り分ける事はできません。
JkMount /sample/* ajp13
- Webアプリケーションの配備情報をweb.xmから取得しているため、Webアプリケーションには web.xml は必須です。web.xmlがない、もしくは、正しく記述されていない場合には、Webアプリケーションを配備することができません。
- Windowsでは、WebアプリケーションのWEB-INFディレクトリ配下などに格納したファイル（*.propertiesなど）をJDBCやXMLパーサなどで処理する場合、これらのファイルが参照状態になり配備解除に失敗することがあります。ドメインを停止後、domain
のディレクトリの applications ディレクトリ配下にあるWebアプリケーションのディレクトリのWEB-INF配下の "lib"、classes"、"nec-web.xml"、"web.xml"以外のファイルを手動で削除して、ドメインを起動後配備解除してください。
例えば、Apache Portals Project で公開されている Jetspeed がこのWebアプリケーションに該当します。
- WebOTX Application Server V7.1からセッション情報を格納する仕様が異なります。このため、WebOTX Application Server V7.1以降と WebOTX V6.5以前にまたがってセッションレプリケーションの連携をすることができません。
- Webアプリケーションの配備時に "--precompilejsp=true" を指定して JSP のプリコンパイルを行う場合に、Webアプリケーション外のクラスを JSP から参照するためには、クラスパスを通す必要があります。ブートストラップクラスローダ・システムクラスローダ・ドメイン共通クラスローダでロードされたクラスを使用する場合は、設定する必要はありません。
設定が必要なケースにはエンタープライズアプリケーション(EAR) 内のWebアプリケーションにある JSP から同じ EAR 内にある EJB アプリケーション(JAR)内のクラスを参照する場合などが該当します。このような場合、参照したクラスが入った JAR を Webアプリケーションの WEB-INF/nec-web.xml ファイルに下記のように指定してください。
※クラスパスはフルパスで指定する必要があります。
Windowsの場合
<nec-web-app>
:
<jsp-config>
<property name="classpath" value="C:/jars/aaa.jar;C:/jars/bbb.jar"/>
</jsp-config>
:
</nec-web-app>
Unixの場合
<nec-web-app>
:
<jsp-config>
<property name="classpath" value="/home/jars/aaa.jar:/home/jars/bbb.jar"/>
</jsp-config>
:
</nec-web-app>
-
コンテキストパス（http://<Host>:<Port>/<ContextPath>/<ServletPath>/ の <ContextPath> の部分）に、例えば "/sample/ap" のように "/" を含む場合、一部機能が利用できません。
利用できないのは次の機能です。
a) セッションレプリケーション
b) マルチプロセスモードにおけるリクエスト振り分け
- セッションレプリケーション
セッションレプリケーションを利用した場合、セッション情報をJNDIサーバに保存します。しかし、JNDIサーバへのセッション情報の保存処理が "/" を含むコンテキストパスに対応していないため、セッションレプリケーション機能を利用できません。
- マルチプロセスモードにおけるリクエスト振り分け
Webコンテナをマルチプロセスモードで利用する時、コンテキストパスに "/" を含むアプリケーションを複数のプロセスグループに配備した場合、正常に振り分けられません。
例えば、次のような場合です。
プロセスグループA → /sample/aaa
プロセスグループB → /sample/bbb
TPモニタは第一階層（/sample）までしか見ないため、このような場合意図したプロセスグループに振り分けられません。
対処：
いずれの場合も、コンテキストパスは "sample_ap" のように "/" は含めない形で配備してください。
また、"/" は含めない形で配備はしても、クライアントからのアクセスURLを変更したくない場合は次の
ように対処してください。
- WebOTX Webサーバで URL の書き換え設定を行います
- WebOTX Webサーバの設定ファイル（httpd.conf）を開き mod_rewrite を有効にします（コメントを外します）。
LoadModule rewrite_module "/opt/WebOTX/WebServer2/modules/mod_rewrite.so"
- URLの書き換えルールを記述します
例えば、コンテキストパスが "/sample/ap" の場合次のようになります。
RewriteEngine on
RewriteRule ^/samplep/ap/(.*)$ /sample_ap/$1 [PT,L]
RewriteRule ^/sample_ap/(.*)$ /sample/ap/$1 [R,L]
設定が終わったら WebOTX Webサーバ、またはドメインを再起動します。
- Cokkie の設定を行います
コンテキストパスに "/" を含む URL にも Cookie を送付するよう明示的に指定します。設定場所は、WebOTX 独自のWebアプリケーションの配備記述子である nec-web.xml です。このファイルに次のような記述を追加します。
<?xml version="1.0" encoding="UTF-8"?><nec-web-app>
<context-root>sample_ap</context-root>
<class-loader delegate="false"/>
<session-config>
<cookie-properties>
<property name="cookiePath" value="/sample/ap"/>
</cookie-properties>
</session-config>
</nec-web-app>
追記が終わったらWARファイルをアーカイブし直して配備します。
- Standard Edition / Enterprise Edition でマルチプロセス動作している場合、forwardによって呼び出せるWebアプリケーションは同じアプリケーショングループ、プロセスグループに配備されているWebアプリケーションのみです。これは、forwardの処理は、同一プロセスないで行うため、プロセスをまたがったWebアプリケーションの呼び出しができないためです。
- Standard Edition / Enterprise Edition でマルチプロセス動作している場合、ファイル等を更新しないようにしてください。複数のプロセスから同時に１つのファイルにアクセスすると正常に処理できません。
- Standard Edition / Enterprise Edition でマルチプロセス動作している場合、WebアプリケーションからのEJBの呼び出しはデフォルトではローカル呼び出しとなります。
- Standard Edition / Enterprise Edition でマルチプロセス動作している場合、Webアプリケーションを"http://webserverhost/"にマッピングするようなコンテキストルートの指定無しの設定はできません。
- Standard Edition / Enterprise Edition でマルチプロセス動作している場合、環境設定のPATHの先頭にObjectBrokerパス指定を、<ショートパス>;<ロングパス>の形で書く必要があります。
- Standard Edition / Enterprise Edition でマルチプロセス動作している場合、HTTPリクエストを前回利用したプロセスに振り分けるために、セッションIDにプロセスIDを含めます。このためセッションIDのフォーマットが次のように変わります。
"セッションID(32桁) $ プロセスID" 例：C7C25B729C39629558DB02C5FA25E038$6212
jvmRouteを付加した場合は次のように変わります。
"セッションID(32桁) . jvmRoute $ プロセスID" 例:5B22AF53A66CAB1AB26490EB430D36C3.hoho1$3936
- Standard Edition / Enterprise Edition で、Webコンテナをマルチプロセス動作させている場合、プロセス間で情報を共有することができません。プロセス障害時にセッション情報を引き継ぐ場合は、セッションレプリケーションを利用してください。また、ServletContextについては、ServletContext#setAttribute()やServletContext#removeAttribute()メソッドで更新した情報を、自プロセス以外では参照できません。