3. Webコンテナ

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

3.1. 注意事項

3.1.1. 環境設定

3.1.1.1. 環境設定ツールの起動方法について

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

3.1.1.2. 環境設定時に初期化されるファイルについて

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


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

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

3.1.2.1. JSPエンジンのログレベルを上げた場合

JSP のログレベルを "DEBUG" 以上に変更すると、JSP でリクエストパラメータを取得した時に文字化けが発生します。

ログレベルを "DEBUG" に変更すると、JSP処理コンポーネントが処理するデータをログに記録します。障害調査などを目的としたログであるためブラウザから渡されてきたそのままのデータを記録します。このため、JSP でリクエストパラメータ取得時の文字コードを設定する前にリクエストパラメータを分解します。この結果、文字コードの設定が効かずアプリケーションで文字化けが発生します。

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

3.1.2.2. 大量のリクエストパラメータを処理する場合

多量のパラメータを持つリクエストを処理すると、パラメータ解析処理に過剰な負荷が掛かかりドメインが動作できなくなる問題(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]

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

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

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

[確認方法]

  1. スレッドダンプの採取
     > kill -QUIT <PID> 
        ・PIDは{ドメインディレクトリ}/config/server_pidを参照
        ・10秒間隔で1分程度採取します。
        ・結果は{ドメインディレクトリ}/logs/server.logに出力
    
  2. CPUリソースを消費しているスレッドの特定

  3. スレッドダンプから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コネクタに変更することで現象を回避します。

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


3.1.2.4. 全てのクライアントからリクエストを受けるための設定

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サーバ連携

3.1.3.1. /scripts/jrun.dll/ というリクエストで404エラーが発生する

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

3.1.3.2. 動的反映機能がOFF(無効)の時に404エラーが発生する

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

3.1.3.3. IIS連携時に匿名アクセスを有効にしていない場合

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

3.1.3.4. IIS連携時に「ファンクションが間違っています」と表示される

IIS連携時、isapiプラグインから設定ファイルuriworkersmap.properties-autoが読み込めていないために、「ファンクションが間違っています」と表示される場合があります。その場合、次の設定を行ってください。

3.1.3.5. IIS連携時にWebサーバプラグインのログが出力されない

IIS連携時に、JKコネクタ(Webサーバプラグイン)のログが指定しているディレクトリに出力されない場合があります。
次の処理を行ってください。

  1. ${INSTANECE_ROOT}\logsの「プロパティ」を開き、「セキュリティ」タブで「追加」ボタンをクリックします。
  2. 「ユーザーまたはグループの選択」ダイアログで自マシンの NETWORK SERVICE を選択し OK します。
  3. 「詳細設定」ボタンをクリックします。
  4. 「セキュリティの詳細設定」ダイアログの「アクセス許可」タブで「追加」ボタンをクリックします。
  5. 「ユーザーまたはグループの選択」ダイアログで自マシンの NETWORK SERVICE を選択し OK します。
  6. 「アクセス許可エントリ」ダイアログの「適用先」で「このフォルダとサブフォルダ」を選択し、「アクセス許可」で「ファイルの作成/データの書き込み」と「フォルダの作成/データの追加」をチェックして OK します。
  7. 「セキュリティの詳細設定」ダイアログ、「プロパティ」を OK して閉じます。

3.1.3.6. Webサーバの連携解除について

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

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

3.1.3.7. 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

3.1.3.8. 配備解除したWebアプリケーションへのアクセスでダウンロードが開始される場合

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

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

3.1.3.9. Webアプリケーションのルートコンテキスト("/")への割り当てについて

3.1.3.10. 外部Webサーバと連携のログファイルについて

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

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

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

3.1.3.11. Webサーバ側に配置したコンテンツへのアクセスでエラーログが記録される

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

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

3.1.3.12. 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をダブルクリックして実行し、レジストリを設定します。ダブルクリック後、レジストリエディタの確認画面が表示されるので、「はい」を押して設定を行ってください。

上記の手順を実施した後、環境設定ツールによる環境設定を実行してください。

3.1.3.13. 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

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

3.1.3.14. アドバンスドモード(IIOP) で名前解決が失敗する場合

アドバンスドモードでは、Webサーバ(IIOPプラグイン)とWebOTX(IIOPリスナ)の間を、IIOPで通信しています。このIIOPのWebサーバからの接続先を示す情報(ホスト名、IIOPリスナのポート番号)がhttpgateway.iorに入っています。ここに記述されているホスト名がマシンで名前解決できるホスト名でない場合、通信に失敗し、エラーが発生します。次の設定を行ってください。

