2. マイグレーションアシスタントを利用しないマイグレーションガイド

2.1. はじめに

前章でも説明したように、WebOTX V9.4より提供するマイグレーション機能を利用することで、 移行作業の容易化と、それにかかるコストを低減することができますが、本章では、マイグレーション 機能を利用しない場合のシステムの移行方法について説明します。

WebOTX Developer を利用できない環境での移行作業や、マイグレーションアシスタントでサポートして いない古いバージョンのTomcat/WebOTXや、その他のAPサーバ(JRun、WebLogic、WebSphere)から WebOTX V9.4 にシステムを移行する際の作業支援に役立ちます。
なお、本章の説明内容は、以前の WebOTXマニュアルでは 「リファレンス集 ドメイン構成・環境移行編」-「2.他APサーバ(Tomcat)からWebOTXへの移行ガイド」 として記載していました。

本章で対象とする移行元のAPサーバは以下のとおりです。

表2.1-1
対象APサーバ バージョン
Tomcat 3.x
4.x
5.0.x
5.5.x
6.x
WebOTX 5.x
6.x
7.x
8.x
9.x
その他のAPサーバ
(JRun、WebLogic、WebSphere)
-

2.2. ソフトウェア条件

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

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

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

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

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

2.2.2. Webサーバ

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

2.2.3. データベース

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

2.2.4. 同梱するライブラリ

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

表2.2.4-1
名称 V5.3V6.1V6.22 V6.31V6.4V6.50.02 V7.11.08V8.12V8.2 V8.31V8.4V8.42 V9.1V9.2 V9.3 V9.4
Java Beans Activation Framework (JAF) -1.0.21.0.2 1.0.21.0.21.0.2 1.0.21.0.21.0.2 1.0.2 1.0.2 1.0.2 1.11.1 1.1 1.1
JavaMail -1.3.11.3.1 1.3.11.3.11.3.1 1.3.11.3.11.3.1 1.4 1.4 1.4 1.41.4 1.4 1.4
JAXP -1.2.51.2.5 1.2.51.2.51.2.5 1.3.041.3.041.3.04 1.3.04 1.3.04 1.3.04 同梱なし同梱なし 同梱なし 同梱なし
Ant -1.5.41.5.4 1.5.41.5.41.5.4 1.6.51.7.01.7.0 1.7.1 1.8.2 1.8.4 1.8.41.8.4 1.8.4 1.8.4
Jakarta Commons BeanUtiles (*1) -1.6.11.6.1 1.7.01.7.01.7.0 1.7.01.7.01.7.0 1.8.0 1.8.0 1.8.0 同梱なし同梱なし 同梱なし 同梱なし
Jakarta Commons Codec (*1) -1.21.3 1.31.31.3 1.31.31.3 1.3 1.4 1.4 同梱なし同梱なし 同梱なし 同梱なし
Jakarta Commons Collections (*1) -2.112.11 2.112.112.11 2.112.112.11 2.11 2.11 2.11 同梱なし同梱なし 同梱なし 同梱なし
Jakarta Commons Digester (*1) -1.51.6 1.71.71.8 1.81.81.8 1.8 1.8 1.8 同梱なし同梱なし 同梱なし 同梱なし
Jakarta Commons Discovery (*1) -0.20.2 0.20.20.4 0.40.40.4 0.4 0.4 0.4 同梱なし同梱なし 同梱なし 同梱なし
Jakarta Commons EL (*1) -1.01.0 1.01.01.0 1.01.01.0 1.0 1.0 1.0 同梱なし同梱なし 同梱なし 同梱なし
Jakarta Commons FileUpload (*1) 1.01.01.0 同梱なし同梱なし同梱なし 同梱なし同梱なし同梱なし 同梱なし 同梱なし 同梱なし 同梱なし同梱なし 同梱なし 同梱なし
Jakarta Commons Launcher (*1) -1.0-dev1.1 1.11.11.1 1.11.11.1 1.1 1.1 1.1 同梱なし同梱なし 同梱なし 同梱なし
Jakarta Commons Logging (*1) 1.0.41.0.41.0.4 1.0.41.0.41.1 1.11.1.11.1 1.1 1.1.1 1.1.1 同梱なし同梱なし 同梱なし 同梱なし
Jakarta Commons Modeler (*1) -1.11.1 1.11.12.0 2.02.02.0 2.0 2.0 2.0 同梱なし同梱なし 同梱なし 同梱なし
Jakarta Regexp -1.31.3 1.41.41.4 1.51.51.5 1.5 1.5 1.5 同梱なし同梱なし 同梱なし 同梱なし
Log4j -1.2.81.2.8 1.2.131.2.131.2.14 1.2.141.2.15(*1)1.2.15(*1) 1.2.15(*1) 1.2.15(*1) 1.2.17(*1) 1.2.17(*1)1.2.17(*1) 1.2.17(*1) 1.2.17(*1)
XML Xerces 2 Java Parser -2.5.02.5.0 2.5.02.5.02.5.0 2.9.02.9.12.9.1 2.9.1 2.9.1 2.9.1 同梱なし(*2)同梱なし(*2) 同梱なし(*2) 同梱なし(*2)
XML Xalan Java 2 -2.5.22.5.2 2.5.22.5.22.5.2 2.7.02.7.12.7.1 2.7.1 2.7.1 2.7.1 同梱なし(*2)同梱なし(*2) 同梱なし(*2) 同梱なし(*2)
The Web Services Description Language
for Java Toolkit (WSDL4J)
-1.41.4 1.41.41.4 1.41.41.4 1.4 1.4(*3) 1.4(*3) 同梱なし同梱なし 同梱なし 同梱なし

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

*2:V9以降は、XercesおよびXalanを同梱しなくなりました。

