3. Webコンテナ

Webコンテナを利用する際の注意制限事項について説明します。

3.1. 注意事項

3.1.1. 環境設定

環境設定ツールの起動方法について
Windows OS において環境設定ツールを起動する際は、右クリックメニューから［管理者として実行］を選択して起動してください。

環境設定時に初期化されるファイルについて
環境設定を行うと、ドメインの config/WebCont 配下にある workers.properties/ior_workers.properties が初期化されます。これらのファイルを編集している場合はバックアップを取っておいてください。

3.1.2. Webコンテナの運用/管理

Web版統合運用管理コンソールについては、[ 19. Web版統合運用管理コンソール ]を参照してください。

JSPエンジンのログレベルを上げた場合
JSP のログレベルを "DEBUG" 以上に変更すると、JSP でリクエストパラメータを取得した時に文字化けが発生します。
- 統合運用管理ツール/Web版統合運用管理コンソールで更新する場合：
  アプリケーションサーバ > ログサービス > モジュールログレベル > JSP
- log4otx.xml ファイルを手動で更新する場合：
  対象ファイル（スタンダードモード）：
  　<WebOTXインストールディレクトリ>/domains/<ドメイン名>/config/log4otx.xml
  対象ファイル（アドバンスドモード）：
  　<WebOTXインストールディレクトリ>/domains/<ドメイン名>/config/tpsystem/logconf/<AP-G名>-<PG-G名>/log4otx.xml
  
  対象箇所：
  　<logger name="org.apache.jasper" additivity="true">
  　　<level value="CONFIG" class="com.nec.webotx.logging.OTXLogLevel">
ログレベルを "DEBUG" に変更すると、JSP処理コンポーネントが処理するデータをログに記録します。障害調査などを目的としたログであるためブラウザから渡されてきたそのままのデータを記録します。このため、JSP でリクエストパラメータ取得時の文字コードを設定する前にリクエストパラメータを分解します。この結果、文字コードの設定が効かずアプリケーションで文字化けが発生します。

本ログレベルを上げるのは、JSPにおいてリクエストの内容がどのようになっているかを確認する時だけにしてください。そして、内容を確認した後は、必ず "CONFIG" レベルに戻してください。

大量のリクエストパラメータを処理する場合
多量のパラメータを持つリクエストを処理すると、パラメータ解析処理に過剰な負荷が掛かかりドメインが動作できなくなる問題（Tomcatの脆弱性 CVE-2012-0022、CVE-2011-4858）に対処するため、処理可能なリクエストパラメータ数の上限を10000に設定しています（既定値）。リクエストパラメータ数の上限を変更したい場合、maxParameterCount で調整してください。

詳細は以下を参照してください。
[リファレンス集運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ > 1.4.2. Webコンテナ設定項目一覧 > 1.4.2.1. MOで設定可能な項目一覧 > Dottedname : server.network-config.protocols.protocol.protocol-name.http.property.maxParameterCount > maxParameterCount]

低負荷でもCPU使用率が100%になる現象について

通信にGrizzlyコネクタもしくはnioコネクタを利用している場合に、JDKとの組み合わせにより低負荷にもかかわらずCPU使用率が100%になる現象が発生する場合があります。

現在、Linux(64bit)環境での現象発生が報告されています。現象が本件に合致しているかどうかは次の方法で確認します。

[確認方法]

スレッドダンプの採取

 > kill -QUIT <PID>

    ・PIDは{ドメインディレクトリ}/config/server_pidを参照
    ・10秒間隔で1分程度採取します。
    ・結果は{ドメインディレクトリ}/logs/server.logに出力

CPUリソースを消費しているスレッドの特定
- プロセス情報を取得します
```
 > ps -L auxww
```
```
    ・10秒間隔で1分程度採取します。
  
```
- psコマンドの結果からCPUリソースの消費が続いてしるスレッドを特定します。
```
    USER       PID   LWP %CPU NLWP %MEM    VSZ   RSS TTY      ・・・
        :
    root      7152  7242 96.2  111  3.9 1651724 478756 ?      ・・・
        :
  
```
  LWP(10進数)がスレッドダンプ中のスレッドID(nid(16進数))に相当します。

スレッドダンプからCPUリソースを消費しているスレッドの状態を確認します。
次のようにepollWait()を実行している状態が続いていれば本件に該当します。

    "Grizzly-kernel-thread(1)" daemon prio=10 tid=0x00007fa8a4017800 nid=0x1c4a runnable [0x00007fa8b04a8000]
       java.lang.Thread.State: RUNNABLE
     at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
     at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
     at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
     at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
     - locked <0x00000000e133c560> (a sun.nio.ch.Util$2)
     - locked <0x00000000e133c570> (a java.util.Collections$UnmodifiableSet)
     - locked <0x00000000e133c518> (a sun.nio.ch.EPollSelectorImpl)
     at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
     at com.nec.webotx.grizzly.TCPSelectorHandler.select(TCPSelectorHandler.java:514)
     at com.nec.webotx.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:190)
     at com.nec.webotx.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:132)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
     at java.lang.Thread.run(Thread.java:745)

[回避方法]
HTTP通信コネクタをGrizzly(もしくはnio)コネクタからbioコネクタに変更することで現象を回避します。

変更対象には次の２つがあり、構成により変更箇所に違いがあります。

運用管理コンソール用通信コネクタ
内蔵Webサーバ用通信コネクタ

[アドバンスドモード／スタンダードモード(Webサーバ連携)]
運用管理コンソールの通信コネクタをbioコネクタに変更します。
```
otxadmin> set server.network-config.protocols.protocol.admin-listener.type=bio
```
※ Webサーバ連携用のコネクタはajpコネクタを使用しているため変更不要です。
[スタンダードモード(内蔵Webサーバ)]
運用管理コンソールの通信コネクタをbioコネクタに変更します。
```
otxadmin> set server.network-config.protocols.protocol.admin-listener.type=bio
```
内蔵Webサーバのコネクタ種別がgrizzly、nioの場合、bioコネクタに変更します。内蔵Webサーバのコネクタ種別を確認します。
```
otxadmin> get server.network-config.protocols.protocol.http-listener.type
  server.network-config.protocols.protocol.http-listener.type = grizzly
```
typeの内容が"grizzly"もしくは"nio"の場合、bioコネクタに変更します。
```
otxadmin> set server.network-config.protocols.protocol.http-listener.type=bio
```

全てのクライアントからリクエストを受けるための設定
WebOTX が動作しているマシン上の全てのIPアドレスでリクエストを受け付けるように設定する場合、domain.xml の domain > configs > config > network-config > network-listeners > network-listener > http-listener の address 属性で "0.0.0.0" と指定してください。例えば "any" や "ANY" といった文字列は指定できません。指定した場合には通信ができなくなります。

3.1.3. Webサーバ連携

