WebOTX Manual V10.1 (第7版) 目次を表示

---

1. はじめに

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

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

2. ソフトウェア条件

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

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

詳細については、以下のインストールガイドをご覧ください。

• [インストールガイド > Windows]
• [インストールガイド > Linux]
• [インストールガイド > HP-UX]

2.1. 同梱するライブラリ

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

*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.*" のように指定することで、使用するパッケージへのアクセス権のみを付与することも可能です。
その場合は、使用する機能に合わせてパッケージ名を指定した権限を追加してください。

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

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

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

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

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

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

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

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

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

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

3. 移行作業

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

3.1. ディレクトリ構成

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

WebOTXインストールディレクトリ
  └─domains
      ├─admin (管理ドメイン)
      └─domain1 (ユーザドメイン)
          ├─applications
          ├─autodeploy
          ├─backup
          ├─bin
          ├─config
          │      domain.xml (ドメインの構成情報ファイル)
          │      log4j2-as.xml (Log4j定義ファイル)
          │      server.policy (ポリシーファイル)
          │
          ├─docroot (Webサーバ用ドキュメントルート)
          ├─generated (JSPファイルをコンパイルしたファイル等の格納先)
          ├─jmq
          ├─lib
          ├─logs (ログ出力先)
          ├─osgi-cache
          ├─session-store
          └─stats

3.2. 移行作業一覧

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

3.2.1. パッケージの設定

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

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

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

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

3.2.3. log4jの設定

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

3.2.4. nec-web.xmlの設定

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

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

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

3.2.6. Tomcatの差異による対応

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

3.2.7. JavaVMオプションの設定

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

3.3. パッケージの設定

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

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

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

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

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

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

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

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

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