JAXPを使用するアプリケーションでJAXP実装のライブラリを含まない場合、デフォルトではJDKに含まれるJAXP実装(com.sun.org.apache.〜 で始まるクラス)が使用されます。
(V8までは、WebOTXに同梱のXerces、Xalanが使用されていました。)

一方、JDKに含まれるJAXP実装クラスのパッケージは、アクセスが制限されています。(Memo参照)
そのため、 ${INSTANCE_ROOT}/config/server.policy を編集して、JAXPを使用するアプリケーションのコードに対して、JDKに含まれるJAXP実装のパッケージへのアクセス権を付与する必要があります。
※ アプリケーション内(例: WARファイル内のWEB-INF/lib)にXerces、Xalanを含む場合は、そちらのJAXP実装が使われるため、アクセス権の付与は必要ありません。

server.policyに追加する権限の例は以下の通りです。

grant codeBase "file:${com.nec.webotx.instanceRoot}/applications/<アプリケーション名>/-" {
    permission java.lang.RuntimePermission "accessClassInPackage.*";
};

grant codeBase "file:${com.nec.webotx.instanceRoot}/generated/-" {
    permission java.lang.RuntimePermission "accessClassInPackage.*";
};

上記の例では、アクセス制限のある全てのパッケージへのアクセス権を付与していますが、 "accessClassInPackage.com.sun.org.apache.xerces.internal.*" や "accessClassInPackage.com.sun.org.apache.xalan.internal.*" のように指定することで、使用するパッケージへのアクセス権のみを付与することも可能です。
その場合は、使用する機能に合わせてパッケージ名を指定した権限を追加してください。

Memo
${JRE_HOME}/lib/security/java.security の package.access に指定されたパッケージおよびそのサブパッケージにアクセスするコードには、 java.lang.RuntimePermission "accessClassInPackage.{パッケージ名}" を与える必要があります。
権限がない場合、該当するパッケージのクラスのロードに失敗します。

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

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

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

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

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

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

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

domain1/lib/ext
  ↑
WebOTX/modules(Webアプリケーションで使用するjarファイルはここには入れないで下さい)
  ↑
WebOTX/lib, domain1/lib
  ↑
classpath
  ↑
WEB-INF/lib

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

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

ロードされるライブラリの優先順位はdelegate=true の場合は以下のようになります。delegate の設定はWebAP のWEB-INF/nec-web.xml で設定します。

domain1/lib/ext
  ↓
WebOTX/lib
  ↓
domain1/lib
  ↓
classpath
  ↓
WEB-INF/lib

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

WEB-INF/lib
  ↓
domain1/lib/ext
  ↓
WebOTX/lib
  ↓
domain1/lib
  ↓
classpath


クラスローダの詳細は、[ ドメイン構築・基本設定ガイド > 5.9. クラスローダ ] をご参照ください。

2.3. 移行作業

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

2.3.1. ディレクトリ構成

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


図2.3.1-1

2.3.2. 移行作業一覧

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

表2.3.2-1
移行作業 Tomcat のバージョン WebOTX のバージョン 他APサーバ 本章での説明
3.x 4.x 5.0 5.5 6.x 7.x V5.x V6.x V7.x V8.1 V8.2-
V8.4
V9.1-
V9.3
JRun WebLogic WebSphere
パッケージの設定 2.3.2.1.
JDBCデータソースの設定 2.3.2.2.
log4jの設定 2.3.2.3.
nec-web.xmlの設定 2.3.2.4.
セキュリティポリシーの設定 2.3.2.5.
Tomcatの差異による対応 2.3.2.6.
JavaVMオプションの設定 2.3.2.7.
その他のAPサーバからの移行 2.3.9.
WebOTX V8とV9の差異 2.3.10.

○:作業要  △:条件により作業要  −:不要(対応済み)

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.3は、JDK 7、JDK8 をサポートします。

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

アプリケーションからJDBCデータソースをルックアップする際に、引数として"java:comp/env/"から始まる文字列(環境ネーミングコンテキスト名)を用いている場合、 環境ネーミングコンテキスト名と、ここで指定したJNDI名(JNDI物理名)のマッピングをnec-web.xmlファイルに resource-ref 要素として記述する必要があります。2.3.6.6. resource-ref の設定を参照してください。

2.3.4.2. クラスパスの設定

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

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

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

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

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

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

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

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

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

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

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ベース認証を利用する場合、次の箇所を設定します。

【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>
【nec-web.xmlの記述例(抜粋)】

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

※overrideablejavaxpackages の設定をドメイン全体で有効にするには、processLauncher.xmlに "com.nec.webotx.enterprise.overrideablejavaxpackages"の設定を行います。 次の内容を参考にして${AS_INSTALL}/lib/processLauncher.xmlを編集してください。

<?xml version="1.0"?>
<processes>
    <process name="webotx-server">
            :
        <sysproperty key="com.nec.webotx.enterprise.overrideablejavaxpackages"
            value="javax.help,javax.portlet,パッケージ名"/>
            :

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.6.6. resource-ref の設定

アプリケーションからJDBCデータソースをルックアップする際に、引数として"java:comp/env/"から始まる文字列(環境ネーミングコンテキスト名)を用いている場合、 環境ネーミングコンテキスト名と2.3.4.1. JDBCデータソースの設定方法で指定したJNDI名(JNDI物理名)とのマッピングを nec-web.xml に resource-ref 要素 として記述する必要があります。

<resource-ref>
  <res-ref-name>環境ネーミングコンテキスト名("java:comp/env/"より後ろの部分)</res-ref-name>
  <jndi-name>JNDI物理名</jndi-name>
</resource-ref>

例えば、アプリケーション内で"java:comp/env/jdbc/MyOracle"という文字列を引数にルックアップしており、 で"jdbc/MyOracle"というJNDI物理名でJDBCデータソースを作成したのであれば、以下のように記述します。