/scripts/jrun.dll/ というリクエストで404エラーが発生する
IIS + Webコンテナの環境で、リクエストURLに「/scripts/jrun.dll/」という文字列が先頭に付加されている場合にJSPファイルを実行するとエラー(404)が発生します。
この現象は IIS ＋ JRun の環境を過去に構築した事があると発生します。 IIS の script ディレクトリに「jrun.ini」があるので、その中で「scripts/jrun.dll」の文字列が付加されていれば、「jrun.ini」を削除(待避)してください。

動的反映機能がOFF(無効)の時に404エラーが発生する
コンテキストの動的反映をOFF（ajp13_originalを指定）に設定していて、マシン再起動などで WebOTX のドメインと外部Webサーバが同時に起動するような場合、タイミングによっては404エラーが発生する場合があります。
ドメインは起動時に毎回配備されているアプリケーションの内容をプラグインの連携設定用ファイルに書き出しますが、ドメインがこの連携設定用ファイルを更新するタイミングで外部Webサーバのプラグインがアクセスしてしまう場合があるためです。
このような現象が発生する場合は外部Webサーバの起動タイミングを数秒遅らせる等の対処をしてください。

IIS連携時に匿名アクセスを有効にしていない場合
IISと連携している時、Webサイトの設定でディレクトリセキュリティの「認証方法」で“匿名アクセスを有効にする”のチェックを外している場合、servlets-examplesなど一般の Webアプリケーションへのアクセス時にも認証が必要となります。
これは、IISへのアクセスに関して認証が要求されているという事ですので、システムに存在するいずれかのユーザでログインしてください。

IIS連携時に「ファンクションが間違っています」と表示される
IIS連携時、isapiプラグインから設定ファイルuriworkersmap.properties-autoが読み込めていないために、「ファンクションが間違っています」と表示される場合があります。その場合、次の設定を行ってください。
- ${AS_INSTALL}\bin\win32\i386\isapi_redirect.dllをexplorerで選択し、右クリック - プロパティ - セキュリティ - 「追加」-「詳細設定」-「今すぐ検索」-"NETWORK SERVICE"を選択し、追加します。設定変更後、IISを再起動し設定を反映してください。

IIS連携時にWebサーバプラグインのログが出力されない
IIS連携時に、JKコネクタ（Webサーバプラグイン）のログが指定しているディレクトリに出力されない場合があります。
次の処理を行ってください。
1. ${INSTANECE_ROOT}\logsの「プロパティ」を開き、「セキュリティ」タブで「追加」ボタンをクリックします。
2. 「ユーザーまたはグループの選択」ダイアログで自マシンの NETWORK SERVICE を選択し OK します。
3. 「詳細設定」ボタンをクリックします。
4. 「セキュリティの詳細設定」ダイアログの「アクセス許可」タブで「追加」ボタンをクリックします。
5. 「ユーザーまたはグループの選択」ダイアログで自マシンの NETWORK SERVICE を選択し OK します。
6. 「アクセス許可エントリ」ダイアログの「適用先」で「このフォルダとサブフォルダ」を選択し、「アクセス許可」で「ファイルの作成/データの書き込み」と「フォルダの作成/データの追加」をチェックして OK します。
7. 「セキュリティの詳細設定」ダイアログ、「プロパティ」を OK して閉じます。

Webサーバの連携解除について
Webコンテナをアンインストールしても連携する Webサーバの設定が残っています。そのまま Webサーバを使い続けた場合、システムによっては 503エラーを返却するなどWebサーバが正常に起動しなくなる可能性があります。特に Unix 環境でWebサーバを自動起動に設定している場合、最悪 Unix が起動しなくなる恐れがあります。

また、WebOTX V9.2 以降では ISAPI フィルター名にドメイン名を domain1_webcont のようにつけるため、WebOTX V9.1 以前で使用していた IIS サイトに対して連携設定を行ったり、別のドメインと行うと古い設定が残ったままとなり、連携ができず 503 エラーとなります。そのため、古い設定が残っている場合は、IISマネージャにて古いISAPI フィルターを削除してください。

WebコンテナとWebOTX Webサーバの連携の解除方法
WebOTX Webサーバのインストールディレクトリのconfディレクトリ配下にあるhttpd.confファイルを編集します。「# TM_WS_PLUGIN-start 」~「# TM_WS_PLUGIN-end」の記述を削除してください。
```
# TM_WS_PLUGIN-start
include "${INSTANECE_ROOT}/config/WebCont/mod_jk-22.conf-auto"
# TM_WS_PLUGIN-end
```

配備解除したWebアプリケーションへのアクセスでダウンロードが開始される場合
Webサーバと連携中に配備解除したWebアプリケーションにアクセスするなどした場合(通常は HTTP404エラー)、ブラウザの設定によりダウンロード処理が始まることがあります。
ブラウザの設定を変更することで回避することができます。

　　例) IE6の場合次のチェックをONにする
　　　　メニューより「ツール」-「インターネットオプション」-「詳細設定」で「ブラウズ」-「HTTPエラーメッセージを簡易表示する」

Webアプリケーションのルートコンテキスト("/")への割り当てについて
- Webアプリケーションにルートコンテキスト(/)を割当てて配備した場合、ドメインを再起動しないとアクセスできません。また、別のWebアプリケーションをルートコンテキスト("/")へ配備した場合も、ドメインの再起動が必要です。
  Webアプリーションの配備後にドメインを再起動してください。外部のWebサーバ（Apache等）と連携している場合には、外部のWebサーバも再起動が必要です。
```
PathCheck fn="find-index" index-names="index.html,home.html,index.jsp"
```
- Webアプリケーションにルートコンテキスト(/)を割当てて配備した場合、その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サーバを再起動してください。
- ルートコンテキスト（/）に割り当てたWebアプリケーションと通常のコンテキスト名を指定したWebアプリケーションを混在させた場合、前者のサーブレット名（http://<ホスト名>/<servlet-name>）と後者のコンテキスト名（http://<ホスト名>/<context-name>）が重複しないように注意してください。

外部Webサーバと連携のログファイルについて
外部Webサーバと連携した場合、logsディレクトリに以下のようなファイルが作成されます。

Apache の場合："jk_runtime_status"と"jk_runtime_status.lock"

これらは、JKコネクタ（Webサーバプラグイン）の制御ファイルです。

Webサーバ側に配置したコンテンツへのアクセスでエラーログが記録される
外部Webサーバ連携時は、Webサーバ側に配置したコンテンツにアクセスすることによりWebサーバプラグインのログにエラーが出力される場合があります。

アクセスしたコンテンツがWebコンテナにないかクエリを行い、その結果、コンテンツがないためにエラーログが出力されます。動的反映を無効にするか、Webサーバ起動時に１回だけクエリする設定(queryonce)によりエラーログを抑制することができます。

