2. 他APサーバ(Tomcat)からWebOTXへの移行ガイド

2.1. はじめに

Webシステム構築において、コスト削減の面からオープンソース導入が注目されています。しかし、保守運用までを見据えた場合、本当にコスト削減が達成できるのか、という疑問の声もよく耳にします。

WebOTX V9シリーズでは、サン・マイクロシステムズ社が中心に仕様策定した、エンタープライズ領域の Java仕様「Java Platform, Enterprise Edition 6　(Java EE 6)」に準拠した製品を提供しています。WebOTX ASは、その機能群の中のWeb層として、Apache TomcatプロジェクトのオープンソースTomcat 7.0をベースにサーブレットやJSPなどのWebアプリケーション実行環境(Webコンテナ)を組み込んでいます。

WebOTX V9.2で提供するWebコンテナは、Apache Tomcat 7.0.42 をベースに品質の改良、機能の追加、性能の向上、運用性の強化などを施しています。このため、現在Apache Tomcat (以下、略してTomcatと呼びます) 上で動作しているWebアプリケーションを少ない労力でWebOTXに移行でき、かつ、システムの信頼性、運用性、性能等の向上を手に入れることができます。

2.1.1. 対象読者

本章は、既にTomcatを利用して何らかのシステムを運用している方や、利用経験のある方、Tomcatの知識を有している方などを対象に、既存のTomcatによる構築済みシステムをWebOTXに移行する際の作業を支援するガイドです。
また、WebOTX V8以前や、その他のAPサーバ(JRun、WebLogic、WebSphereなど)からWebOTX V9.2に移行する際の作業も支援します。

対象とする移行パターンは以下のとおりです。

Tomcat 3.x → WebOTX V9.2

Tomcat 4.x → WebOTX V9.2

Tomcat 5.0.x → WebOTX V9.2

Tomcat 5.5.x → WebOTX V9.2

Tomcat 6.x → WebOTX V9.2

WebOTX V5.x → WebOTX V9.2

WebOTX V6.x → WebOTX V9.2

WebOTX V7.x → WebOTX V9.2

WebOTX V8.x → WebOTX V9.2

WebOTX V9.1 → WebOTX V9.2

その他のAPサーバ(JRun、WebLogic、WebSphereなど) → WebOTX V9.2

2.2. ソフトウェア条件

WebOTXがサポートするソフトウェアについて説明します。

WebOTXに移行することにより、J2SE SDKやデータベースのバージョンを変更する場合、関連するソフトウェアのバージョンアップの必要性を確認してください。

詳細については、[ セットアップガイド > 1. 使用上の条件 ] をご覧ください。

2.2.1. 対象プラットフォーム

WebOTX がサポートするOSとJ2SE SDKのバージョンは以下を参照してください。

• セットアップガイド > 1. 使用上の条件 > 1.2. ソフトウェア条件について > 1.2.1. オペレーティング・システム

2.2.2. Webサーバ

WebOTX がサポートする外部Webサーバは以下を参照してください。

• セットアップガイド > 1. 使用上の条件 > 1.2. ソフトウェア条件について > 1.2.5. 対応ソフトウェア > 1.2.5.1. Webサーバ

2.2.3. データベース

WebOTX がサポートする対象のデータベースは以下を参照してください。

• セットアップガイド > 1. 使用上の条件 > 1.2. ソフトウェア条件について > 1.2.5. 対応ソフトウェア > 1.2.5.2. データベース・サーバ

2.2.4. 同梱するライブラリ

WebOTXに同梱しているライブラリとバージョンは次の表のとおりです。

*1：パッケージ名をWebOTX独自のものに変更しているため、ユーザアプリケーションから利用できません。Webアプリケーションで利用する場合は、WEB-INF/libの下にライブラリを配置してください

*2：標準ではクラスパスに含まれておりません。ライブラリの格納先は${AS_INSTALL}/lib/wssに移動しました。利用する場合は、クラスパスに含めるようにしてください。

2.2.5. クラスのロードについて

Webアプリケーションで利用するJavaのクラスを実行するためにロードを行う機能としてクラスローダがあります。

クラスローダには階層があります。上位のクラスローダでロードされたクラスからは下位のクラスローダでロードされたクラスは参照することができません。

逆に、下位のクラスローダでロードされたクラスからは、上位のクラスローダでロードされたクラスは参照することができます。

Webアプリケーションで使用するライブラリはWEB-IN/lib に配置します。複数のアプリケーションでライブラリを共有したい場合はWebOTX/libやdomain1/libに配置します

WebOTX のクラスローダの階層は次のようになります。

また、nec-web.xml のdelegate の設定により、ロードする優先順位を決定することができます。

同じ名前のライブラリがあると、競合が発生し、優先順位の高いパスに含まれるライブラリが利用されます。

delegate=false の場合は以下のようになります。

2.3. 移行作業

本章では、TomcatやWebOTX V5-V8.42などからWebOTXに移行する際に必要となる作業について説明します。

2.3.1. ディレクトリ構成

WebOTXのドメインに関連する主要なディレクトリは次のようになっています。

図2.3.1-1

2.3.2. 移行作業一覧

Tomcatの各バージョンからWebOTXに移行するための作業と、本書での説明の対応は以下のとおりです。

2.3.2.1. パッケージの設定

既存のJSPコードにおいて、他のクラスをインポート(import)している場合にはパッケージを指定しなければなりません。これはJDK 1.4からJavacコンパイラがJava言語仕様へ厳密にチェックするように変わったことに起因します。J2SE 1.4.0より前のバージョンでは、パッケージの指定は必要ありませんでしたが、J2SE 1.4.0以降ではパッケージの指定が必要になっています。

2.3.2.2. JDBCデータソースの設定

Tomcatでは、「conf/server.xml」ファイルを直接修正することでJDBCデータソースの設定を行いますが、WebOTXでは、JMX (Java Management Extensions) に対応した運用管理コンソールや運用管理コマンドで設定します。 WebOTXでは、データベース・サーバへの接続をファクトリ化し、JNDI API経由で接続オブジェクト参照を得る仕組みとしてJDBCデータソースを提供しています。JDBCデータソースは、分散トランザクションやコネクション・プーリングなどを考慮しているため、単にJDBCドライバのインタフェースを呼び出す場合よりも機能拡張されています。

既存のWebアプリケーションにおいてJDBCデータソースを使用している場合、JDBCデータソースを利用するための設定を行う必要があります。

2.3.2.3. log4jの設定

WebOTX Application Server V8 以降のバージョンでは、 Apache Logging Server プロジェクトの log4j のパッケージ名を変えてバンドルしており WebOTX自身のロギング機能にlog4jを利用しています。このため、既存のWebアプリケーションでlog4jを利用してログ出力している場合、WebOTX の定義を気にする事なく利用可能です。

2.3.2.4. nec-web.xmlの設定

既存のWebアプリケーションにおいて、StrutsなどのライブラリJARファイルや、WebOTX以外のCORBAライブラリをWARファイル内の「WEB-INF/lib」配下に格納している場合、また、CORBAライブラリについては、WebOTXに含まれるライブラリと重なる場合、Webアプリケーションを配備できないなどの問題が発生することがあります。Webアプリケーションを、そのままのファイル構成でご利用いただくには、nec-web.xmlでライブラリのロードに関する設定を行います。

2.3.2.5. セキュリティポリシーの設定

WebOTXは、インストール・デフォルトの定義によりJavaセキュリティ・マネージャが動作します。Javaセキュリティ・マネージャが働くことで、Webアプリケーションの実行中に、システム上のファイルや他システムへの接続などの資源に対する不用意なアクセスを制限できます。このため、現行システムでセキュリティポリシーを設定していない場合は、WebOTX移行に際してはセキュリティポリシーの設定が必要となります。　また、現行システムでセキュリティポリシーを設定している場合は、既存のセキュリティポリシー設定を移行する必要があります。

2.3.2.6. Tomcatの差異による対応

Tomcatの各バージョンの差異(ベースのTomcatバージョンの差異)により、WebOTXに移行する際に対応が必要となる場合があります。

2.3.2.7. JavaVMオプションの設定

WebOTXは、Tomcatと同様にJavaVMのオプション設定をサポートしています。このため、既存のTomcatシステムでJavaVMオプションの設定を行っている場合はWebOTXにも同様の設定を行う必要があります。詳細は 2.5.2. Java VMオプションのサポートを参照ください。

2.3.3. パッケージの設定

JSPで他のクラスをインポート (import) している場合には、パッケージの指定が必要です。

これまでJava2 SDK 1.3.1以前を使用していた場合は、そのJavacコンパイラの構文チェックが緩かったために問題とはなりませんでした。しかし、J2SE 1.4.0からは構文チェックが厳しくなり、パッケージを持たないJSPコードは、JSPをWebOTXに配備した後に行われるJSPコンパイルでエラーとなります。なお、WebOTX V9は、JDK 7 のみをサポートします。

J2SE 1.3.1以前のバージョンから移行する場合には、importのパッケージの指定を確認してください。

次のようにパッケージの指定のないimportはエラーとなります。

<%@ page import="Converter,ConverterHome" %>

importするクラスにパッケージの指定を追加して、importの指定をそれにあわせて修正してください。

本設定は、includeするファイルも含めて各ファイルで指定してください。

2.3.4. JDBCデータソースの設定

WebOTXのJDBCデータソースを利用するためには、WebOTX運用環境製品で提供している「統合運用管理ツール」か、標準で備わる「運用管理コマンド (otxadmin)」を利用します。ここでは、運用管理コマンドを利用する設定について説明します。

設定内容の詳細や運用機能の詳細は、WebOTXマニュアルの中の [ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.2. 運用管理コマンド(otxadmin) ]、 [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) ] をご参照ください。

2.3.4.1. JDBCデータソースの設定方法

運用管理コマンドよりJDBCデータソースをJNDIに登録します。

以下は、WebOTXをインストールした際にデフォルトで作成されるドメイン「domain1」上でOracleデータベース・サーバを利用するJDBCデータソースを登録するコマンド例です。

otxadmin> create-jdbc-datasource --user admin --password adminadmin 
--port 6212 --host localhost 
--dataSourceType JDBCEX_Oracle 
--jdbcMajorVersion 3 --maxPoolSize 10 
--jdbcUserName scott --jdbcPassword tiger 
--dataSourceName "jdbc:oracle:thin:@hostname:1521:ORCL" 
jdbc/MyOracle

※ 実際には1行で実行してください。