<resource-ref>
  <res-ref-name>jdbc/MyOracle</res-ref-name>
  <jndi-name>jdbc/MyOracle</jndi-name>
</resource-ref>

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

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

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

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

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

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

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の許可を追加しています。 設定後は、ドメインを再起動することで反映されます。

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) 次の方法で設定を追加します。

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

WebOTX Media V9 Release 4以降からインストールした場合では、これらの暗黙オブジェクトの値を 変更するためのJVMオプション(com.nec.webotx.jasper.compiler.NO_FINAL_VARIABLES)を追加しています。 デフォルトは false で意味は以下のようになります。

 true:final宣言を付けない(WebOTX V8互換)
 false:final宣言を付ける

設定方法の詳細については、 [1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ > 1.4.2. Webコンテナ設定項目一覧 > 1.4.2.3. JavaVMオプションで設定可能な項目一覧] を参照してください。

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"が有効でした。

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サーバには、次の制限があります。

この制限を回避するには、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)

設定値説明
trueBIO(既定値)
falseGrizzly NIO

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

type説明
grizzlyGrizzly NIOコネクタ(既定値)
ajpWebサーバ連携コネクタ
nioNIOコネクタ
bioBIOコネクタ

2.3.10.6. 統計情報採取の設定

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

設定値説明
ON採取する
OFF採取しない

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

設定値説明
HIGH採取する
OFF採取しない

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

システムプロパティ:org.apache.catalina.session.useConcurrentHashMap

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の既定値

Dottedname :server.applications.web-module.<Webアプリケーション名>.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への移行

1クライアントが送信したメッセージを接続済みの全クライアントにレスポンスするチャットの様なアプリケーションを、 Tomcat CometからServlet 3.0 Cometに移行する場合を想定して移行方法を説明します。
移行ポイント Tomcat Comet Servlet3.0 の非同期APIへの移行
サーブレットクラス定義 Tomcat Cometはorg.apache.catalina.comet.CometProcessorをimplementsしています。 普通のServletと同じくHttpServletを継承し、CometProcessorのimplementsは削除します。

public class XXXServlet extends HttpServlet

次のいずれかを設定する必要があります
□@WebServlet に asyncSupported=true を指定。
例えば「@WebServlet(urlPatterns = {"/chat"}, asyncSupported = true)」

□web.xmlの<servlet> 要素の下に「<async-supported>true</async-supported>」を追加。
メッセージキュー メッセージキュー(1クライアントがリクエストしたデータをその他の非同期コンテキストに通知するためのキュー) を使用している場合はServlet3.0 Cometではそのまま流用可能です。
 
Tomcat 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();
}

コネクションキュー コネクション(HttpServletResponseやPrintWriter等)のキューを管理している場合は、Servlet3.0では代わりにAsyncContextをキューで管理します。 HttpServletRequestのstartAsync()を実行した戻り値の AsyncContextをキューに登録します。
AsyncContext ac = request.startAsync();
this.queue.add(ac);
Timeout時間 TomcatではCometEventのsetTimeout()でタイムアウト時間を設定しています。
public void event(CometEvent event) throws IOException, ServletException {
    …
    if (event.getEventType() == CometEvent.EventType.BEGIN) {
    	event.setTimeout(30 * 60 * 1000); // 30分
Servlet3.0ではAsyncContextのsetTimeout()でタイムアウト時間を設定します
AsyncContext ac = request.startAsync();
ac.setTimeout(30 * 60 * 1000); // 30分
エラーコネクションの削除 Tomcat Cometで eventメソッドでのイベントがCometEvent.EventType.ERRORの場合やCometEvent.EventType.ENDの場合にコネクションを キューから削除している例です。
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取得後にAsyncContextにAsyncListenerの実装をaddListener()します。
AsyncContext ac = request.startAsync();
ac.addListener(new AsyncListenerImpl());

Servlet3.0ではAsyncContextに登録するAsyncListenerの実装内のonError()とonTimeout()でコネクションをキューから削除します
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());
        }
    }
}
init メソッド 色々な初期化処理が記述されていると思います。
以下は、メッセージキューを使うために、通知者用スレッドを開始している例です。
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();
initで行っている処理はそのまま移植します。
コネクションキューから取得されるコネクション情報はAsyncContextに変更します。

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();
eventメソッド Tomcat Cometのイベントが発生した場合の処理が記述されています。
Servlet3.0では下記の対応を行います。
CometEvent<wbr>.EventType<wbr>.BEGIN eventメソッドでイベントタイプがCometEvent.EventType.BEGIN の場合の処理です。
if (event.getEventType() == CometEvent.EventType.BEGIN) {
    …
}
doGetメソッドやdoPostメソッドで処理を行います。
CometEvent<wbr>.EventType<wbr>.READ eventメソッドでイベントタイプがCometEvent.EventType.READ の場合の処理です。
if (event.getEventType() == CometEvent.EventType.READ) {
    …
}
doGetメソッドやdoPostメソッドでServletRequestの getInputStream()を使って ServletInputStreamを取得します。
CometEvent<wbr>.EventType<wbr>.ERROR eventメソッドでイベントタイプがCometEvent.EventType.ERROR の場合の処理です。
if (event.getEventType() == CometEvent.EventType.ERROR) {
    …
}
javax.servlet.AsyncListener を実装したクラスの onErrorメソッドに処理を記述します。
class AsyncListenerImpl extends Thread implements AsyncListener{
    …
    public void onError(AsyncEvent event) throws IOException {
        …
    }
}
CometEvent<wbr>.EventSubType<wbr>.TIMEOUT eventメソッドでイベントタイプがCometEvent.EventSubType.TIMEOUT の場合の処理です。
if (event.getEventSubType() == CometEvent.EventSubType.TIMEOUT) {
    …
}
javax.servlet.AsyncListener を実装したクラスの onTimeoutメソッドに処理を記述します。
class AsyncListenerImpl extends Thread implements AsyncListener{
    …
    public void onTimeout(AsyncEvent event) throws IOException {
        …
    }
}
doGet/doPost メソッド Tomcat Cometでは使用しません。 Tomcat Cometでイベントが CometEvent.EventType.BEGIN の場合に行っている処理をここで実装します。
実装される処理には以下の様なものがあります。 ・AsyncContextを生成します。
・タイムアウト時間を設定します。
・AsyncListenerを生成してAsyncContextに追加します。
・AsyncContextをキューに追加します。