IIS動作マシンにWebOTXをインストールしない場合
下記の手順により、必要なファイルをWebコンテナ動作マシンからコピーし、手動でレジストリに設定を行うことにより、Webコンテナとの連携動作は可能となりますが、この場合、外部Webサーバとの連携についてはサポート対象外となります。完全なサポートを受けるためにも、IISの動作するマシンにWebOTXをインストールすることを推奨します。

手動でレジストリの操作およびファイルのコピーを行い、環境設定ツールをインストールします。

※レジストリの編集を誤ると深刻な問題が発生することがあります。最悪の場合、オペレーティングシステムの再インストールが必要です。レジストリの編集はバックアップをとった上、各自の責任で注意して行ってください。
1. ファイルのコピー
  
  IISの動作するマシンにWebOTXをインストールしない場合は、下図のような構成を保ってWebコンテナ動作マシン上のファイルをIIS動作マシンにコピーしてください。
  
  図3.1.3-1
2. レジストリ設定用ファイル(iis_redirect.reg)の作成
  
  iis_redirect.regを新規に作成し、テキストエディタ等で下記の内容を記述します。”C:\\WebOTX\\”の箇所は上記 1.で作成したディレクトリを指定してください。
```
  REGEDIT4

  [HKEY_LOCAL_MACHINE\SOFTWARE\NEC\WebOTX WebContainer]

  "PathName"="C:\\WebOTX\\"
 
```
3. レジストリの設定
  
  上記 2.で作成したiis_redirect.regをダブルクリックして実行し、レジストリを設定します。ダブルクリック後、レジストリエディタの確認画面が表示されるので、「はい」を押して設定を行ってください。
上記の手順を実施した後、環境設定ツールによる環境設定を実行してください。

Webサーバ連携用ファイルの自動出力について
WebOTX V8.2以降ではアドバンスドモードの場合でも、Webサーバとの連携設定に使用する設定ファイル(mod_jk_om-22.conf-auto)を自動で出力します

旧バージョンのWebOTXと同様に、これらのファイルを自動で変更したくない場合は、以下のコマンドでJVMオプションを設定してください。ただし、以下のオプションを指定している場合、統合運用管理ツールから設定できる「Webサーバ連携設定」の項目のうち、*.conf-auto に出力される設定項目も無効になります。
```
otxadmin> create-jvm-options
-Dwebotx.webcontainer.serverconfig.OMlistener.OutputConfAuto=false
```
また、上記オプションの設定有無に関わらず、ファイルが存在しない場合は自動で作成されます。

アドバンスドモード(IIOP) で名前解決が失敗する場合
アドバンスドモードでは、Webサーバ（IIOPプラグイン）とWebOTX（IIOPリスナ）の間を、IIOPで通信しています。このIIOPのWebサーバからの接続先を示す情報（ホスト名、IIOPリスナのポート番号）がhttpgateway.iorに入っています。ここに記述されているホスト名がマシンで名前解決できるホスト名でない場合、通信に失敗し、エラーが発生します。次の設定を行ってください。
- 運用管理コンソールで<ドメイン名>-「TPシステム」ノードの「システム情報」タブ、「接続サーバ名」から名前解決できるホスト名またはIPアドレスを設定します。
  
  ドメインを再起動し、設定を反映してください。

外部Webサーバ連携時にリクエストの振り分けがうまくいかない場合
外部Webサーバ連携時、JkMountディレクティブの記述の仕方によってはリクエストが正常に振り分けられない事があります。例えば、次のような場合です。