※ 各引数の詳細は、WebOTXマニュアルの [ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.2. 運用管理コマンド(otxadmin) ]、 の "create-jdbc-datasource" を参照してください。

※"jdbc:oracle:thin:@hostname:1521:ORCL"　および jdbc/MyOracle 部分は環境に合わせて変更してください。

登録が成功すると次のように表示されます。

> Command create-jdbc-datasource executed successfully.

現在の設定を確認する場合は、次のコマンドを実行します。

otxadmin> list-jdbc-datasources --user admin --password adminadmin --port 6212

2.3.4.2. クラスパスの設定

Oracleデータベース・サーバに付属するJDBCドライバ (ojdbc6.jar) が配置されたディレクトリにクラスパスを設定します。 以下はdomain1ドメインにクラスパスを設定するコマンド例です。

現状のクラスパスを確認します。

・スタンダードモードの場合

otxadmin> get server.java-config.server-classpath

・アドバンスドモードの場合

otxadmin> get tpsystem.applicationGroups.apg.processGroups.pg.setenvList

※ 実際には1行で実行してください。

現状のクラスパスにJDBCドライバのクラスパスを追加設定します。

・スタンダードモードの場合

otxadmin> set server.java-config.server-classpath=…;/temp/ojdbc6.jar

・アドバンスドモードの場合

otxadmin> add-pg-setenv --apgroup <APG名> --setenv CLASSPATH --value …;/temp/ojdbc6.jar <PG名>

※ <APG名> にはアプリケーショングループ名、<PG名> にはプロセスグループ名が入ります。

※ "/temp/ojdbc6.jar"部分は環境に合わせて変更してください。

※ 実際には１行で実行してください。

※ setコマンドおよびadd-pg-setenvコマンドは指定の値で上書きしますので、既存の設定値を含めて設定してください。

設定が完了したらドメインを再起動してください。

2.3.5. log4jの設定

Tomcatでは、Webアプリケーション毎にログ出力方法を制御する場合は、各Webアプリケーションの WEB-INF/classes 以下に log4j.properties または log4j.xml という名前で設定ファイルを配置します。そのほかに、システム全体で設定ファイルを指定する方法もあります。この場合、Tomcat3.x ならばTOMCAT_OPTS 、Tomcat4.x 以降ならばCATALINA_OPTS 環境変数へ指定します。

以下は、Tomcat4.xで、システム全体でlog4jの設定を行っている場合の移行の例です。WEB-INF/classes 配下に log4j の定義ファイルを含めている場合はこの設定は不要です。