final AsyncContext ac = req.startAsync();
ac.setTimeout(10 * 60 * 1000); 
ac.addListener(new AsyncListener() { 
    ... 
}; 
queue.add(ac);
destroy メソッド 以下の様な色々な後処理が実装されていると思います。
・キューのクリア。
・通知者スレッドの中止。

queue.clear();
notifierThread.interrupt();
Tomcat Cometからそのまま移植します。

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

1クライアントが送信したメッセージを接続済みの全クライアントにレスポンスするチャットの様なアプリケーションを、 Grizzly CometからServlet 3.0 Cometに移行する場合を想定して移行方法を説明します。
移行ポイント Grizzly Comet Servlet3.0 の非同期APIへの移行
サーブレットクラス定義 普通のServletと同じくHttpServletを継承しています。

public class XXXServlet extends HttpServlet
サーブレットクラスの継承はそのまま変えません。
public class XXXServlet extends HttpServlet

次のいずれかを設定する必要があります
□@WebServlet に asyncSupportedを指定。
例えば「@WebServlet(urlPatterns = {"/chat"}, asyncSupported = true)」

□web.xmlの<servlet> の下に「<async-supported>true</async-supported>」を追加。
メッセージキュー CometContextのnotify()の引数にメッセージを渡す事でGrizzlyが管理しているメッセージキューにメッセージを登録している例です。

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();
}

コネクションキュー HttpServletResponse等にアタッチするためのCometHandlerを実装したクラスをCometContextに登録する事で、コネクションキューが管理されています。

CometHandlerImpl handler = new CometHandlerImpl();
handler.attach(response);
CometContext cometContext = CometEngine.getEngine().getCometContext(this.contextPath);
cometContext.addCometHandler(handler);
下記の例ではHttpServletResponseをアタッチしています。
public class CometHandlerImpl implements CometHandler<HttpServletResponse>{
  private  HttpServletResponse response;

  …

  public void attach(HttpServletResponse response){
    this.response = response;
  }
  …
}
コネクションキューは独自に実装します。
HttpServletRequestのstartAsync()を実行した戻り値AsyncContextをコネクションキューに登録します。

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

…

AsyncContext ac = request.startAsync();
this.queue.add(ac);
Timeout時間 CometContextのsetExpirationDelay()を行います。
CometContext cometContext = CometEngine.getEngine().register(contextPath);
cometContext.setExpirationDelay(30 * 60 * 1000);
コネクションキューに登録する前にAsyncContextのsetTimeout()を行います。
AsyncContext ac = request.startAsync();
ac.setTimeout(30 * 60 * 1000);
エラーコネクションの削除 Grizzly内部で管理しています。 AsyncContext取得後にAsyncContextにAsyncListenerの実装をaddListener()します。
AsyncContext ac = request.startAsync();
ac.addListener(new AsyncListenerImpl());

AsyncListenerの実装のonError()とonTimeout()で、コネクションキューからAsyncContextを削除します。

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());
  }
}
init メソッド CometEngineにcontextPathを登録しています。
タイムアウト時間を設定しています。

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();
イベントハンドラ CometHandlerを実装したクラスがイベントハンドラです。
public class CometHandlerImpl implements CometHandler<HttpServletResponse>{
    ・・・

    public void onEvent(CometEvent event) 
    throws IOException{
        ・・・
    }
}
Sservlet3.0ではjavax.servlet.AsyncListener を実装したクラスがイベントハンドラです。
下記の対応を行います。
イベントハンドラ(onEvent) CometContextのnotify()を実行するとCometHandlerを実装したクラスのonEvent()がCometEvent.NOTIFYイベントで呼び出されます。
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();
        }

    }
}
Sservlet3.0ではメッセージキューから値を取り出しコネクションキューにあるコネクションに対してレスポンスを送信する処理を独自に作成して実装します。
initメソッドの例を参考にしてください。
イベントハンドラ(onInitialize) onInitialize()はリクエスト受信時に呼び出されます。
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();
    }
}
Sservlet3.0ではdoGetメソッドやdoPostメソッドにて実装します。
イベントハンドラ(onTerminate) onTerminate()はCometEngineからコンテキストがunregister()される際に呼び出されます。
例ではコネクションのクローズを行っています。
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);
    }
}
特に実装はありません。
イベントハンドラ(onInterrupt) onInterrupt()はタイムアウト時やクライアントから接続が閉じられた場合に呼び出されます。
例ではコネクションのクローズを行っています。
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);
    }
}
AsyncListenerの実装クラスのonError()やonTimeout()でコネクションキューからAsyncContextを削除する処理を実装します。
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());
    }
}
doGet/doPost メソッド ■メッセージレスポンス用リクエストの場合
HttpServletResponseをアタッチした CometHandler実装クラスをCometContextに追加しています。
ChatListnerHandler handler = new ChatListnerHandler(); 
handler.attach(response); 
CometContext cometContext = CometEngine.getEngine().getCometContext(contextPath);
cometContext.addCometHandler(handler)
■メッセージリクエスト用リクエストの場合
CometContextのnotify(message)を実行しています。
CometContext cometContext = CometEngine.getEngine().getCometContext(this.contextPath);
cometContext.notify(message);
■メッセージレスポンス用リクエストの場合
AsyncContext にAsyncListenerの実装クラスを追加してコネクションキューにAsyncContextを追加します。
final AsyncContext ac = req.startAsync();
AsyncListenerImpl listener = new AsyncListenerImpl();
ac.addListener(listener);
queue.add(ac);
■メッセージリクエスト用リクエストの場合
メッセージキューにメッセージを登録します。
this.messageQueue.add(message);
destroy メソッド - ・Grizzly Cometで実装があればそのまま移植します。
・コネクションキューをクリアしてメッセージ通知用スレッドを中止します。

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
項目 Tomcat WebOTX 本章での説明
Webサーバとの連携 設定ファイルを直接編集 環境設定ツールを提供
WebOTX Webサーバ利用時は自動的に連携設定
2.4.1.
配備方法 Managerアプリケーションを使うか、webappsディレクトリへWARファイルをコピー 運用管理コマンド、運用管理コンソールを提供し、autodeployディレクトリへのファイルコピーでの配備にも対応 2.4.4.
複数Webコンテナの構成 Tomcatを複数インストール 複数のドメインを作成 -
運用管理コマンド なし 運用管理コマンドを提供 2.4.2.
運用管理コンソール Administration Tool、Managerアプリケーションを提供 運用管理コンソールを提供 2.4.3.

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 のいずれかが必要です。