設定内容の詳細や運用機能の詳細は、WebOTXマニュアルの中の [ リファレンス > コマンド > 運用管理コマンド(otxadmin) ]、 [ リファレンス > 設定 > Webコンテナ > Webコンテナ設定項目一覧 ] をご参照ください。

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マニュアルの [ リファレンス > コマンド > 運用管理コマンド(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 要素として記述する必要があります。resource-ref の設定を参照してください。

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"部分は環境に合わせて変更してください。

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

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

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

3.5. log4jの設定

WebOTX V5では、Webアプリケーション毎にログ出力方法を制御する場合は、各Webアプリケーションの WEB-INF/classes 以下に log4j.properties または 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 を利用することが可能です。

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

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

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

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に指定する方法は、 [ アプリケーション開発 > Webアプリケーション > プログラミング・開発ガイド > Webアプリケーションのデプロイ> web.xmlデプロイメント記述子 ] の、[nec-web.xmlファイルの要素] をご覧ください。

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ファイルを作成して配備

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

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

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"に"validOverridableJavaxPackages"を追加します。（V9 の"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="validOverridableJavaxPackages" 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="validOverridableJavaxPackages" value="javax,sun,org"/>
  </class-loader>
</nec-web-app>

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

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

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 を指定した場合、[ 利用する場合に設定が必要なパッケージ ]にあるパッケージのうち "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>

…

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>

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

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>

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

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

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

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

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」と記録されているものを確認し、セキュリティポリシーの追加を行ってください。

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";
    ：省略
};

3.8. Tomcatの差異による対応

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

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

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

3.8.1. Tomcat 5.0と Tomcat 5.5の差異

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

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

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

3.8.2. Tomcat 5.5と Tomcat 6.0の差異

InvokerServletが機能しない

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

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

【設定手順】

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

3.8.3. Tomcat 6.0と Tomcat 7.0の差異

emptySessionPathの設定

Tomcat7では、emptySessionPathの設定が廃止され、sessionCookiePath="/" の設定により同等の動作をします。
WebOTXでは、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宣言を付ける

設定方法の詳細については、[リファレンス > 設定 > 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"が有効でした。

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

<jsp:text>タグ内へのサブエレメント記述禁止

Tomcat 7.0.43 より<jsp:text>タグの仕様通りタグ内にサブエレメントを記述することができなくなりました。記述するとJSPのコンパイルエラーが発生するようになります。

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

    :
<jsp:text>
    :
　<c:out value="${name}"/>
    :
</jsp:text>

Webアプリケーションの修正が必要になります。

3.8.4. Tomcat 7.0と Tomcat 8.5の差異

リクエストパラメータデコード時の文字エンコード

Tomcat8.5ではフォワード先のサーブレットでリクエストパラメータ取得する際、デコードに使用する既定の文字エンコードがISO-8859-1からUTF-8に変更されています。 そのため、次のような処理を行っている場合、文字化けが発生します。

• HttpServletRequest#setCharacterEncoding()で文字エンコードを指定していない。
• フォワード先のサーブレットからHttpServletRequest#getParameter()等でリクエストパラメータを取得している。
• 取得した文字列をISO-8859-1から他の文字エンコードで再変換している。(*1)

(*1) 再変換の例

        String temp = request.getParameter("hoho");
        String param = new String(temp.getBytes("ISO-8859-1"), "UTF-8");

WebOTX V10も、合わせて既定文字エンコードがUTF-8になっています。文字化けを回避するにはHttpServletRequest#setCharacterEncoding()を実施するサーブレットフィルターをアプリケーションに追加設定し、文字化けを回避してください。フィルターのURLパターンにはリクエスト中最初にHttpServletRequest#getParameter()が行われる処理を設定します。

web.xmlへのサーブレットフィルターの設定例

<web-app>
        :
    <filter>
        <filter-name>Set Character Encoding</filter-name>
        <filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class>
        <init-param>
            <param-name>encoding</param-name>
            <param-value>ISO-8859-1</param-value>
        </init-param>
        <init-param>
            >param-name>ignore</param-name>
            >param-value>true</param-value>
        </init-param>
    </filter>
    <filter-mapping>
        <filter-name>Set Character Encoding</filter-name>
        <url-pattern>/hoho.jsp</url-pattern>
    </filter-mapping>
        :
</web-app>

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

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

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

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

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

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

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

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

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

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

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

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

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

3.10. WebOTX V8とV9の差異

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

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

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

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

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

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

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

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)

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)

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

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

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

3.10.9. cross-contextの既定値

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

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を指定します。

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

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

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>←追加

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

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

3.10.15. クライアントへの書込みタイムアウト設定

内蔵Webサーバ(V8はbioコネクタ、V9はgrizzlyコネクタ)を使用している場合、クライアントへの書込みタイムアウト(*1)値の設定箇所が異なります。

(*1) タイムアウトの例)
　　　　Windowsでファイルをダウンロードする際、ファイルの保存場所を指定するダイアログを開いたまま放置し、
　　　　いざダウンロードを開始した時、ダイアログを開いてから一定時間が経過していると、書込みタイムアウトが発生し、
　　　　ダウンロードは失敗、頭のデータしか無いファイルが出来上がる。

書込みタイムアウトの時間を変更するには次の値を更新します。単位はそれぞれミリ秒です。
V8:bioコネクタを使用してる場合
　　server.http-service.http-listener.http-listener-1.connection-timeout
V9:内蔵Webサーバ(grizzlyコネクタ)を使用している場合
　　-Dcom.nec.webotx.grizzly.writeTimeout
　　　※JVMオプションを設定します。既定値は30000(ミリ秒)で、設定値の３倍の値(90秒)でタイムアウトします。
V9:内蔵Webサーバ(grizzlyコネクタ以外)を使用している場合
　　server.network-config.protocols.protocol.http-listener.http.connection-timeout

3.11. WebOTX V9とV10の差異

3.11.1. Webコンテナの動作モード廃止