【log4.configurationを使用した設定例 (tomcat4.xの例）】

環境変数への設定（unixの場合）

export CATALINA_OPTS="-Dlog4j.configuration=file:///home/foo/log4j.xml"

【運用管理コマンドでの設定(WebOTXの例)】

・スタンダードモードの場合

otxadmin > create-jvm-options "-Dlog4j.configuration=file\:///${com.nec.webotx.instanceRoot}${file.separator}config${file.separator}{log4j 定義ファイル名}.xml"

・アドバンスドモードの場合

otxadmin > add-pg-javasystem-property --apgroup <APG名> --javasystemprop log4j.configuration --value file\:///${com.nec.webotx.instanceRoot}${file.separator}config${file.separator}{log4j 定義ファイル名}.xml

※ <APG名> にはアプリケーショングループ名が入ります。

※ 実際には1行で実行してください。

Webアプリケーションでlog4j APIを呼び出して、利用するlog4j定義ファイルを読み込む方法についての説明は、ここでは省略します。

前述の通り、WebOTX V8.x 以降のバージョンではログ出力に WebOTX 独自のlogging モジュールを利用しています。よって、ユーザアプリケーションでは、WEB-INF/classes 配下に定義ファイルを置くか、システムプロパティに設定するかのどちらかで log4j を利用することが可能です。

2.3.6. WebOTX独自のWebアプリケーション配備記述子（nec-web.xml）

Webアプリケーションには、Servlet仕様にしたがって配備記述子 (Deployment Descriptor) と呼ばれる実行の振る舞いを宣言するXML形式の設定ファイル (web.xml) を含めます。 WebOTX V6以降では、その標準のServlet仕様に規定されたweb.xml要素を拡張した、nec-web.xmlを追加しています。Tomcatの設定項目に対応するnec-web.xmlへの設定の詳細は[ 2.5. Tomcat設定項目 > 2.5.1. Tomcat設定項目との対応 ]を参照してください。

ライブラリのロードの設定を変更したい場合や、BASIC/FORM認証をする際のユーザ名や権限の設定を追加したい場合は、nec-web.xmlに該当する情報を設定しなければなりません。

2.3.6.1. BASIC認証、FORMベース認証を利用する場合の設定

WebOTXでは、BASIC認証かFORMベース認証を利用する場合、次の箇所を設定します。

• 使用するレルムにユーザ名、パスワード、権限を登録します。
• 必要に応じてlogin.conf、domain.xmlファイルに使用するレルムを登録します。
• web.xmlファイルでレルムおよびロールを指定します。
• nec-web.xmlで、web.xmlで指定したロール名に対応するユーザ名(principal)および権限(group)を指定します。

【web.xmlの記述例(抜粋)】

<security-constraint>
   <display-name>Server Configuration Security Constraint</display-name>
      <web-resource-collection>
         <web-resource-name>Protected Area</web-resource-name>
          <!-- Define the context-relative URL(s) to be protected -->
          <url-pattern>*.jsp</url-pattern>
          <url-pattern>*.do</url-pattern>
          <url-pattern>*.html</url-pattern>
          <url-pattern>/WebAPManage/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
        <!-- Anyone with one of the listed roles may access this area -->
          <role-name>stRole</role-name>
      </auth-constraint>
  </security-constraint>

  <!-- Login configuration uses form-based authentication -->
  <login-config>
      <auth-method>FORM</auth-method>
        <realm-name>file</realm-name>
                    
        <form-login-config>
            <form-login-page>/login.jsp</form-login-page>
             <form-error-page>/error.jsp</form-error-page>
        </form-login-config>
    </login-config>

    <!-- Security roles referenced by this web application -->
    <security-role>
        <description>
             The role that is required to log in to the Administration Application
        </description>
       <role-name>stRole</role-name>
    </security-role>

  <context-root>BasicAuthServlet24</context-root>
                
  <security-role-mapping>
    <role-name>stRole</role-name>
               
    <principal-name>admin3</principal-name>
                     
    <group-name>stGroup</group-name>
                　 
  </security-role-mapping>

※ ロール名などをnec-web.xmlに指定する方法は、 [ アプリケーション開発ガイド（Java EE） > 2. Webアプリケーションの開発 > 2.2. プログラミング・開発ガイド > 2.2.13. Webアプリケーションのデプロイ > 2.2.13.4. web.xmlデプロイメント記述子 ] の、[nec-web.xmlファイルの要素] をご覧ください。

2.3.6.2. クラスロード優先順位の設定

nec-web.xmlに"delegate=false"の設定をすることにより、クラスロードの優先順位の変更を行うことができます。
nec-web.xmlファイルの格納場所およびファイルの内容は次のとおりです。

${INSTANCE_ROOT}/applications/Webアプリケーション毎のディレクトリ/WEB-INF

【nec-web.xml】

<?xml version="1.0" encoding="UTF-8"?>
<nec-web-app xmlns="http://java.sun.com/xml/ns/j2ee">
  <context-root>context_name</context-root>
・・・Webアプリケーションのコンテキスト名
  <class-loader delegate="false"/>
・・・委譲モデル（ロード要求を受けた場合、まずは要求を親のクラスローダに委譲）を使用しない場合は、falseを指定
</nec-web-app>

※nec-web.xmlはアプリケーション配備時にアプリケーションディレクトリ内（"<ドメインディレクトリ>/applications/<アプリケーション名>/WEB-INF" 配下）に自動的には生成されません。"<ドメインディレクトリ>/generated/xml/<アプリケーション名>/WEB-INF" 配下に生成されますので、必要に応じてコピーして使用してください。nec-web.xml が含まれない場合、Servlet のバージョンに関わらず delegate のデフォルト値は常に trueになります。

nec-web.xmlを変更した場合は、変更したnec-web.xmlを、WebアプリケーションのWEB-INF配下に再配置します。

WEB-INF下に配置後、次のいずれかの方法で配備を行ってください。

・WARファイルを作成して配備

・ディレクトリ指定で配備

配備については、2.4.4. 配備方法をご覧ください。

2.3.6.3. 利用する場合に設定が必要なパッケージ

Webアプリケーション内に配置したクラスのうちパッケージ名が以下で始まるクラスは参照することができません。この仕様はServlet仕様での勧告（javaxなどのJ2SE、J2EEクラスをWAR内のライブラリでオーバライドさせるべきではない）に基づくものです。詳細はServlet 2.4の9.7.2節を参照してください。
それにより、WEB-INF/lib配下のこれらのファイルを読み込む場合は以下の設定が必要になります。

対象パッケージ名
"javax"
"sun"
"org.xml.sax"
"org.w3c.dom"
"org.apache.taglibs.standard"
"com.sun.faces"

【nec-web.xmlでの設定方法】
<nec-web-app>タグの"property"に"overrideablejavaxpackages"を追加します。複数設定する場合はカンマで区切って指定します。
反映させるにはWebアプリケーションを更新して、更新したアプリケーションを配備し直してください。

※ org と指定した場合、 org.apache.xerces 等の指定したパッケージ配下全てに効果があります。

<?xml version="1.0" encoding="UTF-8"?>
<nec-web-app>
  <context-root>context_name</context-root>
  <class-loader delegate="true">
  　<property name="overrideablejavaxpackages" value="javax"/>
  </class-loader>
</nec-web-app>

※JAXB2.1を利用しているアプリケーションを動作させるためにもこの設定が必要となります。以下の例を参考にnec-web.xmlを追加してください。

<?xml version="1.0" encoding="UTF-8"?>
<nec-web-app>
  <context-root>context_name</context-root>
  <class-loader delegate="false">
  　<property name="overrideablejavaxpackages" value="javax,sun,org"/>
  </class-loader>
</nec-web-app>

※JavaVMシステムプロパティで、"com.nec.webotx.enterprise.overrideablejavaxpackages=パッケージ名"を設定をすることで全Webアプリケーションに対しての設定を行うこともできます。

設定方法の詳細については、[リファレンス集 運用管理・設定編 > Webコンテナ > Webコンテナ設定項目一覧 > JavaVMオプションで設定可能な項目一覧] を参照してください。

2.3.6.4. Java Server Faces(JSF)のアプリケーションを利用するための設定

JSF のアプリケーションを利用する場合、デフォルトでは delegate の値にかかわらず、WebOTX が持っている JSF の実装を利用して動作します。 ユーザのアプリケーションにバンドルされている JSF の実装を利用したい場合、 nec-web.xml に以下の例を参考に useBundledJsf=true の設定を追加してください。

【nec-web.xml】

<?xml version="1.0" encoding="UTF-8"?>
<nec-web-app>
  <context-root>context_name</context-root>
  <class-loader delegate="false"/>
　<property name="useBundledJsf" value="true"/>
</nec-web-app>

useBundledJsf=true を指定した場合、[ 2.3.6.3. 利用する場合に設定が必要なパッケージ ]にあるパッケージのうち "javax.faces", "com.sun.faces" は自動で設定されるため、明示的に設定する必要はありません。

※アプリケーションで特定の <listener> を先に読み込ませる必要がある場合、 先に読み込ませたいリスナの定義を web.xml のリスナ定義の最初に追加してください。
例として、glassfish の JSF 実装のメソッド javax.faces.FactoryFinder.getFactory() メソッドを呼び出す場合、 jsf-core.tld に定義された ConfigureListener を最初にロードする必要があります。 この場合、web.xml に下記例のように設定を行ってください。

【web.xmlの記述例(抜粋)】

<context-param>
   …
</context-param>

<!-- 最初に追加 -->
<listener>
   <listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>

<listener>
   <listener-class>nonjsp.lifecycle.XulServletContextListener</listener-class>
</listener>

<servlet>
   <servlet-name> ...
</servlet>

…

2.3.6.5. no-cache の設定

WebOTX ではセキュリティの制限がかかったアプリケーションへのアクセスの際に no-cache ヘッダを付加します。 V8.x 以降、デフォルトではセキュリティのかかったアプリケーション全体へのアクセスに対して no-cache ヘッダを付加しますが、 V7.x 以前の WebOTX ではセキュリティの範囲内だけに no-cache ヘッダを付加します。 例として、web.xml に以下の記述がある場合、V7.x 以前の WebOTX では *.jsp, *.do, *.html ファイルへのアクセスのみに no-cache ヘッダを付加しますが、V8.x以降 ではこのアプリケーション全体に対して no-cahce ヘッダを付加します。

【web.xmlの記述例(抜粋)】

<security-constraint>
   <display-name>Server Configuration Security Constraint</display-name>
      <web-resource-collection>
         <web-resource-name>Protected Area</web-resource-name>
          <!-- Define the context-relative URL(s) to be protected -->
          <url-pattern>*.jsp</url-pattern>
          <url-pattern>*.do</url-pattern>
          <url-pattern>*.html</url-pattern>
      </web-resource-collection>
      <auth-constraint>
        <!-- Anyone with one of the listed roles may access this area -->
          <role-name>stRole</role-name>
      </auth-constraint>
  </security-constraint>

  <!-- Login configuration uses form-based authentication -->
  <login-config>
      <auth-method>FORM</auth-method>
        <realm-name>file</realm-name>
                    
        <form-login-config>
            <form-login-page>/login.jsp</form-login-page>
             <form-error-page>/error.jsp</form-error-page>
        </form-login-config>
    </login-config>

    <!-- Security roles referenced by this web application -->
    <security-role>
        <description>
             The role that is required to log in to the Administration Application
        </description>
       <role-name>
stRole</role-name>
    </security-role>

V8.x以降 でも V7.x 以前の WebOTX と同様にセキュリティの範囲内のみに no-cache を付加したい場合、 nec-web.xml に下記例を参考に checkURLPatternAfterMatching=false の設定を追加してください。

<?xml version="1.0" encoding="UTF-8"?>
<nec-web-app>
  <context-root>context_name</context-root>
　<property name="checkURLPatternAfterMatching" value="false"/>
</nec-web-app>

この設定により、[ 注意制限事項 > 3. Webコンテナ > 3.1. 注意事項 ]にある [ IEからSSL通信を行う場合、XMLドキュメントの取得に失敗する場合があることについて ]の現象を回避することができることがあります。

2.3.7. セキュリティポリシーの設定

Tomcatは、オプションなしで起動すると、Javaセキュリティ・マネージャを使用しない定義で動作します。セキュリティ・マネージャを使用しない場合、実行時にアクセス制御を行わないため、高速に処理できます。その反面、社会インフラでの利用に求められるサーバ・セキュリティが全く働かない問題があります。

WebOTXでは、デフォルトでセキュリティ・マネージャが動作します。これにより、Webアプリケーションが不用意に資源 (OS上のファイルや他システムへの接続など) にアクセスすることを制限することができます。ただし、意図した資源へのアクセスを許可する場合には、Javaセキュリティポリシーに追加設定する必要があります。

ここでは、Webアプリケーションが必要とする資源へのアクセスを許可させる方法について説明します。

2.3.7.1. セキュリティポリシーの設定方法

Webアプリケーションが、任意のディレクトリ/ファイルにアクセスする場合の設定を例に説明します。

1. ドメインを停止します。

2. Webアプリケーションが、「/Temp」ディレクトリとその配下のファイルの読み込みを行う場合、次のファイルに定義を追加します。

   【${INSTANCE_ROOT }/config/server.policy】

   ・・・
   // Basic set of required permissions granted to all remaining code
   grant {
   
   permission java.io.FilePermission "${/}Temp", "read";
   permission java.io.FilePermission "${/}Temp${/}-", "read";
   ・・・
   }
   ・・・
   

   上記では、「/Temp」ディレクトリへのreadの許可と、「/Temp」ディレクトリ配下のファイルのreadの許可を追加しています。

3. 設定後に、ドメインを起動することで反映されます。

JDKのアクセス権とポリシーの構文については以下のサイトを参照してください。(Java SE 7の説明)

http://docs.oracle.com/javase/7/docs/technotes/guides/security/permissions.html

http://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html

2.3.7.2. セキュリティ例外の調査方法

事前にアクセスするディレクトリ/ファイルなどが分かっている場合には、動作させる前にserver.policyに定義を追加できます。　　しかし、どのようなアクセスがあるか分からない場合には、Webアプリケーションを動作させてみて、セキュリティ例外メッセージから追跡します。

例えば、許可されない資源へのアクセスがあると、${INSTANCE_ROOT}/logs/server.logログファイルに次のような例外メッセージが記録されます。

access denied (java.io.FilePermission /Temp read)

この場合には、先に説明した「/Temp」ディレクトリへのreadを許可するポリシーの追加が必要になります。 さらに、次のようにJava VMのオプションを追加することによって、詳細な情報を確認することができます。 以下はdomain1ドメインにセキュリティ違反の詳細を確認するJava VMオプションを追加するコマンド例です。

otxadmin> create-jvm-options --user admin --password adminadmin --port 6212 --host localhost -Djava.security.debug=access\\:failure:

※ 実際には1行で実行してください。

設定後、ドメインを再起動してください。詳細な情報がlogs/server.logに出力されますので、「denied」と記録されているものを確認し、セキュリティポリシーの追加を行ってください。

2.3.7.3. セキュリティポリシー設定の移行

Tomcatでのセキュリティポリシーの設定はconf/catalina.policyで行います。 WebOTXでのセキュリティポリシーの設定は${INSTANCE_ROOT }/config/server.policyで行います。　現行のシステムでセキュリティポリシーを設定している場合は、この設定内容を移行します。

【conf/catalina.policy抜粋 （Tomcatの例）】

grant { 
    permission java.util.PropertyPermission "java.home", "read";
　　　：省略
};

【${INSTANCE_ROOT }/config/server.policy抜粋　（WebOTXの例）】

grant principal javax.management.remote.JMXPrincipal "admin" {
    :省略
    permission java.io.FilePermission "${java.home}${/}..${/}bin${/}-", "read,execute";
    ：省略
};

2.3.8. Tomcatの差異による対応

Tomcatの各バージョンの差異により、WebOTXへの移行の際に対応が必要となる場合があります。

ここでは、各バージョンの差異とその対応方法について説明します。

また、WebOTX V6、V7のベースとなっているTomcatのバージョンは5.0、V8ではTomcat 6.0、V9ではTomcat7.0がベースとなっています。よって、V8以前からV9へ移行する際にもこれらの設定が必要になります。

2.3.8.1. Tomcat 5.0と Tomcat 5.5の差異

server.web-container.property.forwardRequestURLの値が変更されている

Tomcat 5.0以前からWebOTX V9へ移行する際にこの対応が必要になる場合があります。

Tomcat 5.0とTomcat 5.5の差異として、この値のデフォルト値が “original” → “forward” に変更されています。
WebOTX V6、V7 → V9の変更はTomcat 5.0 → 5.5の変更に合わせているため、対応が必要な場合は設定を行ってください。
設定方法の詳細は 2.5.1. Tomcat設定項目との対応 をご覧ください。

2.3.8.2. Tomcat 5.5と Tomcat 6.0の差異

InvokerServletが機能しない

Tomcat 5.5以前からWebOTX V9に移行する際にこの対応が必要になる場合があります。

これはTomcat 5.5以前で機能していたInvokerServletの機能が、セキュリティ上の観点からTomcat 6.0以降ではデフォルトで動作しないようになっているためです。Tomcat7.0をベースにしているWebOTX V9ではこの問題が発生します。 この機能を使用する場合は下記の設定が必要になります。

【設定手順】

1) Webアプリケーションのweb.xmlのInvokeServletが定義されている事を確認します。

<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>2</load-on-startup>
</servlet>

…