【Web版統合運用管理コンソール】

図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

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

※ 各引数の詳細は、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

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

※ 各引数の詳細は、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共通)

表2.5.1-1
項目 説明 設定箇所 設定方法
maxPostSize コンテナの FORM URL パラメタ構文解析で扱う POST の最大バイト数を指定します。 この属性を 0 以下の値にセットすると無制限になります。
デフォルト値は2097152 (2MByte)です。
domain.xml ■運用管理コンソールへの設定例
<ドメイン名>
 -「アプリケーションサーバ」
  -「ネットワーク構成」
   -「プロトコル構成」
    -「<プロトコル名>」
     -「HTTP」
の順にクリックしていき、「属性」タブの「最大ポストサイズ」に設定を行います。

■運用管理コマンドでの設定例
  otxadmin> set server.network-config.protocols.protocol.http-listener.http.max-post-size-bytes=2097152

■domain.xmlへの設定例
http要素のmax-post-size-bytes属性を設定します。
<network-config> <protocols> <protocol name="http-listener"> <http max-post-size-bytes="2097152">
maxParameterCount 処理可能なリクストパラメータの上限を指定します。 指定値を超えたパラメータは無視されます。 -1 を設定した場合、上限値は無制限となります。 デフォルト値は10000です。 このパラメータをむやみに大きくすることはセキュリティ上問題があります。詳細な情報については以下の参考ページを参照ください。
参考:Apache Tomcat におけるサービス運用妨害 (CPU 資源の消費) の脆弱性
domain.xml ■運用管理コンソールへの設定例
<ドメイン名>
 -「アプリケーションサーバ」
  -「ネットワーク構成」
   -「プロトコル構成」
    -「<プロトコル名>」
     -「HTTP」
の順にクリックしていき、「操作」タブの「プロパティの設定」に記述を行います。
「maxParameterCount=20000」

■運用管理コマンドでの設定例
  otxadmin> set server.network-config.protocols.protocol.http-listener.http.property.maxParameterCount=20000

■domain.xmlへの設定例
http要素のmaxParameterCountプロパティを設定します。
<network-config> <protocols> <protocol name="http-listener"> <http >  <property name="maxParameterCount" value="20000" />
proxyName このコネクタがプロキシを利用する場合、そのプロキシのサーバ名を指定します。HttpServletRequest.getServerName() が返すサーバ名の設定です。
デフォルト値はありません。
またsendRedirect実行時の宛先URLにも影響します。詳細は[リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ > 備考.sendRedirect実行時の宛先URLについて]を参照してください。
domain.xml ■運用管理コンソールへの設定例
<ドメイン名>
 -「アプリケーションサーバ」
  -「ネットワーク構成」
   -「プロトコル構成」
    -「<プロトコル名>」
     -「HTTP」
の順にクリックしていき、「属性」タブの「プロキシ名」に設定を行います。

■運用管理コマンドでの設定例
  otxadmin> set server.network-config.protocols.protocol.http-listener.http.proxy-name=www.mycompany.com

■domain.xmlへの設定例
http要素のproxy-name属性を設定します。
<network-config> <protocols> <protocol name="http-listener"> <http proxy-name="www.mycompany.com">
proxyPort このコネクタがプロキシを利用する場合、そのプロキシのポート番号を指定します。HttpServletRequest.getServerPort() が返すポート番号の設定です。
デフォルト値はありません。
またsendRedirect実行時の宛先URLにも影響します。詳細は[リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ > 備考.sendRedirect実行時の宛先URLについて]を参照してください。
domain.xml ■運用管理コンソールへの設定例
<ドメイン名>
 -「アプリケーションサーバ」
  -「ネットワーク構成」
   -「プロトコル構成」
    -「<プロトコル名>」
     -「HTTP」
の順にクリックしていき、「属性」タブの「プロキシポート」に設定を行います。

■運用管理コマンドでの設定例
  otxadmin> set server.network-config.protocols.protocol.http-listener.http.proxy-port=80

■domain.xmlへの設定例
http要素のproxy-port属性を設定します。
<network-config> <protocols> <protocol name="http-listener"> <http proxy-port="80">
URIEncoding 「http://contents?a=%12%34」形式で記述されたURLをデコードする際の文字エンコーディングを指定します。
デフォルト値は「ISO-8859-1」です。
domain.xml ■運用管理コンソールへの設定例
<ドメイン名>
 -「アプリケーションサーバ」
  -「ネットワーク構成」
   -「プロトコル構成」
    -「<プロトコル名>」
     -「HTTP」
