本章では、TomcatからWebOTXに移行する際に必要となる作業について説明します。
WebOTXのドメインに関連する主要なディレクトリは次のようになっています。
Tomcatの各バージョンからWebOTXに移行するための作業と、本書での説明の対応は以下のとおりです。
| 移行作業 | Tomcat のバージョン | 本書での説明 | ||||
|---|---|---|---|---|---|---|
| 3.x | 4.x | 5.0 | 5.5 | 6.x | ||
| パッケージの設定 | △ | △ | △ | △ | △ | 2.3章 |
| JDBCデータソースの設定 | △ | △ | △ | △ | △ | 2.4章 |
| log4jの設定 | △ | △ | △ | △ | △ | 2.5章 |
| nec-web.xmlの設定 | ○ | ○ | △ | △ | △ | 2.6章 |
| セキュリティポリシーの設定 | ○ | ○ | ○ | ○ | ○ | 2.7章 |
| Tomcatの差異による対応 | × | × | × | △ | △ | 2.8章 |
| JavaVMオプションの設定 | △ | △ | △ | △ | △ | 4.2章 |
○：作業要 △：条件により作業要
既存のJSPコードにおいて、他のクラスをインポート(import)している場合にはパッケージを指定しなければなりません。これはJDK 1.4からJavacコンパイラがJava言語仕様へ厳密にチェックするように変わったことに起因します。J2SE 1.4.0より前のバージョンでは、パッケージの指定は必要ありませんでしたが、J2SE 1.4.0以降ではパッケージの指定が必要になっています。
Tomcatでは、「conf/server.xml」ファイルを直接修正することでJDBCデータソースの設定を行いますが、WebOTXでは、JMX (Java Management Extensions) に対応した運用管理コンソールや運用管理コマンドで設定します。 WebOTXでは、データベース・サーバへの接続をファクトリ化し、JNDI API経由で接続オブジェクト参照を得る仕組みとしてJDBCデータソースを提供しています。JDBCデータソースは、分散トランザクションやコネクション・プーリングなどを考慮しているため、単にJDBCドライバのインタフェースを呼び出す場合よりも機能拡張されています。
既存のWebアプリケーションにおいてJDBCデータソースを使用している場合、JDBCデータソースを利用するための設定を行う必要があります。
WebOTXは、Apache Logging Server プロジェクトの log4j のパッケージ名を変えてバンドルしており WebOTX自身のロギング機能にlog4jを利用しています。このため、既存のWebアプリケーションでlog4jを利用してログ出力している場合、WebOTX の定義を気にする事なく利用可能です。
既存のWebアプリケーションにおいて、StrutsなどのライブラリJARファイルや、WebOTX以外のCORBAライブラリをWARファイル内の「WEB-INF/lib」配下に格納している場合、また、CORBAライブラリについては、WebOTXに含まれるライブラリと重なる場合、Webアプリケーションを配備できないなどの問題が発生することがあります。Webアプリケーションを、そのままのファイル構成でご利用いただくには、nec-web.xmlでライブラリのロードに関する設定を行います。
WebOTXは、インストール・デフォルトの定義によりJavaセキュリティ・マネージャが動作します。Javaセキュリティ・マネージャが働くことで、Webアプリケーションの実行中に、システム上のファイルや他システムへの接続などの資源に対する不用意なアクセスを制限できます。このため、現行システムでセキュリティポリシーを設定していない場合は、WebOTX移行に際してはセキュリティポリシーの設定が必要となります。 また、現行システムでセキュリティポリシーを設定している場合は、既存のセキュリティポリシー設定を移行する必要があります。
Tomcatの各バージョンの差異によりWebOTXに移行する際に対応が必要となる場合があります。
WebOTXは、Tomcatと同様にJavaVMのオプション設定をサポートしています。このため、既存のTomcatシステムでJavaVMオプションの設定を行っている場合はWebOTXにも同様の設定を行う必要があります。詳細は4.2章Java VMオプションのサポートを参照ください。
JSPで他のクラスをインポート (import) している場合には、パッケージの指定が必要です。
これまでJava2 SDK 1.3.1以前を使用していた場合は、そのJavacコンパイラの構文チェックが緩かったために問題とはなりませんでした。しかし、J2SE 1.4.0からは構文チェックが厳しくなり、パッケージを持たないJSPコードは、JSPをWebOTXに配備した後に行われるJSPコンパイルでエラーとなります。なお、WebOTX V8は、JDK 5 か6 のみをサポートします。
J2SE 1.3.1以前のバージョンから移行する場合には、importのパッケージの指定を確認してください。
次のようにパッケージの指定のないimportはエラーとなります。
<%@ page import="Converter,ConverterHome" %>
importするクラスにパッケージの指定を追加して、importの指定をそれにあわせて修正してください。
本設定は、includeするファイルも含めて各ファイルで指定してください。
WebOTXのJDBCデータソースを利用するためには、WebOTX運用環境製品で提供している「統合運用管理ツール」か、標準で備わる「運用管理コマンド (otxadmin)」を利用します。ここでは、運用管理コマンドを利用する設定について説明します。
設定内容の詳細や運用機能の詳細は、WebOTXマニュアルの中の「運用管理コマンドリファレンスマニュアル」−「1. 運用管理エージェント運用管理コマンド」、「運用編（コンフィグレーション）」をご参照ください。
運用管理コマンドより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マニュアルの「運用管理コマンドリファレンスマニュアル」−「1. 運用管理エージェント運用管理コマンド」の "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
Oracleデータベース・サーバに付属するJDBCドライバ (ojdbc14.jar) が配置されたディレクトリにクラスパスを設定します。 以下はdomain1ドメインにクラスパスを設定するコマンド例です。
現状のクラスパスを確認します。
otxadmin> get server.java-config.server-classpath
※ 実際には1行で実行してください。
現状のクラスパスにJDBCドライバのクラスパスを追加設定します。
otxadmin> set server.java-config.server-classpath=…;/temp/ojdbc14.jar
※ "/temp/ojdbc14.jar"部分は環境に合わせて変更してください。
※ 実際には１行で実行してください。
※ setコマンドは指定の値で上書きしますので、既存の設定値を含めて設定してください。
設定が完了したらドメインを再起動してください。
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"
※ <APG名> にはアプリケーショングループ名が入ります。
※ 実際には1行で実行してください。
Webアプリケーションでlog4j APIを呼び出して、利用するlog4j定義ファイルを読み込む方法についての説明は、ここでは省略します。
前述の通り、WebOTX V8.1 ではログ出力に WebOTX 独自のlogging モジュールを利用しています。よって、ユーザアプリケーションでは、WEB-INF/classes 配下に定義ファイルを置くか、システムプロパティに設定するかのどちらかで log4j を利用することが可能です。
Webアプリケーションには、Servlet仕様にしたがって配備記述子 (Deployment Descriptor) と呼ばれる実行の振る舞いを宣言するXML形式の設定ファイル (web.xml) を付属させます。WebOTX V6では、その標準のServlet仕様に規定されたweb.xml要素を拡張した、nec-web.xmlを追加しています。
ライブラリのロードの設定を変更したい場合や、BASIC/FORM認証をする際のユーザ名や権限の設定を追加したい場合は、nec-web.xmlに該当する情報を設定しなければなりません。
・ 使用するレルムにユーザ名、パスワード、権限を登録します。
・ 必要に応じて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>
【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に指定する方法は、[ アプリケーション開発ガイド > 第４部 プログラミング・開発 > 1.3. 配備記述子エディタ ] をご覧ください。
${INSTANCE_ROOT}/applications/j2ee-modules/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/j2ee-module/<アプリケーション名>/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.4 配備方法」をご覧ください。
対象パッケージ名
"javax"
"sun"
"org.xml.sax"
"org.w3c.dom"
"org.apache.xerces"
"org.apache.xalan"
"org.apache.taglibs.standard"
"com.sun.faces"
【nec-web.xmlでの設定方法】
<nec-web-app>タグの"property"に"overrideablejavaxpackages"を追加します。複数設定する場合はカンマで区切って指定します。
反映させるにはWebアプリケーションを更新して、更新したアプリケーションを配備し直してください。
<?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>【運用管理コンソールでの設定方法】
JavaVMオプションに"com.nec.webotx.enterprise.overrideablejavaxpackages"の設定を行います。 詳細は4.2. JavaVMオプションのサポートを参照してください。 ※JAXB2.0を利用しているアプリケーションを動作させるためにもこの設定が必要となります。以下の例を参考に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,パッケージ名"/>
：
Tomcatは、オプションなしで起動すると、Javaセキュリティ・マネージャを使用しない定義で動作します。セキュリティ・マネージャを使用しない場合、実行時にアクセス制御を行わないため、高速に処理できます。その反面、社会インフラでの利用に求められるサーバ・セキュリティが全く働かない問題があります。
WebOTXでは、デフォルトでセキュリティ・マネージャが動作します。これにより、Webアプリケーションが不用意に資源 (OS上のファイルや他システムへの接続など) にアクセスすることを制限することができます。ただし、意図した資源へのアクセスを許可する場合には、Javaセキュリティポリシーに追加設定する必要があります。
ここでは、Webアプリケーションが必要とする資源へのアクセスを許可させる方法について説明します。
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のアクセス権とポリシーの構文については以下のサイトを参照してください。(J2SE 1.5の説明)
http://java.sun.com/j2se/1.5.0/docs/guide/security/permissions.html
http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html
事前にアクセスするディレクトリ/ファイルなどが分かっている場合には、動作させる前に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」と記録されているものを確認し、セキュリティポリシーの追加を行ってください。
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";
：省略
};
Tomcatの各バージョンの差異により、WebOTXへの移行の際に対応が必要となる場合があります。
ここでは、各バージョンの差異とその対応方法について説明します。
また、WebOTX V6、V7のベースとなっているTomcatのバージョンは5.0、V8ではTomcat 6.0がベースとなっています。よって、V7以前からV8へ移行する際にもこれらの設定が必要になります。
Tomcat 5.0以前からWebOTX V8へ移行する際にこの対応が必要になる場合があります。
Tomcat 5.0とTomcat 5.5の差異として、この値のデフォルト値が “original” → “forward” に変更されています。Tomcat 5.5以前からWebOTX V8に移行する際にこの対応が必要になる場合があります。
これはTomcat 5.5で機能していたinvokerServletの機能がTomcat 6.0ではデフォルトで動作しないようになっているため、Tomcat6.0をベースにしているWebOTX V8ではこの問題が発生します。1) Webアプリケーションのweb.xmlのinvokeServletにload-on-startupが指定されている場合は、これを削除します。
※配備時にはWebアプリケーションに特権が与えられていないため、この指定があると起動に失敗し、配備ができません。
2) Webアプリケーションの設定で特権（privileged）を与えます。
設定方法の詳細は 4.1 Tomcat設定項目との対応 をご覧ください。
3) ドメインを再起動します。
※privilegedをtrueに設定すると、Webアプリケーションが内部クラスにアクセスできるようになります。セキュリティの観点から使用には注意してください。