ドメイン作成時に選択が必要であったWebコンテナの動作モード「スタンダードモード」と「アドバンスドモード」は無くなりました。

V10では、配備する際にアプリケーショングループ名とプロセスグループ名を指定する事でアプリケーションはプロセスグループ上で動作します(V9における「アドバンスドモード」相当)。指定しなければエージェントプロセス上で動作します(V9における「スタンダードモード」)。

3.11.2. コネクタ種別の変更

V9では、外部Webサーバ連携用と内蔵Webサーバ用含めて「grizzly」「ajp」「nio」「bio」がありましたが、V10では、「HTTP/1.1(nio)」「HTTP/1.1(apr)」「AJP(ajp)」「AJP(tpm)」になりました。

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

V10： otxadmin> set server.network-config.protocols.protocol.＜protocol名＞.type=(ajp | tpm | nio | apr)

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

V9： otxadmin> set server.network-config.network-listeners.network-listener.ajp-listener-1.property.maxParameterCount=500
　　　　　　　　　
V10： otxadmin> set server.network-config.network-listeners.network-listener.agent-ajp-listener.property.maxParameterCount=500

3.11.4. 外部Webサーバ連携用ツールの名称と動作の変更

V9では、外部Webサーバと連携する場合に「環境設定ツール」を利用し設定を行っていました。V10では、このツールの名称が「初期設定ツール」に変更となっています。

また、V9ではIISと連携する場合に環境設定ツールで設定後、「IIS6 メタベース互換のインストール」など手動でIISの設定を行う必要がありましたが、V10では初期設定ツールが自動で行うようになりました。

3.11.5. 動的反映機能の動作の変更

V9における「動的反映機能」は、リクエスト処理の延長でドメインへの問い合わせを実施していましたが、V10では、リクエストとは別スレッドでドメインへの問い合わせを実施するようになりました。

また、動的反映機能を手動でOFF(無効)にする場合、V9では「ajp13_original」というキーワードを ${INSTANCE_ROOT}/config/WebCont/workers.properties に記述していましたが、V10ではこれが変更となりました。

3.11.6. IIOP接続の廃止

V9のアドバンスドモードにあった「IIOP」による接続は V10では無くなりました。V10でアプリケーションをプロセスグループに配備した場合、外部Webサーバとの接続は「AJP」に固定となります。

これに伴い、V9に存在した AJP と IIOP の切り替え機能も廃止となります。

3.11.7. クラスローダのオーバーライドプロパティ名称変更

アプリケーションレベルのクラスローダは、既定の設定では"javax"などで始まるパッケージをロードできません。 指定するパッケージをロードできるようにするプロパティ(あるいはJVMオプション)がありますが、 そのプロパティ名称が"overrideablejavaxpackage"と直感的に判別しにくいため、 V10では判別しやすい名称の別プロパティを追加しました。

ただし、V9に存在したプロパティ"overrideablejavaxpackage"も使用可能です。

3.11.8. Cometの移行

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

3.11.8.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();

3.11.8.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();

4. 運用管理方法

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

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

※「配備方法」において、Tomcatの「webappsディレクトリへWARファイルをコピー」と、WebOTXの「autodeployディレクトリへのファイルコピー」は、次の基本的な機能は同等ですが、それぞれのオプション機能に違いがあります。

• WARファイルを配置すればそれが展開されてアプリケーションを配備
• WARファイルを削除すれば配備解除

autodeployについては、[ 配備 > アプリケーション配備 > 配備・再配備・置換 > 配備・再配備 > オートデプロイ機能を利用した配備] を参照してください。

4.1. Webサーバとの連携

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

ドメイン作成時に外部Webサーバの使用を指定している場合はWebサーバとの連携設定は自動で行われます。
内蔵Webサーバの使用を指定してドメインを作成した環境で外部Webサーバと連携させたい場合には初期設定ツールを利用して行います。

