|
|
WebOTX Manual V12.1 (第4版) 目次を表示 |
|
|
|
WebOTX Manual V12.1 (第4版) 目次を表示 |
ここでは、旧バージョンのWebOTXから WebOTX V12 にシステムを移行する際の作業について説明します。
なお、本章の説明内容は、以前の WebOTXマニュアルでは
「リファレンス集 ドメイン構成・環境移行編」-「2.他APサーバ(Tomcat)からWebOTXへの移行ガイド」
として記載していました。
本章で対象とする移行元のAPサーバは以下のとおりです。
| 対象APサーバ | バージョン |
|---|---|
| WebOTX | 5.x |
| 6.x | |
| 7.x | |
| 8.x | |
| 9.x | |
| 10.x | |
| 11.x |
本章では、移行の流れを説明します。
旧バージョンの WebOTX から WebOTX V12に移行する場合、以下の順序で移行作業を行います。
移行元のWebOTX環境に設定した項目を確認します。
移行元環境から確認した設定をもとに、移行先環境の設定項目を設計します。
必要に応じて移行元環境と移行先環境のWebOTXの差異を確認し、アプリケーションソースに反映します。詳細は[ アプリケーションの準備 ]にて説明します。
移行先の環境にWebOTX Application Serverをインストールします。
設計した設定情報とアプリケーションを移行先の環境に反映します。
設定情報の確認(手順1)は移行元の環境で、APサーバのインストール(手順4)と設定情報の反映(手順5)は移行先の環境で行います。その他の作業については、任意の環境で行います。
設定情報の設計(手順2)や設定情報の反映(手順5)では、以下の点を考慮して作業を行う必要があります。
WebOTXの各バージョンと上記の対応は以下の通りです。
| 移行作業 | WebOTX のバージョン | 本章での説明 | |||||||
|---|---|---|---|---|---|---|---|---|---|
| V5.x | V6.x | V7.x | V8.1 | V8.2- V8.4 |
V9.1- V9.4 |
V10.1- V10.4 |
V11.x | ||
| JDBCデータソースの設定 | △ | △ | △ | △ | △ | △ | △ | △ | 説明 |
| セキュリティポリシーの設定 | △ | △ | △ | △ | △ | △ | △ | △ | 説明 |
| Tomcatの差異による対応 | △ | △ | △ | △ | △ | △ | △ | △ | 説明 |
| JavaVMオプションの設定 | △ | △ | △ | △ | △ | △ | △ | △ | 説明 |
○：作業要 △：条件により作業要 −：不要(対応済み)
移行元環境からアプリケーションを移行する場合、JDKやWebOTXの非互換を考慮してソースを確認し、必要に応じて修正します。
WebOTXの非互換については、[ 旧バージョンとの互換性 ]を参照ください。
そのほか、以下の点を考慮してソースの確認・修正を行う必要があります。
WebOTXの各バージョンと上記の対応は以下の通りです。
| 移行作業 | WebOTX のバージョン | 本章での説明 | |||||||
|---|---|---|---|---|---|---|---|---|---|
| V5.x | V6.x | V7.x | V8.1 | V8.2- V8.4 |
V9.1- V9.4 |
V10.1- V10.4 |
V11.x | ||
| パッケージの設定 | △ | − | − | − | − | − | − | − | 説明 |
| log4jの設定 | △ | △ | △ | △ | △ | △ | △ | △ | 説明 |
| nec-web.xmlの設定 | ○ | − | − | − | − | − | − | − | 説明 |
○：作業要 △：条件により作業要 −：不要(対応済み)
移行元環境のWebOTXに設定した項目を確認します。
移行元のWebOTXと移行先のWebOTXでは設定した項目の構成が変更となっている場合があります。[ 旧バージョンとの互換性 ]をご確認いただくとともに、移行元環境から収集した設定項目が移行先環境のどの項目に該当するかを [ 設定 ] を参照してください。
JDKやWebOTXの非互換を考慮してソースを確認し、必要に応じて修正を行います。
WebOTXの非互換については、[ 旧バージョンとの互換性 ]を参照ください。
そのほか、以下の点を考慮してソースを確認・修正を行う必要があります。
JSPで他のクラスをインポート (import) している場合には、パッケージの指定が必要です。
これまでJava2 SDK 1.3.1以前を使用していた場合は、そのJavacコンパイラの構文チェックが緩かったために問題とはなりませんでした。しかし、J2SE 1.4.0からは構文チェックが厳しくなり、パッケージを持たないJSPコードは、JSPをWebOTXに配備した後に行われるJSPコンパイルでエラーとなります。なお、WebOTX V10.2-V10.4 は、JDK 8 および JDK 11 を、V11ではJDK17を、V12ではJDK21をサポートします。
J2SE 1.3.1以前のバージョンから移行する場合には、importのパッケージの指定を確認してください。
次のようにパッケージの指定のないimportはエラーとなります。
<%@ page import="Converter,ConverterHome" %>
importするクラスにパッケージの指定を追加して、importの指定をそれにあわせて修正してください。
本設定は、includeするファイルも含めて各ファイルで指定してください。
WebOTXでは、Webアプリケーション毎にログ出力方法を制御する場合は、各Webアプリケーションの WEB-INF/classes 直下に以下の名前で設定ファイルを配置します。
そのほかに、システム全体で設定ファイルを指定する方法もあります。
【運用管理コマンドでの設定(WebOTXのドメインのconfigディレクトリに配置する例)】
・アプリケーションをエージェントプロセスに配備した場合
Log4jの場合
otxadmin> create-jvm-options "-Dlog4j.configuration=file\:///${com.nec.webotx.instanceRoot}/config/{log4j 定義ファイル名}.xml"
Log4j 2の場合
otxadmin> create-jvm-options "-Dlog4j2.configurationFile=file\:///${com.nec.webotx.instanceRoot}/config/{log4j 2定義ファイル名}.xml"
・アプリケーションをプロセスグループに配備した場合
Log4jの場合
otxadmin> add-pg-javasystem-property --apgroup <APG名> --javasystemprop log4j.configuration --value file\:///${com.nec.webotx.instanceRoot}/config/{log4j 定義ファイル名}.xml <PG名>
Log4j 2の場合
otxadmin> add-pg-javasystem-property --apgroup <APG名> --javasystemprop log4j2.configurationFile --value file\:///${com.nec.webotx.instanceRoot}/config/{log4j 2定義ファイル名}.xml <PG名>
※ <APG名> にはアプリケーショングループ名が入ります。
※ <PG名> にはプロセスグループ名が入ります。
WebアプリケーションでLog4j APIを呼び出して、利用するLog4j定義ファイルを読み込む方法についての説明は、ここでは省略します。
前述の通り、WebOTXではログ出力に 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に該当する情報を設定しなければなりません。
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に指定する方法は、 [ アプリケーション開発 > Webアプリケーション > プログラミング・開発ガイド > Webアプリケーションのデプロイ> web.xmlデプロイメント記述子 ] の、[nec-web.xmlファイルの要素] をご覧ください。
Webアプリケーションで利用するJavaのクラスを実行するためにロードを行う機能としてクラスローダがあります。
クラスローダには階層があります。上位のクラスローダでロードされたクラスからは下位のクラスローダでロードされたクラスは参照することができません。
逆に、下位のクラスローダでロードされたクラスからは、上位のクラスローダでロードされたクラスは参照することができます。
Webアプリケーションで使用するライブラリはWEB-IN/lib に配置します。複数のアプリケーションでライブラリを共有したい場合はWebOTX/libやdomain1/libに配置します
WebOTX のクラスローダの階層は次のようになります。
また、nec-web.xml のdelegate の設定により、ロードする優先順位を決定することができます。
同じ名前のライブラリがあると、競合が発生し、優先順位の高いパスに含まれるライブラリが利用されます。
ロードされるライブラリの優先順位はdelegate=true の場合は以下のようになります。delegate の設定はWebAP のWEB-INF/nec-web.xml で設定します。delegate=false の場合は以下のようになります。
nec-web.xmlファイルの格納場所およびファイルの内容は次のとおりです。
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を変更した場合は、次のいずれかの方法で配備を行ってください。
・WARファイルを作成して配備
・ディレクトリ指定で配備
配備については、[ 配備方法 ]をご覧ください。
Webアプリケーション内に配置したクラスのうちパッケージ名が以下で始まるクラスは参照することができません。この仕様はServlet仕様での勧告（javaxなどのJ2SE、J2EEクラスをWAR内のライブラリでオーバライドさせるべきではない）に基づくものです。詳細はServlet
2.4の9.7.2節を参照してください。
それにより、WEB-INF/lib配下のこれらのファイルを読み込む場合は以下の設定が必要になります。
対象パッケージ名
"jakarta"
"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オプションで設定可能な項目一覧] を参照してください。
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 を指定した場合、[ 利用する場合に設定が必要なパッケージ ]にあるパッケージのうち "jakarta.faces", "com.sun.faces" は自動で設定されるため、明示的に設定する必要はありません。
※アプリケーションで特定の <listener> を先に読み込ませる必要がある場合、
先に読み込ませたいリスナの定義を web.xml のリスナ定義の最初に追加してください。
例として、glassfish の JSF 実装のメソッド jakarta.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> …
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ドキュメントの取得に失敗する場合があることについて
]の現象を回避することができることがあります。
アプリケーションからJDBCデータソースをルックアップする際に、引数として"java:comp/env/"から始まる文字列(環境ネーミングコンテキスト名)を用いている場合、 環境ネーミングコンテキスト名と[ 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>
移行先の環境に WebOTX Application Server をインストールします。
具体的なインストール手順については詳細は、各インストールガイド（ Windows ／Linux ）を参照してください。
設計した設定情報とアプリケーションを移行先の環境に反映します。
主な設定の反映方法は以下の通りです。アプリケーションの配備については、[ Webアプリケーションのデプロイ ]をご覧ください。
WebOTXのJDBCデータソースを利用するためには、WebOTX運用環境製品で提供している「統合運用管理ツール」か、標準で備わる「運用管理コマンド (otxadmin)」を利用します。ここでは、運用管理コマンドを利用する設定について説明します。
設定内容の詳細や運用機能の詳細は、WebOTXマニュアルの中の [ リファレンス > コマンド > 運用管理コマンド(otxadmin) ]、 [ リファレンス > 設定 > Webコンテナ > Webコンテナ設定項目一覧 ] をご参照ください。
運用管理コマンドより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
※ 各引数の詳細は、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 の設定 ]を参照してください。
Oracleデータベース・サーバに付属するJDBCドライバ (ojdbc6.jarやojdbc8.jar) が配置されたディレクトリにクラスパスを設定します。 以下はdomain1ドメインにクラスパスを設定するコマンド例です。
現状のクラスパスを確認します。
otxadmin> get server.java-config.server-classpath
現状のクラスパスにJDBCドライバのクラスパスを追加設定します。
otxadmin> set server.java-config.server-classpath=…;/temp/ojdbc8.jar
※ "/temp/ojdbc8.jar"部分は環境に合わせて変更してください。
※ setコマンドは指定の値で上書きしますので、既存の設定値を含めて設定してください。
設定が完了したらドメインを再起動してください。
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のアクセス権とポリシーの構文については以下のサイトを参照してください。(Java SE 8の説明)
Permissions in the Java Development Kit (JDK)
Default Policy Implementation and Policy File Syntax
事前にアクセスするディレクトリ/ファイルなどが分かっている場合には、動作させる前に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:
設定後、ドメインを再起動してください。詳細な情報が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、V9ではTomcat7.0、V10ではTomcat8.5、V11ではTomcat9.0、V12ではTomcat10.1がベースとなっています。よって、V11以前からV12へ移行する際にもこれらの設定が必要になります。
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の変更に合わせているため、対応が必要な場合は設定を行ってください。
設定方法の詳細は [ Tomcat設定項目との対応 ]をご覧ください。
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) 次の方法で設定を追加します。
3) ドメインを再起動します。
[ Q&A > 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
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コンテナ > Webコンテナ設定項目一覧 > 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"が有効でした。
<jsp:text>タグ内へのサブエレメント記述禁止
Tomcat 7.0.43 より<jsp:text>タグの仕様通りタグ内にサブエレメントを記述することができなくなりました。記述するとJSPのコンパイルエラーが発生するようになります。
【エラーとなるタグ記述の例】
:
<jsp:text>
:
<c:out value="${name}"/>
:
</jsp:text>
Webアプリケーションの修正が必要になります。
リクエストパラメータデコード時の文字エンコード
Tomcat8.5ではフォワード先のサーブレットでリクエストパラメータ取得する際、デコードに使用する既定の文字エンコードがISO-8859-1からUTF-8に変更されています。
そのため、次のような処理を行っている場合、文字化けが発生します。
(*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>
レスポンスヘッダに"Server"ヘッダが含まれない
WebOTX AS V10では、ベースとしているTomcat 8.5 の変更に伴い、レスポンスヘッダに"Server"ヘッダを含まないようにしています。
レスポンスヘッダに"Server"ヘッダを含むようにする場合はWebOTX AS Webコンテナの内蔵Webサーバで設定が必要です。
詳細は以下を参照してください。
[
リファレンス
> 設定
> Webコンテナ
> Webコンテナ設定項目一覧
> MOで設定可能な項目一覧
> Dottedname : server.network-config.protocols.protocol.<プロトコル名>.http.property
> server]
Webコンテナ外部のWebサーバ(IIS/WebOTX Webサーバ等)の場合は外部のWebサーバがServerヘッダを設定します。
WebOTXはJavaVMのオプション設定をサポートしています。このため、既存のシステムでJavaVMオプションの設定を行っている場合は同様の設定を行う必要があります。詳細は Java VMオプションのサポートを参照ください。
WebOTXが動作保証するJDK(J2SE SDK) JDK(J2SE SDK)を変更する場合、WebアプリケーションやWebアプリケーションが依存するライブラリが、特定のJDK(J2SE SDKに依存しないか動作確認を行ってください。
移行先環境が WebOTX Application Server Express の場合、WebOTX V9.1以降には同時処理数が100までという緒元制限が存在します。移行後の環境において同時処理数が100を超える場合、同時処理数を100以下に設定してください。諸元制限についての詳細は[インストールガイド(Windows)]または[インストールガイド(Linux)]を参照してください。
[同時処理数の設定箇所]
リファレンス > 設定 > Webコンテナ > Webコンテナ設定項目一覧 > MOで設定可能な項目一覧 > max-thread-pool-size
詳細については [ 注意制限事項 > 機能ごとの注意制限事項 > マイグレーション > 注意事項 > 配備 > アプリケーション名の規約に違反するアプリケーション ]を参照してください。
詳細については [ 注意制限事項 > 機能ごとの注意制限事項 > マイグレーション > 注意事項 > WebOTX Webサーバ > WebOTX Webサーバ 2.xからの移行 ]を参照してください。