<servlet-mapping>
　<servlet-name>invoker</servlet-name>
　<url-pattern>/servlet/*</url-pattern>
</servlet-mapping>

2) 次の方法で設定を追加します。

• 次のシステムプロパティを指定します（全てのアプリケーションに適用されます）。
  org.apache.catalina.servlets.enableInvokerServlet=true
  
  

3) ドメインを再起動します。

[ 2.6. Q&A > 2.6.1. Webアプリケーションの実行エラーに関するQ&A ]の Q8 も参考にしてください。

JSPの実行時に例外が発生する場合がある

WebOTX V8より該当クラスのパッケージ名が変更されているため、JSPの実行時に例外が発生し、HTTPステータスコード500エラーが返却される場合があります。

org.apache.jasper.tagplugins.jstl.If
↓
org.apache.jasper.tagplugins.jstl.core.If
その他の変更/削除されたパッケージ（クラス）は以下のとおりです。

[変更]
org/apache/commons/beanutils/ -> com/nec/webotx/org/apache/commons/beanutils/
org/apache/commons/collections/ -> com/nec/webotx/org/apache/commons/collections/
org/apache/commons/digester/ -> com/nec/webotx/org/apache/commons/digester/
org/apache/commons/el/ -> org/apache/taglibs/standard/lang/jstl/
org/apache/commons/el/parser/ -> org/apache/el/parser/
org/apache/commons/launcher/ -> com/nec/webotx/org/apache/commons/launcher/
org/apache/commons/logging/ -> com/nec/webotx/org/apache/commons/logging/
org/apache/commons/modeler/ -> com/nec/webotx/org/apache/commons/modeler/
org/apache/jasper/tagplugins/jstl/ -> org/apache/jasper/tagplugins/jstl/core/
org/apache/log4j/ -> com/nec/webotx/org/apache/log4j/

org/apache/jasper/util/FastDateFormat.class -> org/apache/catalina/util/FastDateFormat.class
org/apache/jasper/util/Queue.class -> org/apache/tomcat/util/collections/Queue.class
org/apache/jasper/util/SimplePool.class -> org/apache/tomcat/util/collections/SimplePool.class
org/apache/jasper/util/SystemLogHandler.class -> org/apache/tomcat/util/log/SystemLogHandler.class

[削除]
org/apache/commons/codec/
org/apache/commons/discovery/
org/apache/jasper/xmlparser/XercesEncodingDetector.class
org/apache/regexp/RETestCase.class
org/apache/taglibs/standard/tag/common/xml/JSTLPrefixResolver.class
org/apache/taglibs/standard/tag/common/xml/JSTLXPathAPI.class

2.3.8.3. Tomcat 6.0と Tomcat 7.0の差異

emptySessionPathの設定

Tomcat7では、emptySessionPathの設定が廃止され、sessionCookiePath="/" の設定により同等の動作をします。
WebOTX V9.2では、CookiePath="/"の設定で、指定します。

JSPコンパイル時に暗黙オブジェクトに対してfinal宣言が付く

Tomcat7では、以下の暗黙オブジェクトに対して final 宣言が付く変更が行われています。 そのため、これらの暗黙オブジェクトの値を変更することができません。

暗黙オブジェクト:
  request
  response
  pageContext
  application
  config
  page

 true：final宣言を付けない（WebOTX V8互換）
 false：final宣言を付ける

JSPコンパイルのタグ属性重複エラーチェック

Tomcat7ではjspでカスタムタグをコンパイルする際、タグ属性の重複チェックが追加されました。
WebOTX V9では、タグ属性の重複チェックをON/OFFできるよう機能を強化しています。

【エラーとなるタグ記述の例】

    :
<%@ taglib uri="/WEB-INF/mytag.tld"  prefix="c" %>
    :
<c:mytest numAt="100" strAt="XYZ" strAt="ABC"/>
    :

Tomcat7ではタグ属性(strAt)が複数あるためエラーとなります。Tomcat6まではエラーにならず最後に設定した"ABC"が有効でした。

• 次のシステムプロパティを指定することで、タグ重複のチェックをOFFにできます。
  org.apache.jasper.compiler.Parser.TAGATTRIBUTE_UNIQUECHECK=false
  
  

2.3.9. その他のAPサーバからの移行

ここでは、その他のAPサーバからWebOTX V9へ移行する際に必要となる対応について説明します。

2.3.9.1. その他のAPサーバ独自のAPIについて

その他のAPサーバ独自のAPIを使用している場合、WebOTXで動作させると問題が発生します。
（例えば、JRunが独自に提供するAPIは、パッケージ名に「jrun」というキーワードが入っています。）
アプリケーションが利用するライブラリのパッケージ名にその他のAPサーバ独自のキーワードがあるかどうか、 JSPやServletなどでその他のAPサーバ独自のAPIを使用していないかを確認してください。

2.3.9.2. WEB-INFに配置したファイルを読む方法

JRunでは、WEB-INFに配置したファイルは配置しただけで読み込めますが、その他のAPサーバでは読み込めません。 読み込めるようにするためには、クラスパスの設定などの対処が必要になります。

2.3.9.3. リクエストの読み込みとレスポンスの書き込みについて

Servlet仕様に記載されている通り、WebOTXを含む一般のAPサーバには、次の制限があります。

• リクエストを読む場合、getParameter()とgetInputStream()はどちらか一方しか実行できません
• レスポンスを書き込む場合、getWriter()とgetOutputStream()はどちらか一方しか実行できません (JSPでは、自動的にgetWriter()が利用されます。)

この制限を回避するには、Webアプリケーションの改造が必要になります。

2.3.9.4. 仮想ドキュメントルートの設定

WebLogicの仮想ディレクトリ(※)をWebOTXで実現するには、 nec-web.xmlでalternatedocroot_<N>プロパティ の設定を行う必要があります。

※ Webアプリケーションのデフォルトドキュメントルート以外のドキュメントルートを指定する機能

2.3.10. WebOTX V8とV9の差異

2.3.10.1. Webアプリケーションのリロード

Webアプリケーションのリロードは手動で行います。 2.5.1. Tomcat設定項目との対応 - コンテキスト（共通） - reloadableを参照ください。

2.3.10.2. Webアプリケーションの配備ディレクトリ

Webアプリケーションの配備先は以下のディレクトリに変更になりました。
V8： ${INSTANCE_ROOT}/applications/j2ee-modules/{アプリケーション名}
　　　　　　　　　　　　　　　　　　　　　　　　　　　
V9： ${INSTANCE_ROOT}/applications/{アプリケーション名}

2.3.10.3. HTTPリスナに対する設定（maxParameterCountの例）

V8： otxadmin> set server.http-service.http-listener.ajp-listener-1.property.maxParameterCount=500
　　　　　　　　　
V9： otxadmin> set server.network-config.network-listeners.network-listener.ajp-listener-1.property.maxParameterCount=500

2.3.10.4. virtual-serverで使用するリスナを列挙する属性

V8： server.http-service.virtual-server.＜virtual-server-name＞.http-listeners
　　　　　　　　　
V9： server.http-service.virtual-server.＜virtual-server-name＞.network-listeners

2.3.10.5. 利用するコネクタの指定

V8：JavaVMのシステムプロパティに以下を設定
 -Dcom.nec.webotx.enterprise.web.connector.useCoyoteConnector=(true | false)

V9： otxadmin> set server.network-config.protocols.protocol.＜protocol名＞.type=(ajp | grizzly | nio | bio)

2.3.10.6. 統計情報採取の設定

V8： otxadmin> set server.monitoring-service.module-monitoring-levels.web-container=(ON | OFF)

V9： otxadmin> set server.monitoring-service.module-monitoring-levels.web-container=(HIGH | OFF)

2.3.10.7. セッションオブジェクトの属性の管理オプションの既定値

V8：  既定値: false(低メモリ消費優先)
　　　　　　　　　
V9：  既定値: true(排他処理性能優先)

2.3.10.8. リスナスレッド数

最大リスナスレッド数
V8： server.http-service.http-listener.＜リスナID＞.max-processors
　　　　　　　　　
V9： server.thread-pools.thread-pool.＜スレッドプール名＞.max-thread-pool-size

最小リスナスレッド数
V8： server.http-service.http-listener.＜リスナID＞.min-processors
　　　　　　　　　
V9： server.thread-pools.thread-pool.＜スレッドプール名＞.min-thread-pool-size

スレッド数警告のしきい値
V8： server.http-service.http-listener.＜リスナID＞.limit-processors
　　　　　　　　　
V9： server.thread-pools.thread-pool.＜スレッドプール名＞.limit-thread-pool-size

2.3.10.9. cross-contextの既定値

V8：  既定値: false(クロスコンテキスト不許可)
　　　　　　　　　
V9：  既定値: true(クロスコンテキスト許可)

2.3.10.10. welcome-fileの仮想パス対応

V8： servlet-mappingのurl-patternに"*.do"を設定してwelcome-fileにindex.doを設定している場合、ディレクトリにアクセスしたとき、404エラーを表示する。

V9： servlet-mappingのurl-patternに"*.do"を設定してwelcome-fileにindex.doを設定している場合、ディレクトリにアクセスしたとき、*.doにマッピングされたservletを実行する。

※V9では、strutsやjsfで使用されるindex.doやindex.jsf等の物理的に存在しないパス名を welcome-fileに指定して利用する事が出来るようになりました。
※V8と同様の表示をさせるには、[2.5.1. Tomcat設定項目との対応] - [コンテキスト（共通）] - [resourceOnlyServlets]オプションで、url-patternに対応付いたservlet-nameを指定します。

2.3.10.11. HTTPリクエストヘッダの最大サイズの指定オプション

V8：  server.http-service.http-listener.＜リスナID＞.property.maxHttpHeaderSize
　　　　　　　　　
V9：  server.network-config.protocols.protocol.＜プロトコル名＞.http.header-buffer-length-bytes

2.3.10.12. jsp事前コンパイルの対応taglib定義バージョン

jspプリコンパイルでサポートする web.xmlのtaglib定義仕様はweb-app2.4以降の仕様(<web-app> - <jsp-config> - <taglib>)に変更しました。

※web.xmlの<taglib>の定義位置の仕様
・web-app2.3以前

<web-app> - <taglib>

・web-app2.4以降

<web-app> - <jsp-config> - <taglib>

そのため以下のどちらかの対応が必要です。
(a) 配備時のjspプリコンパイルオプションを外す。

(b) web.xmlのtaglib要素をweb-app2.4以降に準拠して定義する。

(1) web.xmlのバージョンをweb-app2.4に変更します

<?xml version="1.0" encoding="ISO-8859-1"?>

<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2eeweb-app_2_4.xsd" version="2.4">

(2) taglib要素をjsp-config要素内に入れます

<jsp-config>←追加
    …
    <taglib>
        <taglib-uri>/tags/xxx</taglib-uri>
        <taglib-location>/WEB-INF/xxx.tld</taglib-location>
    </taglib>
    …
</jsp-config>←追加

2.3.10.13. コンテナの FORM URL パラメタ構文解析で扱う POST の最大バイト数

V8：  server.http-service.http-listener.<リスナ名>.property.maxPostSize
　　　　　　　　　
V9：  server.network-config.protocols.protocol.<プロトコル名>.http.max-post-size-bytes

2.3.10.14.*.tldファイルが不正な場所に存在する場合のチェックを強化

/WEB-INF/tags 配下にimplicit.tld 以外の*.tldファイルを配置した場合は、アプリケーションのロード時にエラーとなるようWebOTX V9から実装仕様を変更しました。
これはJSP2.1仕様で変更された「JSP.7.3.1 Identifying Tag Library Descriptors Tag」の仕様によるものです。
回避するにはアプリケーション側で、/WEB-INF/tags 配下にある implicit.tld 以外の*.tldファイルを、 /WEB-INF/tags以外の /WEB-INF 配下(/WEB-INF/classes, /WEB-INF/libは推奨しません)に移動するか 以下の設定を行ってください。

JVMシステムプロパティ
-Dcom.nec.webotx.webcontainer.jsp.TldInTags=true

2.3.11. Cometの移行

TomcatやGrizzlyのCometを使用している場合は、今後のAPIの互換性が保障されるServlet 3.0を使用したCometに移行してください。
移行の方法を以下に説明します。

2.3.11.1. Tomcat CometからServlet API3.0 Cometへの移行

BlockingQueue<String> messageQueue = new LinkedBlockingQueue<String>();

public void init(ServletConfig config) throws ServletException {
    super.init(config);
    Runnable notifierRunnable = new Runnable() {
        public void run() {
            try{
                while(true){ 
                    String cMessage = messageQueue.take();
                    for (AsyncContext ac : queue) {
                        try {
                            PrintWriter acWriter = ac.getResponse().getWriter();
                            acWriter.println(cMessage);
                            acWriter.flush();
                        } catch(IOException ex) {
                            queue.remove(ac);
                        }
                    }
                }
            }catch(InterruptedException e){
                log("messageQueue take error", e);
            }
        }
    };
    notifierThread = new Thread(notifierRunnable);
    notifierThread.start();
}

AsyncContext ac = request.startAsync();
this.queue.add(ac);

public void event(CometEvent event) throws IOException, ServletException {
    …
    if (event.getEventType() == CometEvent.EventType.BEGIN) {
    	event.setTimeout(30 * 60 * 1000); // 30分

AsyncContext ac = request.startAsync();
ac.setTimeout(30 * 60 * 1000); // 30分

public void event(CometEvent event) throws IOException, ServletException {
  …
    } else if (event.getEventType() == CometEvent.EventType.ERROR) {
        synchronized (queue) {
            queue.remove(response);
        }
        event.close();
    } else if (event.getEventType() == CometEvent.EventType.END) {
        synchronized (queue) {
            queue.remove(response);
        }
        event.close();
    }

AsyncContext ac = request.startAsync();
ac.addListener(new AsyncListenerImpl());

class AsyncListenerImpl extends Thread implements AsyncListener{
  …
    @Override
    public void onError(AsyncEvent ae) throws IOException {
        synchronized (queue) {
            queue.remove(ae.getAsyncContext());
        }
    }

    @Override
    public void onTimeout(AsyncEvent ae) throws IOException {
        synchronized (queue) {
            queue.remove(ae.getAsyncContext());
        }
    }
}

Runnable notifierRunnable = new Runnable() {
public void run() { 
  ... 
  while(true){ 
    cMessage = messageQueue.take(); 
    for (HttpServletResponse res : queue) { 
        try { 
            PrintWriter acWriter = res.getWriter(); 
            acWriter.println(cMessage); 
            acWriter.flush(); 
        } catch(IOException ex) { 
            queue.remove(ac); 
      ... 
    }
  }
}; 
notifierThread = new Thread(notifierRunnable); 
notifierThread.start();

Runnable notifierRunnable = new Runnable() { 
public void run() { 
  ... 
  while(true){ 
    cMessage = messageQueue.take(); 
    for (AsyncContext ac : queue) { 
        try { 
            PrintWriter acWriter = ac.getResponse().getWriter(); 
            acWriter.println(cMessage); 
            acWriter.flush(); 
        } catch(IOException ex) { 
            queue.remove(ac); 
    ...
    }
  }
}; 
notifierThread = new Thread(notifierRunnable); 
notifierThread.start();

if (event.getEventType() == CometEvent.EventType.BEGIN) {
　　　　…
}

if (event.getEventType() == CometEvent.EventType.READ) {
　　　　…
}

if (event.getEventType() == CometEvent.EventType.ERROR) {
　　　　…
}

class AsyncListenerImpl extends Thread implements AsyncListener{
    …
    public void onError(AsyncEvent event) throws IOException {
        …
    }
}

if (event.getEventSubType() == CometEvent.EventSubType.TIMEOUT) {
　　　　…
}

class AsyncListenerImpl extends Thread implements AsyncListener{
    …
    public void onTimeout(AsyncEvent event) throws IOException {
        …
    }
}

final AsyncContext ac = req.startAsync();
ac.setTimeout(10 * 60 * 1000); 
ac.addListener(new AsyncListener() { 
    ... 
}; 
queue.add(ac);

queue.clear();
notifierThread.interrupt();

2.3.11.2. Grizzly CometからServlet API3.0 Cometへの移行

public class XXXServlet extends HttpServlet

public class XXXServlet extends HttpServlet

CometContext cometContext = CometEngine.getEngine().getCometContext(this.contextPath);
cometContext.notify("[" + user + "]: " + message);

BlockingQueue<String> messageQueue = new LinkedBlockingQueue<String>();

public void init(ServletConfig config) throws ServletException {
    super.init(config);
    Runnable notifierRunnable = new Runnable() {
        public void run() {
            try{
                while(true){ 
                    String cMessage = messageQueue.take();
                    for (AsyncContext ac : queue) {
                        try {
                            PrintWriter acWriter = ac.getResponse().getWriter();
                            acWriter.println(cMessage);
                            acWriter.flush();
                        } catch(IOException ex) {
                            queue.remove(ac);
                        }
                    }
                }
            }catch(InterruptedException e){
                log("messageQueue take error", e);
            }
        }
    };
    notifierThread = new Thread(notifierRunnable);
    notifierThread.start();
}

CometHandlerImpl handler = new CometHandlerImpl();
handler.attach(response);
CometContext cometContext = CometEngine.getEngine().getCometContext(this.contextPath);
cometContext.addCometHandler(handler);

public class CometHandlerImpl implements CometHandler<HttpServletResponse>{
  private  HttpServletResponse response;

  …

  public void attach(HttpServletResponse response){
    this.response = response;
  }
  …
}

Queue<AsyncContext> queue = new ConcurrentLinkedQueue<AsyncContext>();

…

AsyncContext ac = request.startAsync();
this.queue.add(ac);

CometContext cometContext = CometEngine.getEngine().register(contextPath);
cometContext.setExpirationDelay(30 * 60 * 1000);

AsyncContext ac = request.startAsync();
ac.setTimeout(30 * 60 * 1000);

AsyncContext ac = request.startAsync();
ac.addListener(new AsyncListenerImpl());

class AsyncListenerImpl extends Thread implements AsyncListener{
  …
  @Override
  public void onError(AsyncEvent event) 
  throws IOException {
    queue.remove(event.getAsyncContext());
  }

  @Override
  public void onTimeout(AsyncEvent event) 
  throws IOException {
    queue.remove(event.getAsyncContext());
  }
}

contextPath = config.getServletContext().getContextPath() + "/chat"; 
CometContext context = CometEngine.getEngine().register(contextPath);
context.setExpirationDelay(5 * 60 * 1000);

Runnable notifierRunnable = new Runnable() {
  public void run() {
    try{
      while(true){
        String cMessage = messageQueue.take();
        for (AsyncContext ac : queue) {
          try {
            PrintWriter acWriter = ac.getResponse().getWriter();
            acWriter.println(cMessage);
            acWriter.flush();
          } catch(IOException ex) {
            queue.remove(ac);
          }
        }
      }
    }catch(InterruptedException e){
      log("messageQueue take error", e);
    }
  }
};
notifierThread = new Thread(notifierRunnable);
notifierThread.start();

public class CometHandlerImpl implements CometHandler<HttpServletResponse>{
    ･･･

    public void onEvent(CometEvent event) 
    throws IOException{
        ･･･
    }
}

public class CometHandlerImpl implements CometHandler<HttpServletResponse>{
    ･･･

    public void onEvent(CometEvent event) 
    throws IOException{
        if ( event.getType() == CometEvent.NOTIFY ){
            String text = (String)event.attachment();
            PrintWriter writer = this.response.getWriter();
            writer.println(text);
            writer.flush();
        }

    }
}

public class CometHandlerImpl implements CometHandler<HttpServletResponse>{
    ･･･
    
    public void onInitialize(CometEvent event) 
    throws IOException{
        this.response.setContentType("text/plain;charset=UTF-8");
        this.response.setCharacterEncoding("utf-8");

        PrintWriter writer = this.response.getWriter();
        writer.println("Welcome");
        writer.flush();
    }
}

public class CometHandlerImpl implements CometHandler<HttpServletResponse>{
    ･･･

    public void onTerminate(CometEvent event) 
    throws IOException{
        this.response.getWriter().close();
        CometContext context = 
            CometEngine.getEngine().getCometContext(contextPath);
        context.removeCometHandler(this);
    }
}

public class CometHandlerImpl implements CometHandler<HttpServletResponse>{
    ･･･

    public void onInterrupt(CometEvent event) 
    throws IOException{
        this.response.getWriter().close();
        CometContext context = 
            CometEngine.getEngine().getCometContext(contextPath);
        context.removeCometHandler(this);
    }
}

class AsyncListenerImpl extends Thread implements AsyncListener{
    ･･･

    public void onError(AsyncEvent event) throws IOException {
        queue.remove(event.getAsyncContext());
    }

    public void onTimeout(AsyncEvent event) throws IOException {
        queue.remove(event.getAsyncContext());
    }
}

ChatListnerHandler handler = new ChatListnerHandler(); 
handler.attach(response); 
CometContext cometContext = CometEngine.getEngine().getCometContext(contextPath);
cometContext.addCometHandler(handler)

CometContext cometContext = CometEngine.getEngine().getCometContext(this.contextPath);
cometContext.notify(message);

final AsyncContext ac = req.startAsync();
AsyncListenerImpl listener = new AsyncListenerImpl();
ac.addListener(listener);
queue.add(ac);

this.messageQueue.add(message);

queue.clear();
notifierThread.interrupt();

2.4. 運用管理方法

Tomcatでの運用管理では、WebブラウザからAdministration ToolやManagerアプリケーションを利用し、設定の変更はserver.xmlを直接編集するのが一般的です。

WebOTXでは、JMX（Java Management Extensions）による運用管理機能を提供しています。これにより、Tomcatのserver.xmlに相当する設定項目をコマンドやGUIにより容易に運用管理できるようになっています。運用管理において、TomcatとWebOTXは次の違いがあります。

2.4.1. Webサーバとの連携

WebOTXでは、各Webサーバとの連携に必要なプラグイン（mod_jk）と、連携のための設定作業を支援する環境設定ツールも提供しています。

Webサーバとの連携を設定する場合には、環境設定ツールを利用して行います。複数のドメインが存在する場合、この設定はドメイン毎に行います。

【環境設定ツール】　Windows版

　　「スタート」-「プログラム」-「WebOTX」の「環境設定ツール」を起動します。

【環境設定ツール】(シェル)　UNIX版　

　　ログイン名 root でログインします。

login: root

WebOTXのインストールディレクトリ/binディレクトリへ移動します。

root> cd /opt/WebOTX/bin

./setconf.sh と入力し環境設定ツールを起動します。

root> ./setconf.sh

上記の環境設定を行った後に、次のように運用管理コマンド（otxadmin）で設定します。

otxadmin> set --user admin --password adminadmin --port 6212 --host localhost server.server.http-listeners=”ajp-listener-1”

環境設定ツール、運用管理コマンドでの設定手順の詳細については、 WebOTXマニュアル [ セットアップガイド ] をご覧ください。

2.4.2. 運用管理コマンド

WebOTXでは、運用のための様々なコマンドを用意しています。

domainの起動/停止、構成情報の参照や変更、アプリケーションの配備/配備解除などが運用管理コマンドで可能です。 詳細は [ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.2. 運用管理コマンド(otxadmin) ] をご覧ください。

2.4.3. 運用管理コンソール

Webブラウザから利用できるWeb版統合運用管理コンソールを用意しています。 詳細は WebOTXマニュアル [ 運用ツールガイド > 1. Web版統合運用管理コンソール ] 、もしくはWeb版統合運用管理コンソールのヘルプをご覧ください。

Web版統合運用管理コンソールを利用するには、クライアントにWebブラウザとして Internet Explorer 7/8/9/10, Firefox 24, Chrome30 のいずれかが必要です。

図2.4.3-1

2.4.4. 配備方法

WARファイルを配備するには、運用管理コマンドを利用する方法と運用管理コンソールを利用する方法、autodeployディレクトリにコピーする方法があります。

本節では、運用管理コマンドで配備する方法について、説明します。

WebOTXにWebアプリケーションを配備するには、WARファイルで配備する方法と、WebOTXが動作するサーバ上のWebアプリケーションのディレクトリを指定して配備する方法があります

2.4.4.1. WARファイルでの配備

WebOTXにWebアプリケーションを配備するには、WARファイルで配備する方法と、WebOTXが動作するサーバ上のWebアプリケーションのディレクトリを指定して配備する方法があります。ここでは、WARファイルで配備する場合について説明します。

WARファイルの作成

Webアプリケーションのディレクトリを”D:/temp/sampleAP”とします。JDKのインストールディレクトリは” C:/jdk1.7.0”とします。 Windowsでは、次のようにコマンドを実行してsampleAP.warファイルを作成します。

cd D:/temp/sampleAP
C:/jdk1.7.0/bin/jar -cfv sampleAP.war *

※WARファイルの構成については以下のマニュアルを参照ください。
[ アプリケーション開発ガイド（Java EE） > 2. Webアプリケーションの開発 ]

運用管理コマンドでの配備

運用管理コマンドでWARファイルを配備するには次のようにコマンドを実行します。 自ホストでデフォルト作成したdomain1にsampleAP.warを配備する場合の例です。

otxadmin> deploy --user admin --password adminadmin --host localhost --port 6212  sampleAP.war

※ 実際には１行で実行してください。

※ 各引数の詳細は、WebOTXマニュアル [ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.2. 運用管理コマンド(otxadmin) ] をご覧ください。

2.4.4.2. ディレクトリ指定での配備

運用管理コマンドでディレクトリ指定によってWebアプリケーションを配備するには次のようにコマンドを実行します。 自ホストでデフォルト作成したdomain1に/home/temp/sampleAPディレクトリ配下に作成したアプリケーションを配備する場合の例です。

otxadmin> deploydir     --user admin --password adminadmin --host localhost --port 6212 /home/temp/sampleAP

※ 実際には１行で実行してください。

※ 各引数の詳細は、WebOTXマニュアル [ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.2. 運用管理コマンド(otxadmin) ] をご覧ください。

2.5. Tomcat設定項目

本章では、WebOTXに設定することのできる項目について説明しています。

2.5.1. Tomcat設定項目との対応

Tomcat 7.xの設定項目をWebOTX V9に設定する方法をまとめました。設定を反映させる方法は以下のようになります。

・ domain.xmlへの設定を運用管理コンソールにより設定する場合（推奨）
運用管理コンソールにて設定を行った後、ドメインを再起動してください。

・ domain.xmlへの設定をコマンドにより設定する場合
ドメインを起動した状態で、運用管理コマンドにて設定コマンドを入力した後、ドメインを再起動してください。

・ domain.xmlを直接編集する場合
ドメイン停止後、記述箇所に設定内容を記述し、ドメインを起動してください。

・ nec-web.xmlを編集する場合
Webアプリケーションを更新して、更新したアプリケーションを配備し直してください。

また、domain.xmlとnec-web.xmlの両方に設定箇所がある項目については、同時に設定した場合nec-web.xmlへの設定が優先されます。

コネクタ（HTTP、AJP共通）

コネクタ（HTTP）

コンテキスト（共通）

コンテキスト（Standard）

Realm
JDBCレルムについてはWebOTX マニュアルの [ ドメイン構築・基本設定ガイド > 4. ユーザ管理 > 4.2. レルムの設定 > 4.2.3. JDBCレルム ]を参照してください。

Loader

2.5.2. JavaVMオプションのサポート

JavaVMオプションでの設定項目は[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ > 1.4.2. Webコンテナ設定項目一覧 > 1.4.2.3. JavaVMオプションで設定可能な項目一覧 ]を参照してください。

2.6. Q&A

Tomcatからの移行時によく起きる問題やTomcatからの移行以外にもよくある質問に対するQ&Aをまとめました。

2.6.1. Webアプリケーションの実行エラーに関するQ&A

Q1　Webアプリケーションを実行するとClassCastExceptionが発生するのですが、どのような原因が考えられますか？

A1　対象となるクラスのロードが正しく行われていない可能性があります。nec-web.xmlの設定を変更して、クラスのロード処理を変えて、アプリケーションの動作を確認してください。以下の例を参考に"delegate=false"を設定したnec-web.xmlを追加してください。
【nec-web.xml】

<?xml version="1.0" encoding="UTF-8"?>
<nec-web-app xmlns="http://java.sun.com/xml/ns/j2ee">
  <context-root>context_name</context-root>
  <class-loader delegate="false"/>
</nec-web-app>

nec-web.xmlの詳細は[ 2.3. 移行作業 > 2.3.6.2. クラスロード優先順位の設定 ]を参照してください。

Q2　Webアプリケーションを実行するとセキュリティ例外が発生するのですが、どのような原因が考えられますか？

A2　セキュリティポリシーの追加が必要です。本資料の[ 2.3. 移行作業 > 2.3.7. セキュリティポリシーの設定 ]をご覧ください。

Q3　Webアプリケーションからのログが出力されないのですが、どのような原因が考えられますか？

A3　log4jの設定を変更してください。本資料の[ 2.3. 移行作業 > 2.3.5. log4jの設定 ]をご覧ください。

Q4　フィルタがうまく動作しないのですが、どのような原因が考えられますか？

A4　フィルタはServlet2.3仕様から追加された仕組みです。WebOTX V9 ではServlet3.0に準拠しているため、web.xml 先頭の version を 2.3、2.4または2.5 に変更してください。変更後のイメージは次のようになります。

<?xml version="1.0" encoding="Shift_JIS"?>
　<web-app xmlns="http://java.sun.com/xml/ns/j2ee" version="2.4" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

Q5　getParameterで取得したデータが文字化けするのですが、どのような原因が考えられますか？

A5　Tomcat 7.xでは、URIのエンコードの指定のために、server.xmlでURIEncoding と useBodyEncodingForURI が指定できますが、WebOTX では、server.network-config.protocols.protocol.http-listener.http.uri-encoding と server.network-config.protocols.protocol.http-listener.http.use-body-encoding-for-uri で指定します。
それぞれ、運用管理コマンド（otxadminコマンド）を利用して、次のように指定します。

otxadmin> set server.network-config.protocols.protocol.http-listener.http.uri-encoding=Windows-31J

otxadmin> set server.network-config.protocols.protocol.http-listener.http.use-body-encoding-for-uri=true

Q6　WebブラウザでJSPの出力を参照したとき、機種依存文字（�鰍ﾈど）が文字化けするのですが、どのような原因が考えられますか？

A6　Web アプリケーションの表示で文字化けが発生する場合、次のステップで原因の調査と対処をしてくださ い。

1. Servlet で、Content-Type による charset を正しく指定（出力）しているか確認します。
   Web ブラウザが表示する文字コードを判断するのに Content-Type を使用します。 Servlet が出力する文字のコードを Content-Type による charset で正しく指定する必要があります。 機種依存文字などを出力する際には、charset に”Windows-31J”を指定します。
2. JSP で、page ディレクティブで、contentType を正しく指定しているか確認します。
   Servlet と同様に、出力する文字コードを contentType で指定します。 Servlet と同様、機種依存文字などを出力する際には、charset に“Windows-31J”を指定します。
3. JSP で、page ディレクティブで pageEncoding を正しく指定しているかを確認します。
   pageEncoding は、JSP 自体がどのコードで記述されているかを示します。 個々のJSP では pageEncoding を指定せずに、まとめて指定することもできます。 web.xml で次のように<page-encoding> を指定します。

   【web.xml】
   <web-app  ....
     <jsp-config>
       <jsp-property-group>
         ....
         <page-encoding>Windows-31J</page-encoding>
       </jsp-property-group>
     </jsp-config>
     ....
     <servlet>
     ....
     </servlet>
   </web-app>
   

また、WebOTX V8からは文字コードを強制的に指定することができるようになりました。以下に、Servlet/JSPへの入出力、エンコーディングを強制設定する機能について説明します。

1. HTTPリクエスト

   エンコーディングを指定してリクエストのデータをどの文字コードとしてJavaで扱うUnicodeにデコードするか、 の設定があります。
   詳細は 01. HTTPリクエスト を参照してください。
   

2. HTTPレスポンス

   レスポンス出力時、Javaで扱うUnicodeをどのエンコーディングを指定して、意図する文字コードにエンコード(レスポンス出力)するか の設定があります。
   詳細は 02. HTTPレスポンス を参照してください。
   

3. jspファイルのコンパイル

   jspファイルがどの文字コードで記述されているか(どのエンコーディングを指定してJavaで扱うUnicodeにデコードするか) の設定があります。
   詳細は 03. jspファイルのコンパイル を参照してください。
   

4. jspファイルのレスポンス

   JSPを実行した際、Javaで扱うUnicodeをどのエンコーディングを指定して、意図する文字コードにエンコード(レスポンス出力)するか の設定があります。
   詳細は 04. jspファイルのレスポンス を参照してください。
   

5. ファイル入力/出力

   ファイルにアクセスするInputStream、OutputStreamを作成する際ユーザが文字コードを指定します。WebOTX独自の設定機能は存在しませんがJava VMオプション(-Dfile.encoding=<MS932等>)指定によりデフォルトキャラセットを変更可能
   

6. データベースアクセス

   JDBCドライバに依存します。
   

※各設定で指定した文字コードはJavaのコンバータにより処理されます。

01. HTTPリクエスト

リクエストのデータをどの文字コードとして扱うかは通常、以下の処理順で決定されます。(ここで決定された文字コードはリクエストからデータを取得する際のInputStreamに適用されます。)

1. Filter等でリクエストデータを参照する前に、ServletRequest.setCharcterEncoding()によりエンコーディングを設定した場合、そのエンコーディングでリクエストデータをデコードします。
   
   
2. HTTPリクエストのヘッダ情報にcharset指定がある場合、そのエンコーディングでリクエストデータをデコードします。
   "Content-Type: application/x-www-form-urlencoded; charset=windows-31j" 等
   
   
3. HTTPリクエストのヘッダ情報にcharset指定が無い場合、nec-web.xmlファイルに<locale-charset-info>要素を設定し、warファイルに予めアーカイブすることでリクエストデータのデコードに用いるデフォルトのエンコーディングを指定することができます。
   ※nec-web.xmlの例
   

   <locale-charset-info default-locale="ja">
   　<locale-charset-map locale="ja" charset="windows-31j" />
   　<parameter-encoding form-hint-field="penc" />
   </locale-charset-info>
   

   
   

   3-1)	リクエストのパラメータ中に該当データ(この場合パラメータ名が（pencのデータpenc=x-IBM943C 等)があればそれをエンコーディングとして使用します。
   3-2)	3-1)が無い場合、リクエスト中のAccept-Language: ja、無ければnec-web.xmlの<locale-charset-info default-locale="ja">を取得します。<locale-charset-map>よりlocaleが一致するmapを検索し、そのcharsetでリクエストパラメータをUnicodeに変換します。

   
   
4. 上記のいずれも無い場合、リクエストデータはデフォルトのエンコーディング"ISO-8859-1"でデコードされます。
   

02. HTTPレスポンス

レスポンスにデータをどの文字コードとして出力するかは通常、以下の処理順で決定されます。(ここで決定された文字コードはHTTPレスポンスのヘッダ情報(Content-Typeのcharset)とデータを出力する際のOutputStreamに適用されます)

1. Servlet2.4の仕様でロケールおよび文字エンコードのマッピングをweb.xmlに指定できます。javax.servlet.ServletResponseのsetLocale()メソッドが呼ばれた時に参照され、指定したロケールに対応する文字コードが設定されます。
   ※web.xmlへの設定例
   

   <locale-encoding-mapping-list>
   　<locale-encoding-mapping>
   　　<locale>ja</locale>
   　　<encoding>windows-31j</encoding>
   　</locale-encoding-mapping>
   　<locale-encoding-mapping>
   　　<locale>ko_KR</locale>
   　　<encoding>EUC-KR</encoding>
   　</locale-encoding-mapping>
   </locale-encoding-mapping-list>
   

   
   
2. ServletResponse.setContentType()にてcharsetが指定された場合、そのエンコーディングでエンコード(レスポンス出力)します。
   
   
3. 上記の指定が無い場合、デフォルトのエンコーディング"ISO-8859-1"でエンコード(レスポンス出力)します。
   

03. jspファイルのコンパイル

jspファイルがどの文字コードで記述されているか(読み込み時どのエンコーディングでデコードするか)は通常、以下の処理で決定されます。(ここで決定されたエンコーディングはjspファイルを読み込む際のInputStremに適用されます)

1. jspにpageEncoding指定が記述されている場合、そのエンコーディングでjspファイルをデコード(読み込み)します。
   
   
2. jspにpageEncoding指定が無くcontentType指定(charset指定)が記述されている場合、そのエンコーディングでjspファイルをデコード(読み込み)します。
   
   
3. JSP2.0の仕様でjspのエンコーディングをweb.xmlに指定できます。contentType指定(charset指定)が無い場合、web.xmlで指定したエンコーディングが適用されます。
   ※web.xmlへの設定例
   

   <jsp-config>
   　<jsp-property-group>
   　　<uri-pattern>/jsp/*</uri-pattern>
   　　<page-encoding>Shift_JIS</page-encoding>
   　</jsp-property-group>
   </jsp-config>
   

   
   
4. pageEncoding指定、contentType指定が共に無い、web.xmlの指定も無い場合、otxadminコマンドにてデフォルトのエンコーディングを指定することができます。(要ドメイン再起動)
   

   otxadmin> set server.web-container.property.default-encoding=Shift_JIS
   

5. 上記のいずれの指定も無い場合、jspファイルはデフォルトのエンコーディング"ISO-8859-1"でデコード(読み込み)されます。
   ※default-web.xmlのjavaEncodingはjsp->servletで変換したservletのjavaファイルをエンコード(出力)する際のエンコーディング指定します。
   
   

※実際のファイルの文字コードが、複数あり、個別のページでエンコーディングを指定している場合、priorityJspInEncodingを指定して特定の文字コードでエンコードするように設定すると、一部のページで文字化けが発生します。この場合は、該当のページのファイルの文字コード修正してください。

04. jspファイルのレスポンス

出力するレスポンスデータはどのエンコーディングエンコード(出力)するかは通常、以下の処理で決定されます。(ここで決定されたエンコーディングはレスポンスのヘッダ情報(Content-Typeのcharset)と出力する際OutputStreamに適用されます)

1. jspにcontentType指定(charset指定)が記述されている場合、そのエンコーディングでレスポンスデータをエンコード(出力)します。
   
   
2. JSP2.0の仕様でjspのエンコーディングをweb.xmlに指定できます。contentType指定(charset指定)が無い場合、web.xmlで指定したエンコーディングが適用されます。
   
   ※web.xmlへの設定例
   

   <jsp-config>
   　<jsp-property-group>
   　　<uri-pattern>/jsp/*</uri-pattern>
   　　<page-encoding>Shift_JIS</page-encoding>
   　</jsp-property-group>
   </jsp-config>
   

   
   
3. contentType指定、web.xmlの指定共に無い場合、otxadminコマンドにてデフォルトのエンコーディングを指定することができます。(要ドメイン再起動)
   
   

   otxadmin> set server.web-container.property.default-encoding=Shift_JIS
   

4. 上記のいずれの指定も無い場合、jspのレスポンスはデフォルトのエンコーディング"ISO-8859-1"でエンコード出力されます。
   
   ※1 この機能の指定方法は２パターンあります、全Webアプリケーション共通の指定と、Webアプリケーション毎に指定するものです。それぞれdomain.xmlのweb-container要素のpropertyとwarファイルにアーカイブするnec-web.xmlに定義されます。
   
   全アプリケーション共通の設定、Webアプリケーション毎の設定の両方が指定された場合、Webアプリケーション毎の設定が優先されます。nec-web.xmlに指定する場合は、エンコーディングを１つ設定する指定か、localeとエンコーディングをマッピングさせてエンコーディングを決定する指定の２パターンを可能とします。両方が指定された場合、localeとエンコーディングのマッピング指定が優先されます。以下、各設定例を記述します。
   
   =====設定例=====
   
   1. レスポンスエンコーディングの優先設定
      
      • Webアプリケーション毎に有効なLocaleに対応したエンコーディング指定のnec-web.xmlへの記述(a1)
        例）<nec-web-app>
        　　　<property name="priorityResponseEncoding-map:ja" value="EUC_JP" />
        　　</nec-web-app>
        
        ※ "priorityResponseEncoding"に"-map"を付加し、":"で区切ってLocaleを記述します LocaleはHttpResponseのgetLocale()で取得できる文字列と同じである必要があります。
        
        
      • Webアプリケーション毎に有効なnec-web.xmlへの記述 (a2)
        例）<nec-web-app>
        　　　<property name="priorityResponseEncoding" value="EUC_JP" />
        　　</nec-web-app>
        
        
      • 全Webアプリケーションに有効なdomain.xmlへの指定 (b)
        例）　otxadmin> set server.web-container.property.priority-response-encoding=EUC_JP
        ※要ドメイン再起動
        
        
   2. JSPファイル読み込みエンコーディングの優先指定
      
      • Webアプリケーション毎に有効なnec-web.xmlへの記述(c)
        例）<nec-web-app>
        　　　<jsp-config />
        　　　　<property name="priorityJspInEncoding" value="EUC_JP" />
        　　　</jsp-config>
        　　</nec-web-app>
        
        
      • 全Webアプリケーションに有効なdomain.xmlへの指定(d)
        例）　otxadmin> set server.web-container.property.priority-jsp-in-encoding=EUC_JP
        ※要ドメイン再起動
        
   3. JSPファイル出力時エンコーディングの優先指定
      JSP出力時とはコンパイルしたjavaソースでHttpServletResponseにsetContentType()する際に指定する"charset=XXX"部分に相当します。
      
      • Webアプリケーション毎に有効なLocaleに対応したエンコーディング指定のnec-web.xmlへの記述(e1)
        例）<nec-web-app>
        　　　<jsp-config />
        　　　　<property name="priorityJspOutEncoding-map:ja" value="EUC_JP" />
        　　　</jsp-config>
        　　</nec-web-app>
        
        ※ "priorityJspOutEncoding"に"-map"を付加し、":"で区切ってLocaleを記述します。
        LocaleはHttpResponseのgetLocale()で取得できる文字列と同じである必要があります。
        
        
      • Webアプリケーション毎に有効なnec-web.xmlへの記述 (e2)
        例）<nec-web-app>
        　　　<jsp-config />
        　　　　<property name="priorityJspOutEncoding" value="EUC_JP" />
        　　　</jsp-config>
        　　</nec-web-app>
        
        
      • 全Webアプリケーションに有効なdomain.xmlへの指定 (f)
        例）　otxadmin> set server.web-container.property.priority-jsp-out-encoding=EUC_JP
        ※要ドメイン再起動
        

Q7　Tomcatからの移行時にJSPのコンパイルエラーになるのですが、原因は何が考えられるでしょうか？

A7　Java 1.4 で記述されたJSPをJava 1.6のソースとしてコンパイルした際に、コンパイルエラーが発生します。WebOTX V9はデフォルトでは、Java 6 (Java1.6)としてコンパイルするため、この問題が発生します。次の例のように、コンパイルする際に使用するJavaの バージョンを指定してください。<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>の定義に compilerTargetVM と compilerSourceVM のパラメータで 1.4 を指定する定義を追加し、ドメインを再起動してください。

<servlet>
　<servlet-name>jsp</servlet-name>
　<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
　<init-param>
　　<param-name>compilerTargetVM</param-name>
　　<param-value>1.4</param-value>
　</init-param>
　<init-param>
　　<param-name>compilerSourceVM</param-name>
　　<param-value>1.4<param-value>
　</init-param>
</servlet>

Q8　Servletを実行する際にURLを"/<コンテキスト名>/servlet/サーブレットのクラス名"というように実行するとHTTP404エラーとなるのですが、設定により直接Servletを実行する方法はありますか？

A8　Tomcat4.1.12以降をベースとする WebOTX V6,V7,V8,V9 では、servlet-mapping の定義が無いサーブレットへのアクセスはセキュリティの観点からデフォルトでは無効になっています。また、WebOTX V8からは、この機能がデフォルトで定義されていません。

WebOTX V6, V7, V8, V9 で上記のアクセスを許可するにはアプリケーションのweb.xmlに以下の定義を追加してください。 対象ファイル：web.xml もしくは <WebOTXインストールディレクトリ>/domains/domain1/config/default-web.xml

<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>2</load-on-startup>
</servlet>


<servlet-mapping>
　<servlet-name>invoker</servlet-name>
　<url-pattern>/servlet/*</url-pattern>
</servlet-mapping>

[ 2.3. 移行作業 > 2.3.8.2. Tomcat 5.5と Tomcat 6.0の差異 ] も参考にしてください。

Q9　ServletのJavaプログラムから、ネットワークドライブにあるファイルを開きたいのですが、どのようにしたらよろしいでしょうか？

A9　ネットワークドライブは以下の条件で利用可能となります。
WebOTXがサービス起動の場合は、サービスのログオンユーザの設定と、共有フォルダへのログオンユーザのアクセス権が必要です。また、APでの共有フォルダの指定は、UNC表記（\\hostname\共有フォルダ名）で指定してください。
※ D:\xxxxx\xxxx の表記では、アクセスできません。

Q10　シンボリックリンクを使用したいのですが、どのようにしたらよろしいでしょうか？

A10　例） WebAPP1というWebアプリケーション内からリンクする例です

• Webモジュールのディレクトリ
  　/opt/WebOTX/domains/domain1/applications/WebAPP1
  
• リンク先の対象のファイル
  　/home/hoge/test.html
  
  1. シンボリックリンクを有効にします。
     　運用管理コマンドで以下のコマンドを入力します。
     

     ./otxadmin set --user admin --password adminadmin server.http-service.virtual-server.server.property.allowLinking=true
     ./otxadmin set --user admin --password adminadmin server.http-service.virtual-server.server.property.caseSensitive=false
     

  2. ドメインを再起動します。
     
  3. 次のコマンドでハードリンクします。
     　cd /opt/WebOTX/domains/domain1/applications/WebAPP1
     　ln /home/hoge/test.html t1.html
     
  4. 確認します。
     　cat ./t1.html
     
  5. /WebAPP1/t1.htmlにアクセスすると、test.htmlの内容が表示され、シンボリックリンクを行えていることが確認できます。
     
     
  ※シンボリックリンクはWindows OSでは使用できません。Unix系OSで使用してください。

Q11　Webサーバプラグインのログローテート機能を利用したいのですが、どのようにしたらよろしいでしょうか？

A11　以下の例を参考にファイルを編集し、Webサーバを再起動してください。

対象ファイル：<WebOTXインストールディレクトリ>/domains/domain1/config/WebCont/*.conf-auto

一日（86400秒）毎にログローテートされます。
※　*.conf-autoファイルはデフォルト名のままである場合、ドメイン再起動で上書きされます。必要に応じてファイル名をリネームしてください。

詳細および、その他のWebサーバについては以下を参照してください。

• ドメイン構築・基本設定ガイド > 8. ログ > 8.2. 各サービスのログ > 8.2.14. Webコンテナ

2.6.2. Webアプリケーションの開発に関するQ&A

Q1　servletをコンパイルするときに、WebOTXではどのjarを利用するのでしょうか？

A1　${AS_INSTALL}/lib/javaee.jar を利用してください。

Q2　Webアプリケーションを自動的に配備するには、どうすれば良いのでしょうか？

A2　Tomcatでは、webappsディレクトリにWARファイルを置くと自動的に配備されますが、WebOTXでは ${ INSTANCE_ROOT}/autodeploy ディレクトリにWARファイルを格納することで、自動的に配備できます。

Q3　context.xml にWebアプリケーションが利用するパラメータを記述しているのですが、WebOTX ではどこに記述すればよいのでしょうか？

A3　WebOTX には context.xml は存在しません。web.xml に記述してください。

2.6.3. 環境設定、チューニングに関するQ&A

Q1　WebOTXでJavaVMのメモリ量を指定するには、どうすれば良いのでしょうか？

A1　Tomcatでは、起動用のファイルでJavaVMのメモリ量を指定しますが、WebOTXでは運用管理コマンド（otxadmin） で指定します。

【割り当てメモリの最大値を 1024 MB にする例】

otxadmin> create-jvm-options --user <ユーザ名> --password <パスワード> --host <ホスト名> --port <管理ポート>　-Xmx1024m:

詳細については、WebOTXマニュアル [ 高度な管理と運用サイクルガイド > 2. チューニング > 2.1. APサーバ > 2.1.2. リソースチューニング > 2.1.2.1. ドメインエージェントプロセスのヒープサイズの見直し ] をご覧ください。

Q2　Apacheと連携するときの同時接続（スレッド）数の設定は、どうすれば良いのでしょうか？

A2　Tomcatでは server.xml を編集して設定しますが、WebOTXでは運用管理コマンド（otxadmin） で指定します。

【同時に処理できるリクエストの数を拡大する例】

otxadmin> set --user <ユーザ名> --password <パスワード> --host <ホスト名> --port <管理ポート> server.network-config.network-listeners.network-listener.<リスナID>.max-processors=<最大数>

詳細については、WebOTXマニュアル [ 高度な管理と運用サイクルガイド > 2. チューニング > 2.3. Webコンテナ > 2.3.1. プロセッサ数 > 2.3.1.1. 最大プロセッサ数 ] をご覧ください。

Q3　JDBCデータソースの設定は、どうすれば良いのでしょうか？

A3　Tomcatでは server.xml を編集して設定しますが、WebOTXでの設定方法は本資料の 2.3.4. JDBCデータソースの設定をご覧ください。

Q4　１台のサーバで複数のWebコンテナを起動するには、どうすれば良いのでしょうか？

A4　Tomcatでは、Tomcatのディレクトリをコピーして、同じマシンで複数のTomcatを起動しますが、WebOTXでは複数のドメインを作成することで複数のWebコンテナを起動することができます。

Q5　Tomcatからの移行時に対応する環境設定を教えてください。

A5　環境設定の対応は以下となっています。

• JAVA_HOME
  

  　JAVA_HOMEは、インストール時に「JDKがインストールされているディレクトリ」を指定していると思います。
  

• CATALINA_OPTS
  

  　Java VMオプションは、次の箇所に設定してください。
  　■スタンダードモードの場合StdM
  　　運用管理コンソールでドメイン⇒アプリケーションサーバ⇒JVM構成⇒属性
  　　"JVMオプション"に設定してください　
  　■アドバンスドモードの場合AdvM
  　　運用管理コンソールでドメイン⇒TPシステム⇒アプリケ<ーショングループ⇒＜アプリケーショングループ名＞⇒プロセスグループ⇒＜プロセスグループ名＞
  　　「属性」タブの「「Javaシステムプロパティ」に設定してください。
  
  　既に設定されているJava VMのメモリ指定等は編集してください。
  　新規の項目は、追加してください。
  
  

• SHILIB_PATH、LD_LIBRARY_PATH、CONFIG_PATH
  

  　既存の環境のとおりOSの環境変数に設定してください。
  

• CLASSPATH 　クラスパスは、次の箇所に設定してください。
  

  　■スタンダードモードの場合StdM
  　運用管理コンソールでドメイン⇒アプリケーションサーバ⇒JVM構成⇒属性
  　”サーバのクラスパス” に設定してください　
  　■アドバンスドモードの場合AdvM
  　運用管理コンソールでドメイン⇒TPシステム⇒アプリケーショングループ⇒＜アプリケーショングループ名＞⇒プロセスグループ⇒＜プロセスグループ名＞
  　「属性」タブの「「環境変数」に設定してください。
  
  

※環境変数の詳細については、WebOTXマニュアル [ ドメイン構築・基本設定ガイド > 2. 環境設定 > 2.1. システム環境変数 ] をご覧ください。

2.7. 注意事項

2.7.1. J2SE SDKに関する注意事項

WebOTXが動作保証するJ2SE SDK（JDK）に変更する場合、WebアプリケーションやWebアプリケーションが依存するライブラリが、特定のJ2SE SDKに依存しないか動作確認を行ってください。

2.7.2. Tomcatとの差異

• WebOTXではWARファイル名から拡張子を除いた名称と、配備時に指定したコンテキスト名が異なった場合、WARファイル名から拡張子を除いた名称をコンテキスト名としては利用できません。
• WebOTXでは、web.xmlファイルからWebアプリケーションの配備情報を取得しているため、web.xmlファイルは必須で。web.xmlファイルがない、もしくは、正しく記述されていない場合、WARファイルを配備することができません。

2.7.3. Tomcatポート番号との対応表

Tomcat 6.x、7.x、WebOTX V5、V6、V7、V8、V9で使用するポート番号の一覧を下記に示します。