3. Webコンテナ

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

3.1. 注意事項

3.1.1. 環境設定

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

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

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

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]

通信に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サーバ用通信コネクタ

otxadmin> set server.network-config.protocols.protocol.admin-listener.type=bio

otxadmin> set server.network-config.protocols.protocol.admin-listener.type=bio

otxadmin> get server.network-config.protocols.protocol.http-listener.type
  server.network-config.protocols.protocol.http-listener.type = grizzly

otxadmin> set server.network-config.protocols.protocol.http-listener.type=bio

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

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アプリケーションにアクセスするなどした場合(通常は HTTP404エラー)、ブラウザの設定によりダウンロード処理が始まることがあります。
ブラウザの設定を変更することで回避することができます。
　　例) IE6の場合
　　　　メニューより「ツール」-「インターネットオプション」-「詳細設定」で「ブラウズ」-「HTTPエラーメッセージを簡易表示する」のチェックをONにする。

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サーバと連携した場合、logsディレクトリに以下のようなファイルが作成されます。

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

これらは、JKコネクタ（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をダブルクリックして実行し、レジストリを設定します。ダブルクリック後、レジストリエディタの確認画面が表示されるので、「はい」を押して設定を行ってください。
上記の手順を実施した後、環境設定ツールによる環境設定を実行してください。

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
```
また、上記オプションの設定有無に関わらず、ファイルが存在しない場合は自動で作成されます。

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

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

外部Webサーバと連携している時、JkMount の記載方法によっては正常に振り分けられません。
例えば、次のような場合です。

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

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

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

　JkMount /sample/* ajp13

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

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アプリケーション毎に一意の指定をしてください。

JSP を含む Webアプリケーションを実行すると、パーミッションエラーで JSP のコンパイルが失敗する事があります。この場合、使用する JDK のバージョンに合ったクラスが使用されているかを確認してください。具体的には、利用している JDK に付属の tools.jar が使用されているかを確認します。異なったバージョンの tools.jar がクラスパスに指定されていると正しくコンパイルできない恐れがあります。

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アプリケーション内のクラスを参照する場合、そのクラスはパッケージ化（package 宣言）されている必要があります。

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

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

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

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

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

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

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

Webアプリケーションの配備情報をweb.xmlから取得しているため、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以前にまたがってセッションレプリケーションの連携をすることができません。

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

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)

WebOTX ではアプリケーション配備時にそのアプリケーションに含まれる web.xml および nec-web.xml の内容をドメイン配下に保存します（${INSTANECE_ROOT}/generated/xml/[AP名]/appDescr.dat）。このため、配備したアプリケーションの web.xml 等を直接編集しても反映されません。内容を変更したい場合は再配備してください。

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

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

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

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

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

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

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. 他APサーバ(Tomcat)からWebOTXへの移行ガイド > 2.3. 移行作業 > 2.3.6. WebOTX独自のWebアプリケーション配備記述子（nec-web.xml） > 2.3.6.5. no-cache の設定 ] を参照してください。

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

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

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

詳細は、[ リファレンス集ドメイン構成・環境移行編 > 2. 他APサーバ(Tomcat)からWebOTXへの移行ガイド > 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ファイル参照時に、コンパイルされた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クライアントがエラーとなります。

以下の様なログが出力されてクラスのロードに失敗する場合は下記のセキュリティポリシー定義を追加して下さい。

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.＜パッケージ名＞";
};

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ファイルは、アプリケーション配備後はドメインを停止するまで削除できません。

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>
```

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

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

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

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. エラーメッセージ

webotx_agent.log に、"java.io.IOException: No buffer space available (errno:233)"が出力されることについて。

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.2. 制限事項

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

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

アドバンスドモードでは、IIOPプラグインの機能を利用した負荷分散機能をサポートしていません。

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

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

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

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

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

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