の順にクリックしていき、「属性」タブの「URIエンコーディング」に設定を行います。

■運用管理コマンドでの設定例
  otxadmin> set server.network-config.protocols.protocol.http-listener.http.uri-encoding=Shift_JIS

■domain.xmlへの設定例
http要素のuri-encoding属性を設定します。
<network-config> <protocols> <protocol name="http-listener"> <http uri-encoding="Shift_JIS">
useBodyEncodingForURI Tomcat4.1.x系との互換性の為に使用されます。デフォルト値は false ですが、互換を保つには true を指定して下さい。true にすると、ContentType又はRequest.setCharacterEncodingメソッドで指定されたエンコーディングをデコードに使用します。同じHTTPの属性の"uri-encoding"は使用されません。
デフォルト値はfalseです。
domain.xml ■運用管理コンソールへの設定例
<ドメイン名>
 -「アプリケーションサーバ」
  -「ネットワーク構成」
   -「プロトコル構成」
    -「<プロトコル名>」
     -「HTTP」
の順にクリックしていき、「属性」タブの「URIのエンコーディング」に設定を行います。

■運用管理コマンドでの設定例
  otxadmin> set server.network-config.protocols.protocol.http-listener.http.use-body-encoding-for-uri=true

■domain.xmlへの設定例
http要素のuse-body-encoding-for-uri属性を設定します。
<network-config> <protocols> <protocol name="http-listener"> <http use-body-encoding-for-uri="true">
xpoweredBy Servlet 仕様で推奨されたヘッダを使って、その仕様をサポートしていることを広告します。
デフォルト値はfalseです。
domain.xml ■運用管理コンソールへの設定例
<ドメイン名>
 -「アプリケーションサーバ」
  -「ネットワーク構成」
   -「プロトコル構成」
    -「<プロトコル名>」
     -「HTTP」
の順にクリックしていき、「属性」タブの「X-Powered-Byヘッダの有効化」に設定を行います。

■運用管理コマンドでの設定例
  otxadmin> set server.network-config.protocols.protocol.http-listener.http.xpowered-by=true

■domain.xmlへの設定例
http要素のxpowered-by属性を設定します。
<network-config> <protocols> <protocol name="http-listener"> <http xpowered-by="true">
format アクセスログの出力形式をカスタマイズすることができます。
デフォルト値は"%h %l %u %t "%r" %s %b"です。

フォーマットは以下になります。
%a - 接続元IPアドレス
%A - 自ホストのIPアドレス
%b - 送信バイト数 なしの場合は”-“
%B - 送信バイト数
%h - 接続元ホスト名
%H - リクエストプロトコル名
%l - 接続元論理ユーザ名
%m - リクエストメソッド
%p - 接続ポート番号
%q - クエリ文字列
%r - リクエストの最初の一行
%s - HTTPレスポンスステータスコード
%S - セッションID
%t - 日付と時間
%u - 認証済みのユーザ名
%U - リクエストされたURL
%v - ローカルホスト名
%D - リクエスト処理時間(ミリ秒)
%T リクエスト処理時間(秒)
domain.xml ■運用管理コンソールへの設定例
<ドメイン名>
 -「アプリケーションサーバ」
  -「HTTPサービス」
   -「アクセスログ」
の順にクリックしていき、「設定」タブの「フォーマット」に記述を行います。
「"%h %l %S %u %t \"%r\" %s %b %D"」

■運用管理コマンドでの設定例
  otxadmin> set server.http-service.access-log.format="%h %l %S %u %t \"%r\" %s %b %D"

■domain.xmlへの設定例
http-service要素のaccess-log要素のformatに設定します。
<http-service>
 <access-log format="%h %l %S %u %t"%r" %s %b %D">
 </access-log>
</http-service>

コネクタ(HTTP)

表2.5.1-2
項目 説明 設定箇所 設定方法
SSLEnabled コネクタ上で SSL トラフィックを有効にする場合はこの属性を使用します。コネクタ上で SSLハンドシェーク/暗号化/復号をオンにするには、この値をtrueに指定してください。
デフォルト値はfalseです。
domain.xml ■運用管理コンソールへの設定例
<ドメイン名>
 -「アプリケーションサーバ」
  -「ネットワーク構成」
   -「プロトコル構成」
    -「protocol」
    -「HTTPリスナ」
の順にクリックしていき、「設定」タブの「SSLの使用の有無」のチェックボックスで設定します。

■運用管理コマンドでの設定例
  otxadmin> set server.network-config.protocols.protocol.https-listener.security-enabled="true"

■domain.xmlへの設定例
protocol要素のsecurity-enabledを設定します。
<network-config>
 <protocols>
  <protocol security-enabled="true" name="https-listener">
scheme request.getScheme() 呼び出しで返されるセキュア情報を指定します。SSL を使用する場合は https を指定して下さい。デフォルト値はありません。
またsendRedirect実行時の宛先URLにも影響します。詳細は[リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ > 備考.sendRedirect実行時の宛先URLについて]を参照してください。
domain.xml ■運用管理コンソールへの設定例
<ドメイン名>
 -「アプリケーションサーバ」
  -「ネットワーク構成」
   -「プロトコル構成」
    -「protocol」
    -「HTTPリスナ」
     -「HTTP」
の順にクリックしていき、「属性」タブの「スキーマ」で http または https を設定します。

■運用管理コマンドでの設定例
  otxadmin> set server.network-config.protocols.protocol.http-listener.http.scheme="https"

■domain.xmlへの設定例
http 要素の scheme を設定します。
<network-config>
 <protocols>
  <protocol>
   <http scheme="https">