連携するWebサーバの変更方法の詳細については、 WebOTXマニュアル [ Webコンテナと連携するWebサーバを切り替える方法 ] をご覧ください。

4.2. 運用管理コマンド

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

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

4.3. 運用管理コンソール

Webブラウザから利用できる運用管理コンソールを用意しています。 詳細は WebOTXマニュアル [ 構築・運用 > 操作方法 > 運用管理コンソール ] 、もしくは運用管理コンソールのヘルプをご覧ください。

図2.4.3-1

4.4. 配備方法

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

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

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

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ファイルの構成については以下のマニュアルを参照ください。
[ アプリケーション開発 > Webアプリケーション > チュートリアル > Webアプリケーションの作成 ]

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

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

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

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

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

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

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

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

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

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

5. Tomcat設定項目

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

5.1. Tomcat設定項目との対応

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

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

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

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

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

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

コネクタ（HTTP、AJP共通）

コネクタ（HTTP）

コンテキスト（共通）

Realm
JDBCレルムについてはWebOTX マニュアルの [ 構築・運用 > ユーザ管理 > レルムの設定 > JDBCレルム ]を参照してください。

Loader

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

JavaVMオプションでの設定項目は[ リファレンス > 設定 > Webコンテナ > Webコンテナ設定項目一覧 > JavaVMオプションで設定可能な項目一覧 ]を参照してください。

6. Q&A

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

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の詳細は[ 移行作業 > クラスロード優先順位の設定 ]を参照してください。

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

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

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

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

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

A4　フィルタはServlet2.3仕様から追加された仕組みです。WebOTX V10 では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にデコードするか、 の設定があります。
   詳細は HTTPリクエスト を参照してください。
   

2. HTTPレスポンス

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

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

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

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

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

5. ファイル入力/出力

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

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

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

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

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"でデコードされます。
   

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"でエンコード(レスポンス出力)します。
   

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を指定して特定の文字コードでエンコードするように設定すると、一部のページで文字化けが発生します。この場合は、該当のページのファイルの文字コード修正してください。

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をコンパイルした際にエラーが発生します。WebOTX V10はデフォルトでは、Java 8 (Java1.8)としてコンパイルするため、この問題が発生します。次の例のように、コンパイルする際に使用する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以降 では、servlet-mapping の定義が無いサーブレットへのアクセスはセキュリティの観点からデフォルトでは無効になっています。また、WebOTX V8からは、この機能がデフォルトで定義されていません。

WebOTX V6以降 で上記のアクセスを許可するにはアプリケーションの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>

[ 移行作業 > 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

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

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

• 構築・運用 > ログ > WebOTXのログ > 設定一覧 > WebOTX AS ログ設定一覧

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 に記述してください。

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

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

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

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

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

詳細については、WebOTXマニュアル [ 構築・運用 > チューニング > APサーバ > リソースチューニング ] をご覧ください。

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マニュアル [ 構築・運用 > チューニング > Webコンテナ > プロセッサ数 > 最大プロセッサ数 ] をご覧ください。

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

• SHILIB_PATH、LD_LIBRARY_PATH、CONFIG_PATH
  

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

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

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

※環境変数の詳細については、WebOTXマニュアル [ 構築・運用 > 環境変数・JDK・ホスト名の設定変更 > 2.1. システム環境変数 ] をご覧ください。

6.4. Webアプリケーションのリソースへのアクセス制御に関するQ&A

Q1　<security-constraint>要素でWebアプリケーションのリソースへのアクセス制御を実施していますが、特定のHTTPメソッドでは認証なしでアクセスできてしまいます。ガードする方法はありませんか？

A1　「セキュアシステム構築ガイド > WebOTXを利用する場合のセキュリティ対策の設定 > アプリケーション > 認証・アクセス制御・権限管理 > Webアプリケーションのリソースへのアクセス制御」をご覧ください。

7. 注意事項

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

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

7.2. WebOTX 旧バージョンとの対応表

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