　JkMount /sample/* ajp13
　JkMount /sample/aaa ajp13

上記の記述では、どちらの条件にもマッチするため正常に振り分けられません。

複数のアプリケーションを異なるドメインに配置している時（例えば /sample/aaa と /sample/bbb を異なるドメインに配備した場合）、次のような設定をしても正常に振り分ける事はできません。

　JkMount /sample/* ajp13

別マシンからプラグイン設定項目を行う場合
WebサーバとWebコンテナが別マシン構成の場合、統合運用管理ツールや運用管理コマンドからプラグインの設定項目(Webサーバ連携設定)の変更を行うためには、以下の条件を満たしている必要があります。
- WebサーバのあるマシンにWebOTXがインストールされている。
- 両方のマシンにインストールされたWebOTXのWebコンテナの動作モードが同じ。

IIS連携の設定に必要なコンポーネントについて
環境設定ツールを使用して IIS7.0、IIS7.5、IIS8.0 と連携設定を行う場合、役割サービスの「IIS6メタベース互換」がインストールされている必要があります。

環境設定ツールで「IISサイト名」にサイト名が表示されない場合
役割サービスの[Webサーバ(IIS) > 管理ツール > IIS管理互換 > IIS6メタベース互換] がインストールされているか確認してください。

アドバンスドモード(IIOP) でリクエストの中にCookieのJSESSIONIDが複数存在する場合
リクエストの中にCookieのJSESSIONIDが複数存在した場合、最初に検出したJSESSIONIDをプロセスグループのプロセスへの振り分けに使用します。２つ目以降のJSESSIONIDは無視されます。

動的反映機能がクエリーワンスの場合、404エラーから復旧しない
ドメイン起動後、アプリケーションのロードが完了する前にリクエストを受け付けると404エラーが発生します。クエリーワンス設定はアプリケーション情報を初回リクエスト時しか取得しないためロード完了後も404エラーが発生します。復旧させるには、連携している外部Webサーバを再起動する必要があります。

3.1.4. Webアプリケーションの運用/実行

<load-on-startup>要素が空の場合
Servlet API 仕様 2.4 に準拠したWebアプリケーションで、web.xml に空の <load-on-startup>要素を含む場合は、そのWebアプリケーション（war）は配備できません。

「ファイル転送サンプル」を実行する前の設定について
WebOTX に付属する「ファイル転送サンプル」を実行する場合、実行に先立って次のポリシーをドメインディレクトリの config/server.policy に追加してください。
```
grant {
   permission java.io.FilePermission 
      "${com.nec.webotx.instanceRoot}${/}applications${/}fileupdownload${/}-", "read,write,delete";
};
```

Webアプリケーション名とコンテキストルートは重複して配備できない
Webアプリケーションを配備すると、内部では Webアプリケーション名とコンテキストルートの２つで Webアプリケーションを識別します。これらは、配備済みの Webアプリケーションと同じ名称を指定する事はできません。Webアプリケーション毎に一意の指定をしてください。

JSPコンパイル時のパーミッションエラーについて
JSP を含む Webアプリケーションを実行すると、パーミッションエラーで JSP のコンパイルが失敗する事があります。

この場合、使用する JDK のバージョンに合ったクラスが使用されているかを確認してください。具体的には、利用している JDK に付属の tools.jar が使用されているかを確認します。異なったバージョンの tools.jar がクラスパスに指定されていると正しくコンパイルできない恐れがあります。

「セッションIDの管理」の動作について

Webコンテナで設定できる「セッションIDの管理」ですが、この動作は次のようになります。なお、使用するブラウザによっては必ずしも下記の通りにはならない事もあります。

   ブラウザ       Webコンテナ
1) Cookie有効     セッションIDの管理-ON     → Cookieによってセッション管理される
2) Cookie有効     セッションIDの管理-OFF    → Cookieによってセッション管理される
3) Cookie無効     セッションIDの管理-ON     → URLによってセッション管理される
4) Cookie無効     セッションIDの管理-OFF    → URLによってセッション管理される

JSPで同じ Webアプリケーション内のクラスを参照する場合
JSPページから、同じ Webアプリケーション内のクラスを参照する場合、そのクラスはパッケージ化（package宣言）されている必要があります。

web.xml自体の文字エンコーディング指定について
Webアプリケーションの web.xml の XML宣言部分にエンコーディングとして "SJIS" を指定した場合、Webアプリケーションが正しく読み込めない場合があります。この場合、エンコーディングとして "Shift_JIS" を指定してください。

Webアプリケーションを一時停止した場合の動きについて
Webアプリケーションを運用管理コンソールから、一時停止し、このWebアプリケーションに含まれるHTMLファイルにアクセスした場合、一時停止中にも関わらずエラーにならないことがあります。ServletやJSPにアクセスした場合には、エラーになります。

サイズの大きいWARファイルを配備した時のエラーについて
あるサイズ以上（数百KBから数MB）の WARファイルを Webコンテナに配備すると、次のエラーが発生する事があります。
"Internal server error. reason: JNDI information get error: error in opening zip file"
この場合、次の JavaVM オプションを指定してください。このオプションを指定しても同じエラーが発生する場合は、より大きな値を試してください。
"-Xss512k"

WARファイル名に使用する文字種別について
配備するWARファイルのファイル名に２バイト文字を指定すると、一部文字化けする文字(外字域、機種依存域、等)があります。２バイト文字を指定しないでください。

Servlet のリスナ機能の中でJNDIを利用する場合
ServletContextListener、ServletContextAttributeListener、HttpSessionActivationListener内でJNDI（名前環境のルックアップ等）を利用すると、Exceptionが発生する場合があります。

web.xml の error-page に指定するコンテンツについて
エラーページに page ディレクティブで contentType や pageEncodingを指定するとエラーページの表示で文字化けします。エラーページでは page ディレクティブを指定しないようにしてください。指定しなければ、文字化けさせずに表示できます。

autodeploy で配備するWARファイルのパーミッションについて
root 以外の運用管理ユーザでドメインを運用している時に、WebOTX Application Server 付属のサンプルを autodeploy で配備する場合には、 WARファイルに運用管理ユーザが読み書きできるパーミッションを与えてください。

Servlet 2.5 以前の Webアプリケーションにおける web.xml について
Servlet 2.5 以前では、Webアプリケーションの配備情報をweb.xmlから取得しているため、Webアプリケーションには web.xmlは必須です。web.xmlがない、もしくは、正しく記述されていない場合には、Webアプリケーションを配備することができません。

WEB-INF配下に格納したファイルが参照状態となり配備解除に失敗する
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 V6.5以前と V7以降のセッション情報格納仕様の違いについて
WebOTX Application Server V7.1からセッション情報を格納する仕様が異なります。このため、WebOTX Application Server V7.1以降とWebOTX V6.5以前にまたがってセッションレプリケーションの連携をすることができません。

セッションレプリケーション利用時に格納するオブジェクトについて
セッションレプリケーションを行う場合、格納するオブジェクトに注意事項があります。
- オブジェクトはシリアライズ可能であること。
- セッションにsetAttribute()で格納したオブジェクトを更新した場合、再度setAttribute()する必要がある。
また、この注意事項はアドバンスドモードでの「プロセス間コンテキスト属性共有」を行う場合にも該当します。
詳細は以下を参照してください。
[リファレンス集運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ > 1.4.7. HTTPセッション管理について > 1.4.7.3.セッションレプリケーション > Webアプリケーション実装の注意/制限事項]

セッションレプリケーションの非同期モードにおける注意事項について
セッションレプリケーション非同期モードには、以下の注意点があります。
- ロードバランサーでの振り分けは、セッション固定（クライアントIPで固定）でのサーバ振り分けが必須です。 Webサーバプラグインでの振り分けは利用できません。
  "セッション固定振り分け"をしない場合は、別サーバで更新したセッション情報を参照できません。 "セッション固定振り分け"ができない場合、もしくはWebサーバプラグインでの振り分けが必須である場合は、同期モードを選択してください。
- DB等にセッション保存後、APサーバがダウンするまでの間（セッション更新間隔）に更新されたセッション情報は別サーバに引き継ぐことができません。
  必要とする信頼性レベルで、本動作仕様を許容できない場合は、同期モードを選択してください。
- セッション生成時に、別サーバで同じセッションが生成されていた場合、DBのセッション情報を上書きします。
  本事象は、JVMオプションを各APサーバに設定することで、回避可能です。
- 最大セッション数の制限が効きません。
  他APサーバのメモリ上にのみ存在するセッション数は把握できないので、正確に制限できません。
- アドバンスドモード（複数プロセス利用時）においてはプロセスが再起動やサーバ障害発生後に、セッション生成したプロセスが存在しなくなるため、非同期モードの前提となる"セッション固定振り分け"ができない状態が発生します。これを回避するためセッションID付け替え機能を使用します。ただしセッションID付け替え機能を使用すると途中でセッションIDが変わります(クライアント間のセッションは維持されます)。そのため、セッションIDが途中で変わることを想定していない、変わると動作に支障がでるWebアプリケーションの場合、セッションID付け替え機能は使えません。
  さらに、セッションID付け替え機能を使用できた場合も、プロセス障害発生後次のリクエストが動的ファイル(Servlet/Jsp)を複数同時にリクエスト実行するWebアプリケーションの場合、プロセス障害時に複数のプロセスがセッションID付け替えを行ってしまい (１つのセッションに対して複数の付け替えたセッションが生成されてしまう)正常なセッションの継続ができなくなる可能性があります。

セッションレプリケーションの同期モードにおける注意事項について
セッションレプリケーション同期モードには、以下の注意点があります。
- 同時リクエストをした場合は、別リクエストで更新したセッション情報を参照できない場合があります。
- 同時リクエストをした場合は、別リクエストで更新したセッション情報を上書き消去する場合があります。
- 同時リクエストをした場合は、別リクエストの処理の待ち合わせは行ないません。

Oracle Coherence 利用時の注意事項について
Oracle Coherenceを使用する場合、以下の注意点があります。
- JNDIを使用するレプリケーション機能とOracle Coherenceのレプリケーション機能の併用は不可です。
- Webアプリケーションのストール監視(webap-alive-timeout)は使用できません。
- アドバンスドモードの場合、セッションIDにPID、jvmRouteは付かないため、セッション固定振り分けはできません。
- Oracle Coherenceのセッションレプリケーション機能はJava EE 6のContexts and Dependency Injection(CDI)をサポートしていません。Oracle Coherenceのセッションレプリケーション機能を利用する場合は、アプリケーションでCDIを使用しないでください。

J2SE5.0 の予約語について
J2SE 5.0 で新しく予約語になった用語を JSPファイルで変数などとして使用していた場合コンパイル時にエラーとなります。この場合、nec-web.xml で compilerSourceVM オプションを利用して任意のバージョンを指定するか、名称を変更してください。
```
 <jsp-config>
    <property name="compilerSourceVM" value="1.4"/>
```
なお、Java の予約語は以下の通りです。

原始型（プリミティブ型）を表す予約語
byte,char,short,int,long,float,double,boolean,true,false,void

クラス、パッケージに関する予約語
class,interface,extends,implements,this,super,new,null,instanceof,import,package,

修飾子
public,protected,private,final,static,abstract,native,synchronized,volatile,transient

基本的な制御に関する予約語
for,while,do,if,else,switch,case,default,break,continue,return,

例外処理に関連する予約語
try,catch,finally,throw,throws,

その他の予約語
const,goto,strictfp

追加
assert(1.4),enum(5.0)

配備後の web.xml の扱いについて
WebOTX ではアプリケーション配備時にそのアプリケーションに含まれる web.xml および nec-web.xmlの内容をドメイン配下に保存します（${INSTANECE_ROOT}/generated/xml/[AP名]/appDescr.dat）。

このため、配備したアプリケーションの web.xml 等を直接編集しても反映されません。内容を変更したい場合は再配備してください。

複数の仮想サーバが存在する時の動きについて
複数の仮想サーバを定義している状態で、アプリケーションを配備する際に仮想サーバ（Virtual Server）を指定しなかった場合は全ての仮想サーバで配備したアプリケーションが利用可能な状態になります。

WebOTX V8.1以降の静的ファイルのキャッシュについて
V8.1 より Webアプリケーションの認証処理が一部変更になり、その関係で静的なファイルへのリクエストでキャッシュが効かず毎回リクエストしてしまう、という現象が発生する場合があります。これは、初回リクエストに対するHTTPレスポンスヘッダに以下のパラメータが含まれているためです。

Pragma: No-cache
Cache-Control: no-cache

このパラメータを付加したくない場合（V7以前と同じ動作をさせたい場合）は、次のシステムプロパティを設定してください。

-Dcom.nec.webotx.enterprise.checkURLPatternAfterMatching=false

また、":"を含むURLにアクセスした時に 400エラーになってしまう場合も上記プロパティを設定することで回避可能です。

Internet Explorer 利用時にSSL通信が失敗する
Internet Explorerのバグにより以下の条件を全て満たす場合、SSL通信でのXMLドキュメントの取得に失敗します。
- 読み込み可能オブジェクトモデルの Load メソッドを使用してXMLドキュメントを読み込んでいる。
- Load メソッドの同期オプションを有効にしている。
- SSL の通信を行っており、取得対象のXMLドキュメントに no-cache ヘッダが付加されている。
詳細は以下のサイトを参照してください。
http://support.microsoft.com/kb/272359/en-us

取得する XML ファイルが web.xml で定義された <security-constraint> の範囲外にある場合、 checkURLPatternAfterMatching の設定により、この現象を回避できることがあります。詳細は[ マイグレーションガイド > 2. マイグレーションアシスタントを利用しないマイグレーションガイド > 2.3. 移行作業 > 2.3.6. WebOTX独自のWebアプリケーション配備記述子（nec-web.xml） > 2.3.6.5. no-cache の設定 ] を参照してください。

Internet Explorer 利用時に Cookie が保存されない
Internet Explorerでホスト名に _(アンダースコア)等を含むURLにアクセスした場合、そのサイトの Cookie は保存されません。そのため、セッションを利用する Web 版統合運用管理コンソールなどのアプリケーションが利用できません。
Cookie を使用する場合、IPアドレスを指定してアクセスするか、Firefox等別のブラウザを使用してアクセスしてください。

詳細は以下のサイトを参照してください。
http://support.microsoft.com/kb/275033/en-us

WebOTX V8 から V9 への移行における互換性について
WebOTX V8以前からV9へアップグレードする際には、ベースとなるTomcatのバージョンが変更されていることにより互換性を保つための設定が必要となる場合があります。

詳細は、[ マイグレーションガイド > 2. マイグレーションアシスタントを利用しないマイグレーションガイド > 2.3. 移行作業 > 2.3.8. Tomcatの差異による対応 ] を参照してください。

コンテキストパスに "/" を含む場合の注意事項
コンテキストパス（http://<ホスト名>:<ポート番号>/<ContextPath>/<ServletPath>/ の <ContextPath> の部分）に、例えば "/sample/ap" のように "/" を含む場合、一部機能が利用できません。

利用できないのは次の機能です。

a) セッションレプリケーション
b) アドバンスドモードにおけるリクエスト振り分け
1. セッションレプリケーション
  
  セッションレプリケーションを利用した場合、セッション情報をJNDIサーバに保存します。しかし、JNDIサーバへのセッション情報の保存処理が "/" を含むコンテキストパスに対応していないため、セッションレプリケーション機能を利用できません。
2. アドバンスドモードにおけるリクエスト振り分け
  
  Webコンテナをアドバンスドモードで利用する時、コンテキストパスに "/" を含むアプリケーションを複数のプロセスグループに配備した場合、正常に振り分けられません。
  例えば、次のような場合です。
  
  　プロセスグループA → /sample/aaa
  　プロセスグループB → /sample/bbb
  
  TPモニタは第一階層（/sample）までしか見ないため、このような場合意図したプロセスグループに振り分けられません。
  
  なお、アプリケーションを "/"（ルートコンテキスト）に配備した場合も同様の問題が発生します。
  例えば、次のような場合です。
  
  　プロセスグループA → /
  　プロセスグループB → /bbb
  
  この場合も、意図したプロセスグループに振り分けられません。
対処：

いずれの場合も、コンテキストパスは "sample_ap" のように "/" は含めない形で配備してください。
また、"/" は含めない形で配備はしても、クライアントからのアクセスURLを変更したくない場合は次のように対処してください。
1. WebOTX Webサーバで URL の書き換え設定を行います
  1. WebOTX Webサーバの設定ファイル（httpd.conf）を開き mod_rewrite を有効にします（コメントを外します）。
```
LoadModule rewrite_module "/opt/WebOTX/WebServer2/modules/mod_rewrite.so"
```
  2. URLの書き換えルールを記述します
    例えば、コンテキストパスが "/sample/ap" の場合次のようになります。
```
RewriteEngine on
RewriteRule ^/samplep/ap/(.*)$ /sample_ap/$1 [PT,L]
RewriteRule ^/sample_ap/(.*)$ /sample/ap/$1 [R,L]
```
  設定が終わったら WebOTX Webサーバ、またはドメインを再起動します。
2. Cookie の設定を行います
  
  コンテキストパスに "/" を含む 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ファイルをアーカイブし直して配備します。

JSP実行の "name is too long to represent" の例外について
JSPファイル参照時に、コンパイルされたclassファイルの読み込みで、 JVMの問題による「java.lang.InternalError:name is too long to represent」という例外が発生する場合があります。この例外が発生する場合は、次のいずれかの対処を行ってください。
- JSPファイルのサイズを小さくする
- JSR-045デバッグ情報の設定をOFFにし、JSPコンパイルを行う
  
  ${INSTANCE_ROOT}/config/default-web.xml に次の設定を行うことで、 JSR-045デバッグ情報の設定をOFFにできます。
```
<servlet>
  <servlet-name>jsp</servlet-name>
    <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
      :
    <init-param>
      <param-name>suppressSmap</param-name>
      <param-value>true</param-value>
    </init-param>
```
  JSR-045デバッグ情報は、JSPコードとコンパイルしたclassファイルを関連付けるための情報です。

HTTP/AJPリスナの属性変更時の動作について
HTTPリスナやAJPリスナの属性やプロパティを変更すると、リスナが再起動して接続中のコネクションが切断されるためHTTPクライアントがエラーとなります。

AccessControlException が発生してクラスロードに失敗する
以下の様なログが出力されてクラスのロードに失敗する場合は下記のセキュリティポリシー定義を追加して下さい。
```
yyyy-mm-dd hh:MM:ss,sss INFO     WEBCONT  - Security Violation, attempt to use Restricted Class: ＜パッケージ名＞.＜クラス名＞ [http-thread-pool-80(1)]
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.sun")
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366)
	at java.security.AccessController.checkPermission(AccessController.java:560)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1529)
	at com.nec.webotx.enterprise.security.J2EESecurityManager.checkPackageAccess(J2EESecurityManager.java:104)
	at com.nec.webotx.as.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:2308)
```
${INSTANCE_ROOT}/config/server.policy に以下の定義を追加してください
```
grant codeBase "file:${com.nec.webotx.instanceRoot}/applications/＜アプリケーション名＞/-" {
    permission java.lang.RuntimePermission "accessClassInPackage.＜パッケージ名＞";
    permission java.lang.RuntimePermission "defineClassInPackage.＜パッケージ名＞";
};
```
なお、server.policy にポリシーを追加しても Security Violation のメッセージが抑止できない場合があります。現在確認できているのは次のケースです。
- log4j2-core.jarライブラリをWebアプリケーションで利用している、かつ、
  log4j2の設定ファイル中で、Configurationタグのstatus属性をdebug以上に設定している
  これは、log4j2 の処理の延長で Java の中の JavaScriptエンジンである「Nashorn」関連のクラスがログメッセージ用のリソースを取得する際にアクセス権限が無いため発生しています。このケースでは、Java の中の処理においてアクセス権のコンテキスト付け替えを行っているため、server.policy のポリシーが適用されません。
  
  しかし、本ケースでは Security Violation のメッセージは出力されるもののWebアプリケーションの動作への影響はありません。このため、このメッセージは無視していただくようお願いいたします。
  
  なお、log4j2を利用した本ケースに限らず同じ問題が発生する可能性があります。

配備解除後にアプリケーションディレクトリが残る場合
Webアプリケーション内の WEB-INF/lib 配下のJarファイル内に以下のリソースが存在する場合は配備解除後も ${INSTANCE_ROOT}/applications/${アプリケーション名} ディレクトリが削除されません。
```
META-INF/services/javax.servlet.ServletContainerInitializer
```
当該Jarファイルを任意のディレクトリに移動してnec-web.xmlのclass-loader要素のextra-class-pathでJarファイルのパスを指定してください。
```
<nec-web-app>
    <class-loader extra-class-path="Jarファイルのパス名"/>
</nec-web-app>
```
※任意のディレクトリに移動したJarファイルは、アプリケーション配備後はドメインを停止するまで削除できません。

配備解除後にアプリケーションディレクトリ配下のJARファイルが残る場合
Webアプリケーション内の WEB-INF/lib 配下のJarファイル内のリソースを読み込む実装がある場合に、JDKの java.net.URLClassLoaderがJarファイルを読み込みJarファイルがオープンされたままになるため、配備解除後も${INSTANCE_ROOT}/applications/${アプリケーション名}/WEB-INF/lib 配下の当該Jarファイルが削除されずに残る場合があります。
この場合nec-web.xmlのproperty要素でantiJARLocking=trueを指定してください。
```
<nec-web-app>
    <property name="antiJARLocking" value="true"/>
</nec-web-app>
```

Webアプリケーションで例外が発生した時のレスポンス内容について
WebOTX V9.2以前は、Webアプリケーションのサーブレット実行中に例外が発生した場合、リクエスト元のブラウザに例外のスタックトレースを含んだエラーレポートが表示されていました。

WebOTX V9.3では、例外が発生する前にサーブレットからレスポンスが出力されていた場合、そちらの内容を優先して返却するよう変更しています。例外スタックトレースの確認は以下のログファイルを参照してください。
- ${INSTANCE_ROOT}\logs\webotx_agent.log
- ${INSTANCE_ROOT}\logs\web\webotx_catalina.log

EAR内のServletにおけるEJBのインジェクションについて
スタンダードモード時、ServletとEJBを混在させたEARでServletに対するEJBのインジェクションができません。スタンダードモードでは、EARを作成せずにEJBとWARを個別に配備してください。

プリコンパイル指定での配備で指定できるパスについて
Webアプリケーションの配備時に "--precompilejsp=true" を指定して JSP のプリコンパイルを行う機能では、UNCパスを指定したディレクトリ配備には対応していません。

Comet アプリケーション利用時の注意事項について
Cometアプリケーションを動作させる場合は、HTTPリスナのプロトコルの種類をnioに設定してください。
運用管理コンソールの例：
アプリケーションサーバ >> ネットワーク構成 >> プロトコル構成 >> protocol >> HTTPリスナの「プロトコルの種類」を"http(nio)"に設定してください。

運用管理コマンドの例：
```
otxadmin> set server.network-config.protocols.protocol.http-listener.type=nio
```

bioリスナ利用時にクライアント認証が失敗する場合
Java SE Development Kit 7 (Update 211以降)またはJava SE Development Kit 8 (Update 201以降)の環境で、種別が"bio"のリスナの利用時にクライアント認証が失敗する場合は以下の設定変更を行ってください。(リスナの種別のデフォルトは"grizzly"です)
```
otxadmin> set server.network-config.protocols.protocol.https-listener.ssl.allow-unsafe-legacy-renegotiation=true
```
リスナ種別の確認方法
```
otxadmin> get server.network-config.protocols.protocol.https-listener.type
```

3.1.5. Standard/EnterpriseのアドバンスドモードでのWebアプリケーションの互換性

forward() で他のWebアプリケーションを呼び出す場合
Standard/EnterpriseでWebコンテナがアドバンスドモードで動作している場合、forwardによって呼び出せるWebアプリケーションは同じアプリケーショングループ、プロセスグループに配備されているWebアプリケーションのみです。これは、forwardの処理は、同一プロセスないで行うため、プロセスをまたがったWebアプリケーションの呼び出しができないためです。

WebアプリケーションからEJBの呼出しについて
Standard/EnterpriseでWebコンテナがアドバンスドモードで動作している場合、WebアプリケーションからのEJBの呼び出しはデフォルトではローカル呼び出しです。

アドバンスドモードにおけるセッションIDのフォーマットについて
Standard/Enterpriseにおいて Webコンテナがアドバンスドモード（複数プロセス）で動作している場合、HTTPリクエストを前回利用したプロセスに振り分けるために、セッションIDにプロセスIDを含めます。このためセッションIDのフォーマットが次のように変わります。

"セッションID(32桁) $ プロセスID"　　例：C7C25B729C39629558DB02C5FA25E038$6212

jvmRouteを付加した場合は次のように変わります。
"セッションID(32桁) . jvmRoute $ プロセスID"　　例:5B22AF53A66CAB1AB26490EB430D36C3.hoho1$3936

※プロセス数が１で、動的にプロセス数を変更する場合などプロセスIDを付加したい場合は、"-Dorg.apache.catalina.session.CompulsionPid=on"をプロセスグループのJVMオプションに設定してください。詳細は[ リファレンス集運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ > 1.4.7. HTTPセッション管理について > 1.4.7.4.WebOTXの高度な設定(アドバンスドモードでの設定) ] を参照してください。

アドバンスドモードにおけるレスポンスのバッファの仕組みについて
Standard/EnterpriseでWebコンテナがアドバンスドモードで動作している場合、Webアプリケーションのレスポンスのバッファの仕組みが異なります。同期処理の場合は、Webアプリケーションから書き込むバッファ（1次バッファ）からフラッシュされるとメモリ上もしくはファイルにバッファ（2次バッファ）します。リクエスト処理が完了後に、レスポンス全体をクライアントに返却します。なお、非同期処理の場合は、flushBufferのタイミングで、クライアントに返却します。

バッファ関連のメソッドの挙動は次の通りです。
- getBufferSize
  　1次バッファの情報が返却されます。
- setBufferSize
  　1次バッファのサイズを設定します。　なお、2次バッファの最大サイズは、次の設定で指定します。
  　com.nec.webotx.enterprise.web.connector.iiopSendMaxSize
- isCommitted
  　2次バッファに書き出されたかどうかを返却します。
- reset
  　コミット(2次バッファに書き出し)されていない場合は、1次バッファのデータを　クリアします。
  　　reset呼び出し前にサーブレットが設定したヘッダとステータス・コードはクリアされます。
- resetBuffer
  　レスポンスがまだコミット(2次バッファに書き出し)されていないときは、 1次バッファ内のコンテントをクリアするが、ヘッダとステータス・コードはクリアしない。もしそのレスポンスがコミット(2次バッファに書き出し)されており resetまたはresetBufferメソッドが呼ばれたときは、IllegalStateExceptionがスローされる。そのレスポンスとそれにかかわるバッファは変化しない。
- flushBuffer
  　同期処理の場合は、コミット(2次バッファに書き出し)します。クライアントへの返却は　リクエスト処理完了後に返却します。
  　非同期処理の場合は、コミットして、クライアントへ返却します。

3.1.6. エラーメッセージ

Web版統合運用管理コンソール(Ajax)利用時の例外について
HP-UXでGrizzlyコネクタを設定してWeb版統合運用管理コンソール(Ajax)を使用すると、webotx_agent.log に、"java.io.IOException: No buffer space available (errno:233)" が出力されることがありますが問題はありません。

このエラーは、以下の場合に発生します。
1. クライアントがGrizzlyコネクタへの新規 TCP 接続を行う。
2. その接続が、Grizzlyコネクタ LISTEN ソケット上でキューに入れられる。
3. クライアントがその接続で TCP リセットを送信する。
4. Grizzlyコネクタが Accept 呼び出しを実行する。

3.1.7. WebOTX のバージョン/エディション間の移行

Web Edition からその他の Edition に変える場合
このような場合はアプリケーションの作りによりそのままアプリケーションを移行しただけですと例外が発生するケースがあります。
例えば、Spring や Struts などのフレームワークを利用している場合がこれに該当する場合があります。

上記のようなフレームワークでは、認証に関する処理もフレームワークの中に実装している場合があります。このような場合、認証処理が J2EE に準拠した動作をする場合があります。これはアプリケーションが J2EE を意識するかしないかに関わらず動作する可能性があります。

このようなアプリケーションを V8.1以前の Web Edition で動作させていた場合は J2EE に関する処理は動作しません。

しかし V8.1以前の Standard-J Edition 以上、もしくは V8.2以降でこのようなアプリケーションを動作させた場合、Web Edition では動作していなかった J2EE の処理が動作し、予期せぬエラーが発生する場合があります。

もし、J2EE に準拠しない純粋な Webアプリケーションとして作成している場合は、上記のような現象が発生した場合 WebOTX を Web Edition 相当の動作をするよう設定変更してください。

設定方法：
　j2ee-enabled と sso-enabled を false に設定します。

運用管理コマンドの例：
```
otxadmin> set server.web-container.property.j2ee-enabled=false
otxadmin> set server.http-service.property.sso-enabled=false
```
＃マニュアルでは次の箇所を参照してください。
[ リファレンス集運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ > 1.4.2. Webコンテナ設定項目一覧 > 1.4.2.1. MOで設定可能な項目一覧 ] のj2ee-enabled と sso-enabledの箇所

forward後のレスポンスflush動作の違いについて
RequestDispatcherクラスの forward メソッドを利用してリクエストの別のサーブレットに転送した場合に、レスポンスがflush（コミットされてクライアントに返却される）されるタイミングがV7.x と V8.x で異なります。
- V7.x - forward元のリクエストが終了してからflush
- V8.x - forward先の処理が終了した時点でflush
上記のように、V7.x では forward先サーブレットの処理が終了しforward元に処理が戻り forward元のリクエストの処理も完全に終了してからレスポンスがflushされます。一方 V8.x は forward先サーブレットの処理が終了して forward元サーブレットに戻った時点でレスポンスがflushされます。

既定値では上記の動作ですが、設定により変更が可能です。設定方法は次の2通りです。
- JavaVMオプション指定
- nec-web.xml で指定
JavaVMオプションでは次のオプションを指定します。

com.nec.webotx.enterprise.forwardResponseFlush

例）
```
otxadmin> create-jvm-options -Dcom.nec.webotx.enterprise.forwardResponseFlush=true
```
nec-web.xmlでは次のプロパティで指定します。
```
   <nec-web-app>
      <context-root>コンテキストA</context-root>
      <property name="forwardResponseFlush" value="true"/>
          :
```
両方とも、true(V8.xの動作)/false(V7.xの動作)が指定可能です。規定値はV8.xの場合はtrue、V7.xの場合はfalseとなります。

JavaVMオプションの有効範囲は全Webアプリケーション、nec-web.xmlの有効反映はWebアプリケーション内です。両方指定された場合はnec-web.xmlでの指定が優先します。

※本設定はスタンダードモードでのみ有効です。アドバンスドモードでは常に V7.x の動作となります。

3.1.8. 警告メッセージ

ドメイン停止中の警告ログについて
ドメイン停止中にリクエストが来た場合にwebotx_agent.logに以下のログが出力される事がありますが、これはドメイン停止処理中に同時にリクエスト処理が実行されたことによるものですのでシステムへの影響はありません。
```
WARN     com.nec.webotx - Uncaught thread exception. Thread: ＜スレッド名＞
```

3.1.9. アドバンスドモードでWebサービスのコンテキストマッピング情報が出力されない

アドバンスドモード御利用の場合にはWebサービスのコンテキストマッピング情報が"${INSTANCE_ROOT}/config/WebCont/uriworkermap.properties-auto"に出力されません。このため、デフォルトで有効な動的反映機能を使って頂くか、Webコンテナ連携ファイルをカスタマイズして手動でコンテキストマッピング情報を定義してください。

3.2. 制限事項

3.2.1. Webコンテナの運用/管理

アドバンスドモードにおけるIIOPリスナとAJPリスナの切り替えについて
本制限事項はV9.31で解除されました。

WebOTX V9.3 より、アドバンスドモード利用時にWebコンテナとWebサーバの連携モードを AJP と IIOP のどちらにするか選択することができます。WebOTX V9.3 インストール後にこの連携モードを切換える場合、切換え実施後、ドメイン再起動前に以下のファイルを削除する必要があります。

　　${INSTANCE_ROOT}\config\WebCont\uriworkermap.properties-auto

WebコンテナとWebサーバ間の連携モード切換え時の手順は以下のとおりです。
1. TPシステム停止（※1）
2. Webサーバ停止
3. WebコンテナとWebサーバの連携モードの切換え」を実施（※2）
4. uriworkermap.properties-auto の削除
5. ドメイン再起動
※1 TPシステム停止の詳細については WebOTXオンラインマニュアルの以下を参照してください。 [ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.1. TPシステム > 7.1.1. 操作・状態確認(TPシステム) > 7.1.1.3. 起動・停止]

※2「WebコンテナとWebサーバの連携モードの切換え」の詳細については WebOTXオンラインマニュアルの以下にある連携モード(advanced-mode-protocol)変更に関する注意事項の「統合運用管理コンソールから設定」または「コマンドから設定」を参照してください。 [リファレンス集運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ > 1.4.2. Webコンテナ設定項目一覧 > 1.4.2.1. MOで設定可能な項目一覧]

アドバンスドモードでのリクエスト／レスポンスデータサイズの制限
アドバンスドモードでファイルのアップロード／ダウンロード等を行う場合、2Gbyteを超えるデータサイズのアップロード／ダウンロードは行えません。

3.2.2. Webアプリケーションの運用/実行

ルートコンテキスト(/)に配備した場合バージョン管理機能が利用できない
セッション振り分けバージョン管理機能について、ルートコンテキスト(/)に配備したWebアプリケーションはsetコマンドによるカレントバージョン変更が効きません。バージョン付加による配備は可能ですが、カレントバージョンはバージョン情報を文字列比較して最大のものが常に使用されます。

InvokerServlet では排他制御により性能が出ない

本制限事項はV9.31で解除されました。

InvokerServletのリクエスト処理時には排他が掛かるため、InvokerServletを利用してServletをリクエスト処理すると複数のリクエストが同時に行われた場合に待ち合わせが発生します。待ち合わせを無くすにはInvokerServletを使用しないようにする必要があります。
また、セキュリティ観点から、制限なくサーブレットが実行されてしまうInvokerServletの使用は推奨していません。

InvokerServletを使用しないようにするには、Webアプリケーションのweb.xmlに各Servlet毎の定義を行うように変更します。

○InvokerServletを使用している場合のweb.xml設定例)

<web-app>
    :
  <servlet>
    <servlet-name>invoker</servlet-name>
    <servlet-class>org.apache.catalina.servlets.InvokerServlet</servlet-class>
    <init-param>
      <param-name>debug</param-name>
      <param-value>0</param-value>
    </init-param>
    <load-on-startup>99</load-on-startup>
  </servlet>
    :
  <servlet-mapping>
    <servlet-name>invoker</servlet-name>
    <url-pattern>/servlet/*</url-pattern>
  </servlet-mapping>
    :

○Servlet毎の設定を行ったweb.xmlの設定例)

<web-app>
    :
    <servlet>
        <servlet-name>fooServlet1</servlet-name>
        <servlet-class>foo.fooServlet1</servlet-class>
    </servlet>
    <servlet>
        <servlet-name>fooServlet2</servlet-name>
        <servlet-class>foo.fooServlet2</servlet-class>
    </servlet>
        :
    <servlet-mapping>
        <servlet-name>fooServlet1</servlet-name>
        <url-pattern>/servlet/fooServlet1</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>fooServlet2</servlet-name>
        <url-pattern>/servlet/fooServlet2</url-pattern>
    </servlet-mapping>
    :

default-web-moduleを設定したvirtual-server の hostsに既定値の"localhost"以外を指定するとドメイン起動時にエラーが発生する
本制限事項はV9.4で解除されました。

default-web-moduleを設定したvirtual-serverのhostsには、既定値の"localhost"を設定してください。
```
otxadmin> set server.http-service.virtual-server.<VirtualサーバID>.hosts=localhost
```

WebSocket APIの javax.websocket.Session#getOpenSessions() で自Sessionしか取れない
本制限事項はV9.6で解除されました。

javax.websocket.Session#getOpenSessions() で同じEndpointに接続している他のSessionが取得できません。
このためSessionの管理はonOpenイベントやonCloseイベントを使ってアプリケーション側で行ってください。

Websocket Endpointでの"@Inject" アノテーションの未サポート
WebSocket1.1仕様の「7.1.1 Websocket Endpoints and Dependency Injection」に定義されているWebsocket Endpointの@Injectアノテーションは未サポートです。独自にインスタンス生成等の実装を行ってください。