secure request.isSecure() 呼び出しで返されるスキーマ文字列を定義します。この値が true ならば https 通信が可能となります。デフォルト値はfalseです。 domain.xml ■運用管理コマンドでの設定例
  otxadmin> set server.network-config.protocols.protocol.http-listener.http.secure="true"

■domain.xmlへの設定例
http 要素の secure を設定します。
<network-config>
 <protocols>
  <protocol>
   <http secure="true">




コンテキスト(共通)

表2.5.1-3
項目 説明 設定箇所 設定方法
crossContext このアプリケーション内での ServletContext.getContext() の呼出しが、この仮想ホストで走っている他のwebアプリケーションへのリクエストディスパッチャを、セキュリティを意識した環境で、getContext() が常にnullを返すようにしたいならば、これをfalseにしてください。
デフォルト値はtrueです。
nec-web.xml
または
doman.xml
■運用管理コンソールへの設定例
<ドメイン名>
 -「アプリケーション」
  -「Webモジュール」
    -<Webモジュール名>
の順にクリックしていき、「属性」タブの「他モジュールへのアクセス」にチェックを行います。
この場合以下の設定も必要です。
  otxadmin> set server.applications.web-module.<アプリケーション名>.module.<Webモジュール名>.engine.web.web-module-config.override=true


■運用管理コマンドでの設定例
  otxadmin> set server.applications.web-module.<アプリケーション名>.module.<Webモジュール名>.engine.web.web-module-config.cross-context=false

この場合以下の設定も必要です。
  otxadmin> set server.applications.web-module.<アプリケーション名>.module.<Webモジュール名>.engine.web.web-module-config.override=true

■nec-web.xmlへの設定例
nec-web-app要素にpropertyを設定します。
<nec-web-app>
 <property name="crossContextAllowed" value="true" />
</nec-web-app>

■domain.xmlへの設定例
applications要素のweb-module要素に設定します。
<applications>
 <web-module cross-context="true" />
</applications>
reloadable /WEB-INF/classes/と/WEB-INF/libにあるクラスが変更されていないかどうかを監視します。 この機能はアプリケーション開発時には非常に有用ですが、顕著な実行時オーバヘッドを要するため、製品アプリケーションを配備して使用するときには勧められません。
WebOTX V9では本機能を設定ではなくコマンド実行にて実現します。
コマンドのため設定は無し ■運用管理コンソールへの設定例
<ドメイン名>
 -「アプリケーションサーバ」
  -「Webコンテナ」
の順にクリックしていき、「操作」タブの「Webアプリケーションの差異ロード」を選択し「実行」ボタンをクリックします。

■運用管理コマンドでの実行方法
  otxadmin> invoke server.web-container.reloadAllModules
resourceOnlyServlets welcome-fileが物理的に存在する必要があるサーブレット名を指定します。
ディレクトリアクセス時にファイル一覧を表示したい場合は"jsp"を設定してください。

設定値のフォーマット: "サーブレット名1[,サーブレット名2]..."
nec-web.xml ■nec-web.xmlへの設定例
nec-web-app要素にpropertyを設定します。
<nec-web-app>
 <property name="resourceOnlyServlets" value="jsp" />
</nec-web-app>


コンテキスト(Standard)

表2.5.1-4
項目 説明 設定箇所 設定方法
antiJARLocking この値をtrueにすると、クラスローダはURL経由でJAR内部のリソースをアクセスするとき、JARファイルロッキングを回避するように特別な手段をとります。これはアプリケーションの起動時間に多少の遅延が生じますが、ファイルロッキングが起こり得るプラットフォームや設定状況によっては有用です。
デフォルト値はfalseです。
nec-web.xml
または
doman.xml
Webアプリケーション配備解除や再配備すると設定が消えます。nec-web.xmlに記述するようにしてください。

■運用管理コンソールへの設定例
<ドメイン名>
 -「アプリケーション」
  -「Webモジュール」
   -<Webモジュール名>
    -「module」
     -<Webモジュール名>
      -「engine」
       -「web」
        -「web-module-config」
の順にクリックしていき、「操作」タブの「プロパティの設定」に記述を行います。
「antiJARLocking=true」

■運用管理コマンドでの設定例
  otxadmin> set server.applications.web-module.<Webアプリケーション名>.module.<Webアプリケーション名>.engine.web.web-module-config.property.antiJARLocking=true

■nec-web.xmlへの設定例
nec-web-app要素にpropertyを設定します。
<nec-web-app>
 <property name="antiJARLocking" value="true" />
</nec-web-app>

■domain.xmlへの設定例
web-module-config要素のpropertyに設定します。
<web-module-config>
 <property name="antiJARLocking" value="true" />
</web-module-config>


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

表2.5.1-7
項目 説明 設定箇所 設定方法
classname JDBCレルムに使用するクラス名を記述します domain.xml JDBCレルムの設定は下記のプロパティをまとめて設定します。

■運用管理コンソールへの設定例
<ドメイン名>
 -「アプリケーションサーバ」
  -「セキュリティサービス」
の順にクリックしていき、「操作」タブの「認証レルムの作成」にて設定します。

■運用管理コマンドでの設定例
  otxadmin> create-auth-realm --classname
com.nec.webotx.enterprise.security.auth.realm.jdbc.JDBCRealm
--property "driverName=oracle.jdbc.driver.OracleDriver:
jaas-context=JDBCRealm:connectionURL=jdbc\:oracle\:thin\:
@OracleServer\:1521\:OracleDB:connectionName=scott:
connectionPassword=tiger:user-table=jdbc_user:user-name-column=userid:
password-column=passwd:group-table=jdbc_role:group-name-column=role:
datasource-jndi=jdbc/DigestTest"
JDBCrealm