3.1.3.15. 外部Webサーバ連携時にリクエストの振り分けがうまくいかない場合

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

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

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

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

 JkMount /sample/* ajp13

3.1.3.16. 別マシンからプラグイン設定項目を行う場合

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

3.1.3.17. IIS連携の設定に必要なコンポーネントについて

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

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

3.1.4.1. <load-on-startup>要素が空の場合

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

3.1.4.2. 「ファイル転送サンプル」を実行する前の設定について

WebOTX に付属する「ファイル転送サンプル」を実行する場合、実行に先立って次のポリシーをドメインディレクトリの config/server.policy に追加してください。

grant {
   permission java.io.FilePermission 
      "${com.nec.webotx.instanceRoot}${/}applications${/}fileupdownload${/}-", "read,write,delete";
};

3.1.4.3. Webアプリケーション名とコンテキストルートは重複して配備できない

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

3.1.4.4. JSPコンパイル時のパーミッションエラーについて

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

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

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

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

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

3.1.4.6. JSPで同じ Webアプリケーション内のクラスを参照する場合

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

3.1.4.7. web.xml自体の文字エンコーディング指定について

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

3.1.4.8. Webアプリケーションを一時停止した場合の動きについて

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

3.1.4.9. サイズの大きいWARファイルを配備した時のエラーについて

あるサイズ以上(数百KBから数MB)の WARファイルを Webコンテナに配備すると、次のエラーが発生する事があります。

"Internal server error. reason: JNDI information get error:
error in opening zip file"

この場合、次の JavaVM オプションを指定してください。このオプションを指定しても同じエラーが発生する場合は、より大きな値を試してください。

"-Xss512k"

3.1.4.10. WARファイル名に使用する文字種別について

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

3.1.4.11. Servlet のリスナ機能の中でJNDIを利用する場合

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

3.1.4.12. web.xml の error-page に指定するコンテンツについて

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

3.1.4.13. autodeploy で配備するWARファイルのパーミッションについて

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

3.1.4.14. Servlet 2.5 以前の Webアプリケーションにおける web.xml について

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

3.1.4.15. 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アプリケーションに該当します。

3.1.4.16. WebOTX V6.5以前と V7以降のセッション情報格納仕様の違いについて

WebOTX Application Server V7.1からセッション情報を格納する仕様が異なります。このため、WebOTX Application Server V7.1以降とWebOTX V6.5以前にまたがってセッションレプリケーションの連携をすることができません。

3.1.4.17. セッションレプリケーション利用時に格納するオブジェクトについて

セッションレプリケーションを行う場合、格納するオブジェクトに注意事項があります。

また、この注意事項はアドバンスドモードでの「プロセス間コンテキスト属性共有」を行う場合にも該当します。
詳細は以下を参照してください。
[リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ > 1.4.7. HTTPセッション管理について > 1.4.7.3.セッションレプリケーション > Webアプリケーション実装の注意/制限事項]

3.1.4.18. セッションレプリケーションの非同期モードにおける注意事項について

セッションレプリケーション非同期モードには、以下の注意点があります。

3.1.4.19. セッションレプリケーションの同期モードにおける注意事項について

セッションレプリケーション同期モードには、以下の注意点があります。

3.1.4.20. Oracle Coherence 利用時の注意事項について

Oracle Coherenceを使用する場合、以下の注意点があります。

3.1.4.21. 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)

3.1.4.22. 配備後の web.xml の扱いについて

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

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

3.1.4.23. 複数の仮想サーバが存在する時の動きについて

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

3.1.4.24. WebOTX V8.1以降の静的ファイルのキャッシュについて

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

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

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

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

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

3.1.4.25. Internet Explorer 利用時にSSL通信が失敗する

Internet Explorerのバグにより以下の条件を全て満たす場合、SSL通信でのXMLドキュメントの取得に失敗します。

詳細は以下のサイトを参照してください。
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 の設定 ] を参照してください。

3.1.4.26. Internet Explorer 利用時に Cookie が保存されない

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

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

3.1.4.27. WebOTX V8 から V9 への移行における互換性について

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

詳細は、[ リファレンス集 ドメイン構成・環境移行編 > 2. 他APサーバ(Tomcat)からWebOTXへの移行ガイド > 2.3. 移行作業 > 2.3.8. Tomcatの差異による対応 ] を参照してください。

3.1.4.28. コンテキストパスに "/" を含む場合の注意事項

コンテキストパス(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ファイルをアーカイブし直して配備します。

3.1.4.29. JSP実行の "name is too long to represent" の例外について

JSPファイル参照時に、コンパイルされたclassファイルの読み込みで、 JVMの問題による「java.lang.InternalError:name is too long to represent」という 例外が発生する場合があります。 この例外が発生する場合は、次のいずれかの対処を行ってください。

3.1.4.30. HTTP/AJPリスナの属性変更時の動作について

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

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

3.1.4.32. 配備解除後にアプリケーションディレクトリが残る場合

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

3.1.4.33. 配備解除後にアプリケーションディレクトリ配下の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.4.34. Webアプリケーションで例外が発生した時のレスポンス内容について

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

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

3.1.4.35. EAR内のServletにおけるEJBのインジェクションについて

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

3.1.4.36. プリコンパイル指定での配備で指定できるパスについて

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

3.1.4.37. Comet アプリケーション利用時の注意事項について

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

運用管理コマンドの例:

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

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

3.1.5.1. forward() で他のWebアプリケーションを呼び出す場合

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

3.1.5.2. WebアプリケーションからEJBの呼出しについて

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

3.1.5.3. アドバンスドモードにおけるセッションIDのフォーマットについて

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

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

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

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

3.1.5.4. アドバンスドモードにおけるレスポンスのバッファの仕組みについて

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

バッファ関連のメソッドの挙動は次の通りです。

3.1.6. エラーメッセージ

3.1.6.1. 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 の バージョン/エディション 間の移行

3.1.7.1. 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の箇所

3.1.7.2. forward後のレスポンスflush動作の違いについて

RequestDispatcherクラスの forward メソッドを利用してリクエストの別のサーブレットに転送した場合に、レスポンスがflush(コミットされてクライアントに返却される)されるタイミングがV7.x と V8.x で異なります。

上記のように、V7.x では forward先サーブレットの処理が終了しforward元に処理が戻り forward元のリクエストの処理も完全に 終了してからレスポンスがflushされます。一方 V8.x は forward先サーブレットの処理が終了して forward元サーブレットに戻った時点でレスポンスがflushされます。

既定値では上記の動作ですが、設定により変更が可能です。設定方法は次の2通りです。

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

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

3.2.1.1. アドバンスドモードにおける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で設定可能な項目一覧]

3.2.1.2. UNIX環境でアドバンスドモードかつ連携モードにIIOPプロトコルを使用している場合はコマンドでのWebOTX Webサーバの起動に失敗する

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

以下の条件に全て合致する場合は、${INSTANCE_ROOT}/bin/apachectl.sh でのWebOTX Webサーバの起動ができません。
ドメインの起動によってWebOTX Webサーバを起動してください。

3.2.1.3. 内蔵Webサーバでデフォルトのプロトコルタイプ利用時のスレッド名出力について

内蔵Webサーバでデフォルトのプロトコルタイプ利用時に、ドメイン > アプリケーションサーバ > HTTPサービス > アクセスログに "%I" を追記してもスレッド名は出力されません。

log4otx.xmlの以下を変更する事でスレッド名を出力してください。

・対象appender
<appender 〜 name="ACCESSFILELOGSERVER">

・変更内容
layout要素配下のname属性が"ConversionPattern"のparam要素のvalueに"%t"を追加します。
変更前: <param value="%m %n" name="ConversionPattern"/>
変更後: <param value="%m %t %n" name="ConversionPattern"/>


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

3.2.2.1. ルートコンテキスト(/)に配備した場合バージョン管理機能が利用できない

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

3.2.2.2. 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>
    :

3.2.2.3. default-web-moduleを設定したvirtual-server の hostsに既定値の"localhost"以外を指定するとドメイン起動時にエラーが発生する

default-web-moduleを設定したvirtual-serverのhostsには、既定値の"localhost"を設定してください。

otxadmin> set server.http-service.virtual-server.<VirtualサーバID>.hosts=localhost

3.2.2.4. HttpServletRequestからgetReader()したBufferedReaderから8193バイト以上のデータが取得できない

以下の様にgetReader()したBufferedReaderからリクエストデータを取得する場合は8192バイトまでしか取得できません。

protected void doPost(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    BufferedReader br = request.getReader();
    String line = null;

    while((line = br.readLine()) != null){
        ・・・
    }
    ・・・

8192バイトを超えるリクエストデータを取得する場合は、代わりにgetInputStream()でServletInputStreamを取得し、それを利用して下さい。

protected void doPost(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    ServletInputStream sis = request.getInputStream();
    byte[] b = ・・・
    int size = 0;

    while((size = sis.read(b)) > -1){
        ・・・
    }
    ・・・

3.2.2.5. JDBCレルムを使用するとパスワードの文字数が偶数の場合に認証エラーとなる

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

JDBCレルムを使用すると、パスワードの文字数が偶数の場合に正しい認証情報にも関わらずBASIC/FORM/DIGEST認証に失敗します。
パスワードにASCII文字のみを使う場合は以下のプロパティを設定する事で回避可能です。

運用管理コンソールの場合:
ドメイン名 >> アプリケーションサーバ >> セキュリティサービス >> 認証レルム >> レルム名 >> [操作]タブ >> プロパティの設定
⇒charset=ISO-8859-1

運用管理コマンドの場合

otxadmin> set server.security-service.auth-realm.{レルム名}.property.charset=ISO-8859-1

ドメインを再起動し、設定を反映してください。