※DIGEST認証で使用するJDBCレルムの場合は、jaas-contextを jdbcDigestRealmに変更します。
datasource-jndi データソースを使ってデータベースに接続するためのJNDI名を記述します。
driverName 使用するJDBCドライバのクラス名を記述します。
group-name-column 対応するユーザを含む "user roles"テーブルの列名を記述します。
password-column 対応するパスワードを含む"users" テーブルの列名を記述します。
user-name-column ユーザ名を含む、"users"と"user roles"テーブルの列名を記述します。
group-table 記述したuserNameColとroleNameColを含む "user roles"テーブルの名前を記述します。
user-table 記述したuserNameColとuserCredColを含む "users"テーブルの名前を記述します。


Loader

表2.5.1-8
項目 説明 設定箇所 設定方法
delegate Webアプリケーションを読み込む際にクラスをロードするかどうかを指定します。
デフォルト値はtrueです。
nec-web.xml ■nec-web.xmlへの設定例
class-loader要素に設定します。
<nec-web-app>
 <class-loader delegate="true" />
</nec-web-app>




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 この機能の指定方法は2パターンあります、全Webアプリケーション共通の指定と、Webアプリケーション毎に指定するものです。それぞれdomain.xmlのweb-container要素のpropertyとwarファイルにアーカイブするnec-web.xmlに定義されます。

    全アプリケーション共通の設定、Webアプリケーション毎の設定の両方が指定された場合、Webアプリケーション毎の設定が優先されます。nec-web.xmlに指定する場合は、エンコーディングを1つ設定する指定か、localeとエンコーディングをマッピングさせてエンコーディングを決定する指定の2パターンを可能とします。両方が指定された場合、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 を指定する定義を追加し、ドメインを再起動してください。

対象ファイル:<WebOTXインストールディレクトリ>/domains/domain1/config/default-web.xml
<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>


エラー原因が上記ではない場合は、APでデータ型を明示的に指定することによりエラーを回避できる可能性があります。
AP修正例)
xxxxxxxx a = (xxxxxxxx)form.getViewList().get(idx);
              ↓
xxxxxxxx a = (xxxxxxxx)form.getViewList().get(idx.intValue());

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アプリケーション内からリンクする例です

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

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

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

JkLogFile "D:/WebOTX/domains/domain1/logs/webcontainer/mod_jk-22.log"
                  ↓
JkLogFile "|D:/WebOTX/WebServer22/bin/rotatelogs.exe D:/WebOTX/domains/domain1/logs/webcontainer/mod_jk-22.log 86400"

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

詳細および、その他の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 1台のサーバで複数のWebコンテナを起動するには、どうすれば良いのでしょうか?

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

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

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

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

2.7. 注意事項

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

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

2.7.2. Tomcatとの差異

表2.7.2-1
機能比較
■YES、□NO
Tomcat6.x WebOTX V8.4 Tomcat7.x WebOTX V9.4
仕様        
Java Servlet 2.5 2.5 3.0 3.0
JavaServer Pages 2.1 2.1 2.2 2.2
JSF - 1.2 - 2.1/2.2
JSTL - 1.2 - 1.2
Java EE 6 対応(*:Java EE 5) ■*
WebSocket - - 1.1 (Tomcat 7.0.56より) 1.1
パフォーマンス/チューニング        
リクエスト処理スレッドの動的制御
スケーラビリティ        
ハードウェアを使用した負荷分散
ソフトウェアを使用した負荷分散
セッションのレプリケーション ■(file, database, TCP) ■(JNDI, database) ■(file, database, TCP) ■(JNDI, database)
仮想ホストのサポート
アドバンスドモードのサポート
セキュリティ        
SSL(通信)
SSL(証明書の管理と運用)
認証
- BASIC認証
- フォームベース
- クライアント証明書
- DIGEST認証
ログ        
ローテーション ■(サイズ、時間、個数を指定可能) ■(log4j を採用しているので柔軟なカスタマイズが可能) ■(サイズ、時間、個数を指定可能) ■(log4j を採用しているので柔軟なカスタマイズが可能)
HTTPのログ採取 ■(アクセスログにて細かく指定可能) ■(アクセスログにて細かく指定可能)
Webアプリケーションの実行        
クラスローダの優先順位変更
外部Webサーバ連携時のコンテキスト動的反映 ■(ON/OFF/一回のみ実行を指定可能) ■(ON/OFF/一回のみ実行を指定可能)
国際化        
リクエストデータの文字エンコーディング
- ServletRequest.setCharacterEncoding()
レスポンスデータの文字エンコーディング
- ServletResponse.setContentType()
- JSPでの pageディレクティブ(contentType)
JSPの文字エンコーディング
- pageディレクティブ(pageEncoding)
運用管理(コンテナ)        
初期設定ツール
外部Webサーバとの連携設定 □(手動で設定) □(手動で設定)
リモートからの起動/停止
運用管理(Webアプリケーション)        
配備/配備解除/起動/停止などの運用
- ツールによる配備/配備解除
- コマンドによる配備/配備解除
- autodeploy
アクセス中クライアントの情報表示
任意のコンテキストで配備 ■(独自の配備記述子で指定) ■(独自の配備記述子で指定)

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

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

表2.7.3-1
Tomcat 6.x Tomcat 7.x WebOTX V5.x WebOTX V6.x WebOTX V7.x WebOTX V8.x WebOTX V9.x
HTTP/1.1 8080 8080 8080 80 80 80 80
AJP/1.3 8009 8009 8009 8009 8009 8099 8099
運用管理コンソール 8080 8080 8080 4848 4848 5858 5858
HTTPS 8443 8443 8443 443 443 443 443
終了待ち受けポート 8005 8005 8005 - - - -
IIOPリスナ(アドバンスドモード使用時) - - - 5151 5151 5151 5151
運用管理ポート - - - 6202,6212 6202,6212 6202,6212 6202,6212