1.4. Webコンテナ

Webコンテナに関する設定について説明します。

1.4.1. Webコンテナ設定項目・設定方法

Webコンテナの設定項目の設定方法については次の2通りがあります。

Web版統合管理コンソールによる設定

Web版統合運用管理コンソールでは各種情報の設定ができます。なおWeb版統合運用管理コンソールの使い方と詳細については、「運用ツールガイド > 1. Web版統合運用管理コンソール」を参照してください。

MOによる参照と設定

Web版統合運用管理コンソールで設定できる項目は、JMXのMOとしてもアクセス可能です。項目の設定方法については「1.1. 各サービスの属性」を参照してください。

1.4.2. Webコンテナ設定項目一覧

1.4.2.1. MOで設定可能な項目一覧

Dottedname : server.web-container

Dottedname : server.web-container.property

otxadmin> set  server.web-container.property.j2ee-enabled=true

otxadmin> set  server.web-
container.property.forwardRequestURL=forward

otxadmin> set  server.web-
container.property.auth_all_changeSessionIdOnAuthentication=true

Dottedname : server.web-container.plugin-config

Dottedname : server.web-container.current-version-config.current-version.context-root-name

otxadmin> set
server.web-container.current-version-config.current-version./sample.version=02

Dottedname : server.http-service

otxadmin> set
server.http-service.property.sso-enabled=false

Dottedname : server.http-service.access-log

otxadmin> set server.http-service.access-log.format="%a -
%u %t %m %U %q %H %s %b %D"

Dottedname : server.http-service.virtual-server.virtual-server-name

Dottedname : server.http-service.virtual-server.virtual-server-name.property

otxadmin> set  server.http-service.virtual-
server.server.property.allowLinking=true

valve_=org.apache.catalina.valves.RequestDispatchTestValve

server.http-service.virtual-server.virtual-server-
name.docroot

Dottedname : server.network-config.network-listeners.network-listener.network-listener-name

　　Dottedname : server.http-service.http-listener.http-listener-name 旧名（非互換です）

WebOTX V9よりHTTPリスナの設定を変更しています。設定はtransport、protocol、thread-poolに分散して行い、それぞれを選択することでHTTPリスナを定義します。 HTTPリスナに使用される通信コネクタにはgrizzly、ajp、bio、nioを指定できます。また種類の異なるHTTPコネクタを混在させて使用することが可能です。

　　Dottedname : server.network-config.transports.transport.transport-name

　　Dottedname : server.network-config.protocols.protocol.protocol-name.http

　　Dottedname : server.thread-pools.thread-pool.thread-pool-name

otxadmin> set server.network-config.network-listeners.
network-listener.admin-listener.enabled=false

Dottedname : server.network-config.transports.transport.transport-name

Dottedname : server.network-config.protocols.protocol.protocol-name

Dottedname : server.network-config.protocols.protocol.protocol-name.http

otxadmin> set server.network-
config.protocols.protocol.http-listener.http.max-
post-size-bytes=4194304

otxadmin> set server.network-config.protocols.protocol.http-listener.http.header-buffer-length-bytes=4096

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

Dottedname : server.network-config.protocols.protocol.protocol-name.http.property

otxadmin> set server.network-config.protocols.
protocol.http-listener.http.property.maxParameterCount=2000

Dottedname : server.thread-pools.thread-pool.thread-pool-name

備考.sendRedirect実行時の宛先URLについて
下図のようにリクエスト経路に負荷分散装置(SSLアクセラレータ)を配置して、httpsをhttpに変換している場合は、クライアントの宛先URLとsendRedirect時のURLが異なりエラーが発生します。このような場合、プロパティを設定(scheme、proxy-port、proxy-name)し宛先URLを変更することで、正常にアクセスできるようになります。

図1.4.2.1-1

*1) アドバンスドモードでアクセスログを採取するには accessLoggingEnabled プロパティの代わりに <domain>/config/tpsystem/logconf/<apg>-<pg>/log4otx.xml を開き name="server" の logger のログレベルを DEBUG に変更します。

注）アドバンスドモードではアクセスログのフォーマットを変更することはできません。また、この設定を行うと性能に影響があります。特に必要のない限り、本番等での使用はお控ください。

*2) アドバンスドモードにおいては、これらの項目はプロセスグループの設定項目となります。 「1.4.5.2.IIOPプラグインの設定項目一覧」を参照してください。

*3) アドバンスドモードにおいては、これらの項目は、HTTPリスナ"ajp-listener-1"に対して設定することで利用できます。 また、一部の項目は、旧バージョンと同様にシステムプロパティでも設定することが可能です。「1.4.2.3. JavaVMオプションで設定可能な項目一覧」を参照してください。

*4) アドバンスドモードでは連携する Webサーバ側で設定してください。参考：mod_deflate - Apache 2.2

Dottedname : server.network-config.protocols.protocol.protocol-name.ssl

Dottedname : server.system-applications.application.web-module-name

　　Dottedname :server.applications.web-module.web-module-name　旧名（非互換です）

Dottedname : server.applications.web-module.web-module-name.module.web-module-name.engine.web.web-module-config

*5) コンテキストパスに "/" を含めると一部機能が利用できなくなります。詳しくは [ 注意制限事項 > 3. Webコンテナ > 3.1. 注意事項] を参照してください。

Dottedname : server.session-config.session-manager.manager-properties

*6) セッション情報を格納先に保存し、メモリ上から削除する処理

Dottedname : server.session-config.session-manager.manager-properties.property

Dottedname : server.session-config.session-manager.store-properties

1.4.2.2. プロセスグループ(アドバンスドモードのみ)の環境変数で設定可能な項目一覧

プロセスグループの環境変数は、Web版統合運用管理コンソールや統合運用管理ツールのプロセスグループの「環境変数」タブで設定する事ができます。

1.4.2.3. JavaVMオプションで設定可能な項目一覧

WebOTXは、Servlet/JSPコンテナにさまざまな機能があり、それらの機能の制御を行えるJava VM オプションを説明します。

下記に動作モード（スタンダードモード/アドバンスドモード）別の設定方法を記載します。

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

・運用管理コンソールでの設定方法（推奨）

運用管理コンソールにログインし、下記の箇所に設定を記述した後、ドメインを再起動してください。
<ドメイン名>
　-「アプリケーションサーバ」
　　-「JVM構成」
の順にクリックしていき、「属性」タブの「JVMオプション」の「システムJVMオプション」の欄に”-D”の後に続いて設定を記述してください。その後、ドメインを再起動することで反映されます。

設定例：

・domain.xml直接編集での設定方法

ドメインを停止し、下記の例のように対象ファイルの<java-config>要素に<system-jvm-options>タグを記述した後"-D"の後に続いて設定を記述してください。その後、ドメインを起動することで設定が反映されます。

設定例：<WebOTXインストールディレクトリ>/domains/domain1/config/domain.xml

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

・運用管理コンソールでの設定方法

運用管理コンソールにログインし、下記の箇所に設定を記述した後、TPシステムを再起動してください。
<ドメイン名>
　-「TPシステム」
　　-「アプリケーショングループ」
　　　-「<アプリケーショングループ名>」
　　　　-「プロセスグループ」
　　　　　-「<プロセスグループ名>」
の順にクリックしていき、「属性」タブの「Javaシステムプロパティ」の欄に設定を記述してください。
「名前」に項目名を記述し、「値」に指定する値を記述してください

設定例：

設定項目一覧

1.4.3. HTTPのみのセッションレプリケーション

WebOTX V7.1より、HTTPのみセッションレプリケーションを利用できるようになりました。　従来、レプリケーションを行うとJDBCデータソース、JMSリソースも同じ内容となってしまい、ドメインごとに異なる設定内容にできませんでした。 これにより、複数のWebコンテナおよびEJBコンテナそれぞれにHTTPセッションの共有が容易にできるようになります。

HTTPのみセッションレプリケーションを利用するには、session-replication-jndi-url に、つぎのように設定します。

  rmiiiop://<ホスト1>:<JNDIサーバポート1>,<ホスト2>:<JNDIサーバポート2>…

ホスト名にはレプリケーションさせるJNDIサーバが動作しているホスト名またはIPアドレスを記述します。

JNDI サーバポート番号はJNDI サーバが動作しているWebOTX ドメインの組み込みIIOP リスナのポート番号となります。インストール時に作成されるdomain1のポート番号は7780 です。省略したときは自ドメインの組み込みIIOP リスナのポート番号が使用されます。

複数のWebOTXドメイン間でHTTPセッションをレプリケートするときはレプリケートする全てのWebOTXドメインのJNDIサーバのホスト名、ポート番号を列挙した指定を各WebOTXドメインに対して設定します。列挙する順番は意識する必要はありません。

例えば二つのWebOTXドメインdomain1とdomain2でHTTPセッションレプリケーションを行うためには

  host1: domain1のホスト名

  port1: domain1の組み込みIIOP リスナのポート番号

  host2: domain2のホスト名

  port2: domain2の組み込みIIOP リスナのポート番号

のように設定されている場合、

  rmiiiop://host1:port1,host2:port2

をdomain1とdomain2のsession-replication-jndi-url 属性に設定します。

1.4.3.1. HTTPのみのセッションレプリケーションの設定方法

運用手順

(1) 運用管理コマンドによる設定

次の運用管理コマンドで設定します。

otxadmin> set server.web-container.session-replication-jndi-url=rmiiiop://<ホスト1>:<JNDIサーバポート1>,<ホスト2>:<JNDIサーバポート2>…

<例>

otxadmin> set server.web-container.session-replication-jndi-url=rmiiiop://host1:7780,host2:7780

(2) 設定の反映

ドメインを再起動して、設定を反映します。

1.4.4. Webサーバプラグイン定義ファイルの設定方法

Webサーバプラグインに関する設定について説明します。

1.4.4.1. 動的反映しない設定方法

WebOTXには、Webアプリケーションが配備されたことを自動的にWebOTX Web Server（Apache）などの外部Webサーバに反映させる仕組みがあり、デフォルトではこの機能が有効になっています。　この機能により、ドメインを再起動することなく新規に配備されたWebアプリケーションの存在を外部Webサーバに認識させています。　動的反映の処理には、ある程度負荷がかかるため、Webアプリケーションの更新のないシステムでは不要な負荷がかかることになります。そこで、この動的反映をしない設定をすることによって負荷を低減することができます。

Caution
この設定を行った場合、新規に配備されたWebアプリケーションを外部Webサーバに認識させるには、外部Webサーバおよびドメインを再起動する必要があります。

Caution
環境設定ツールで設定を行うと、以下の設定は初期化されデフォルトの「動的反映を行う」状態になります。環境設定を行った場合は、再度、下記の設定を行ってください。

A: Web版統合運用管理コンソールを利用した設定手順

動的反映しない設定をWeb版統合運用管理コンソールから行うことができます。その他の項目についてのWeb版統合運用管理コンソールを使用した設定方法については「1.4.6. Web版統合運用管理コンソールを利用したプラグインの設定方法」を参照してください。

1. Web版統合運用管理コンソールへの接続

   Webブラウザを起動し、連携設定を行ったドメインのWeb版統合運用管理コンソールへ接続します。"http://<host>:<port>/manager/"に接続してください。
   ※domain1のポート番号の既定値は 5858 です。

2. 設定の変更

   管理コンソールの左側のツリーで「アプリケーションサーバ」-「Webコンテナ」-「Webサーバ連携設定」を選択します。
   「一般」タブにある「プラグインの動的反映オプション」で「Off」を選択し、「更新」ボタンで設定を反映してください。

3. Webサーバの再起動

   以上で設定は完了です。Webサーバを再起動してください。

B: 手動での設定手順

WebサーバとWebコンテナが別マシン構成で、Web版統合運用管理コンソールを利用した設定手順が行えない場合は、以下の手順で手動設定を行ってください。

1. 外部Webサーバの停止
2. workers.propertiesの設定
   

   ${INSTANCE_ROOT}/config/WebCont/workers.propertiesに次の名称でワーカ名を追加してください。

   ajp13_original

   [workers.propertiesの例]

   #------ DEFAULT worker list ------------------------------------------ #--------------------------------------------------------------------- ps=/ # # The workers that your plugins should create and work with # worker.list=ajp13, ajp13_original # #------ DEFAULT ajp13 WORKER DEFINITION ------------------------------ #--------------------------------------------------------------------- # # # Defining a worker named ajp13 and of type ajp13 # Note that the name and the type do not have to match. # # TM_PLUGIN_PORT-start worker.ajp13.port=8099 # TM_PLUGIN_PORT-end worker.ajp13.host=localhost worker.ajp13.type=ajp13 worker.ajp13.connection_pool_size=150

   
   
   
3. 外部Webサーバの起動
   

   外部Webサーバを起動し、設定内容を反映します。

1.4.4.2. Webサーバ起動後一度のみ動的反映する設定方法

ここではWebアプリケーションが配備されたことを外部Webサーバ起動後に一度だけ自動的にWebOTX Webサーバ（Apache）などの外部Webサーバに反映させる設定方法について説明します。

WebOTX Webサーバ（Apache）、またはIISを使用している場合は、起動後の初回リクエスト時にのみ動的反映を行います。

一度動的反映を行った以降は外部Webサーバを再起動するまで動的反映は行われません。

※環境設定ツールで設定を行うと、以下の設定は初期化されデフォルトの「動的反映を行う」状態になります。環境設定を行った場合は、再度、下記の設定を行ってください。

A: Web版統合運用管理コンソールを利用した設定手順

Webサーバ起動後一度のみ動的反映する設定をWeb版統合運用管理コンソールから行うことができます。その他の項目についてのWeb版統合運用管理コンソールを使用した設定方法については「1.4.6. Web版統合運用管理コンソールを利用したプラグインの設定方法」を参照してください。

1. Web版統合運用管理コンソールへの接続

   Webブラウザを起動し、連携設定を行ったドメインのWeb版統合運用管理コンソールへ接続します。"http://<host>:<port>/manager/"に接続してください。
   ※domain1のポート番号の既定値は 5858 です。

2. 設定の変更

   管理コンソールの左側のツリーで「アプリケーションサーバ」-「Webコンテナ」-「Webサーバ連携設定」を選択します。
   「一般」タブにある「プラグインの動的反映オプション」で「Once」を選択し、「更新」ボタンで設定を反映してください。

3. Webサーバの再起動

   以上で設定は完了です。Webサーバを再起動してください。

B: 手動での設定手順

WebサーバとWebコンテナが別マシン構成で、Web版統合運用管理コンソールを利用した設定手順が行えない場合は、以下の手順で手動設定を行ってください。

1. 外部Webサーバの停止
2. workers.propertiesの設定

   ${INSTANCE_ROOT}/config/WebCont/workers.propertiesに次の名称でワーカ名を追加してください。

   ajp13_queryonce

   [workers.propertiesの例]

   #------ DEFAULT worker list ------------------------------------------ #--------------------------------------------------------------------- ps=/ # # The workers that your plugins should create and work with # worker.list=ajp13, ajp13_queryonce # #------ DEFAULT ajp13 WORKER DEFINITION ------------------------------ #--------------------------------------------------------------------- # # # Defining a worker named ajp13 and of type ajp13 # Note that the name and the type do not have to match. # # TM_PLUGIN_PORT-start worker.ajp13.port=8099 # TM_PLUGIN_PORT-end worker.ajp13.host=localhost worker.ajp13.type=ajp13 worker.ajp13.connection_pool_size=150

   
   
   
3. 外部Webサーバの起動
   

   外部Webサーバを起動し、設定内容を反映します。

1.4.4.3. Webサーバプラグイン設定項目一覧

以下はWebサーバプラグイン(スタンダードモードまたはAJPリスナ利用時)、IIOPプラグイン(IIOPリスナ利用時)共通の設定項目一覧です。

Caution
IIOPプラグインでは、負荷分散をサポートしていません。
また、アドバンスドモードでWebコンテナとWebサーバの連携モードに"ajp"を選択している場合、JKプラグインの負荷分散機能を使用することができますが、分散対象のワーカ単位でWebアプリケーションの構成は同じであることが前提となります。また、Webアプリケーションをセッションレプリケーションする場合も同様です。

対象ワーカタイプは次のとおりです。

Webサーバプラグイン：
AJP・・・"type"の値が"ajp13"であるワーカ名。負荷分散でない時に設定されているワーカ名
LB・・・"type"の値が"lb"であるワーカ名。負荷分散時の管理親ワーカ
SUB・・・"type"の値が"ajp13"であるワーカ名。負荷分散時の子ワーカ

IIOPプラグイン：
IIOP・・・"type"の値が"otxiiop"であるワーカ名。
ALL・・・IIOPプラグインの設定をワーカに反映させるための特別な記述子

連携設定項目：workers.properties（Webサーバプラグイン）、ior_workers.properties（IIOPプラグイン）

連携設定項目：mod_jk-22.conf-auto（Webサーバプラグイン）、mod_jk-24.conf-auto(Webサーバプラグイン)、mod_jk_om-22.conf-auto（IIOPプラグイン）、mod_jk_om-24.conf-auto(IIOPプラグイン)
※ドメインを再起動すると、mod_jk-22.conf-auto、mod_jk-24.conf-auto、mod_jk_om-22.conf-auto、mod_jk_om-24.conf-autoファイルは更新されます。

連携設定項目：isapi_redirect.properties

1.4.4.4. バーチャルホストごとにコンテキスト名を設定する方法

WebOTX Webサーバ（Apache）ではバーチャルホストを複数作成することができ、バーチャルホストごとにコンテキスト名の設定を行うことができます。

設定方法

1. WebOTX Webサーバ（Apache）のバーチャルホストの作成

   下記のURLを参照してバーチャルホストを作成してください。
   

   http://httpd.apache.org/docs/2.2/vhosts/

2. 設定

   ${INSTANCE_ROOT}/config/WebCont/mod_jk-**.conf-auto の JkMountCopy の設定を Off にする。

3. バーチャルホストごとのコンテキスト設定

   ${INSTANCE_ROOT}/config/WebServer/httpd.conf の <VirtualHost> 要素内に JkMount(またはJkUnMount)の設定を行う。

   例えばバーチャルホストA、Bを作成し、バーチャルホストAには /aaa というコンテキスト名を、バーチャルホストBには /bbb というコンテキスト名を設定する場合は ${INSTANCE_ROOT}/config/WebServer/httpd.conf に以下のように設定します。

   • バーチャルホストA

     <VirtualHost *:80>
     　JkMount "/aaa" ajp13
     　JkMount "/aaa/*" ajp13
     　･･･
     　</VirtualHost>

   • バーチャルホストB

     <VirtualHost *:8080>
     　JkMount "/bbb" ajp13
     　JkMount "/bbb/*" ajp13
     　･･･
     　</VirtualHost>

4. WebOTX Webサーバ（Apache）の再起動

バーチャルホストAに対して /aaa にリクエストを行うと正常にレスポンスが返り、/bbb にリクエストを行うとコンテキスト名を設定していないため 404エラーが返ります。
また、バーチャルホストBに対してリクエストを行った場合は /aaa にリクエストすると 404エラーが返り、/bbb にリクエストすると正常にレスポンスが返るようになります。

1.4.5. IIOPプラグイン定義ファイルの設定方法

WebOTX Application Server Standard/Enterprise では、Webアプリケーションを動作させるWebコンテナをTPモニタ上でマルチプロセス動作する機能を提供します（アドバンスドモード）。 このマルチコンテナ機能を利用する際に外部Webサーバ（WebOTX Webサーバ（Apache））とWebコンテナをIIOPプラグインで連携させることができます。V9.3よりアドバンスドモード利用時にデフォルトではWebコンテナとWebサーバ間の通信をAJPプロトコルで行っています。IIOPプロトコルで通信する場合にこの節で説明する IIOP プラグインを利用します。

IIOPプラグインの連携設定は、環境設定ツールを使用して連携設定を行います。また、さらに詳細な連携設定は、設定ファイルを直接編集して行います。ここでは、IIOPプラグインの連携の詳細設定、エラードキュメントを指定する方法を説明します。　環境設定ツールを使用した連携設定については「セットアップガイド・インストール」を参照してください。

1.4.5.1. IIOPプラグイン定義ファイルの設定手順

外部Webサーバ（WebOTX Webサーバ（Apache））とWebコンテナの連携設定を行ったあとに、以下の設定をしてください。

設定手順

1. 外部Webサーバの停止
2. ior_workers.propertiesの設定

   設定ファイル　${INSTANCE_ROOT}/config/WebCont/ior_workers.propertiesを編集し、保存します。

   [ ior_workers.propertiesの設定例]

   # TM_PLUGIN_IOR-start worker.list=otxiiop otx_domain=C:/WebOTX/domains/domain1 worker.otxiiop.type=otxiiop worker.otxiiop.default_ior=localdomain worker.otxiiop.ior_def.localdomain=$(otx_domain)/config/httpgateway.ior worker.otxiiop.connection_pool_size=150 worker.otxiiop.http_error.list=404,500 worker.otxiiop.http_error.404.doc=file:///D:/temp/error/404.html worker.otxiiop.http_error.500.doc=file:///D:/temp/error/500.html worker.otxiiop.http_error.charset=Shift_JIS # TM_PLUGIN_IOR-end

   
   
   
3. 外部Webサーバの起動

   外部Webサーバを起動し、設定内容を反映します。

1.4.5.2. IIOPプラグインの設定項目一覧

以下は、IIOPプラグイン特有の設定項目一覧です。

IIOPプラグインが自ドメイン(環境設定ツールで設定したドメイン)以外に配備されたコンテキストを呼び出すためコンテキストとIORを対応付けする情報定義を行うことができます。

また、HTTPエラーおよびCORBAエラーに対応するエラードキュメントを指定することができます。　IIOPプラグインの設定とともに、Apacheのエラードキュメントの設定を行ってください。エラーの内容により有効になる設定箇所が変わります。

Caution
IIOPプラグインでは、負荷分散機能をサポートしていません。

連携設定項目：ior_workers.properties

エラードキュメント指定設定項目

1.4.5.3. IIOPプラグインの設定例

以下にIIOPプラグイン定義について設定例で説明します。

環境設定ツールで設定を行うと ior_workers.properties は、以下の初期値に戻ります。

※ "otx_domain" はマクロ定義です。　$(otx_domain) として、パラメータに使用します。

1.4.6. Web版統合運用管理コンソールを利用したプラグインの設定方法

WebOTX Application Server V8.3 以降 では、統合運用管理ツールやWeb版統合運用管理コンソールからWebサーバプラグインの設定項目を変更する機能を提供しています。

ただし、WebサーバとWebコンテナが別マシン構成の場合、この機能を利用するには以下の両方の条件を満たしている必要があります。

• Webサーバの入っているマシンにWebOTXがインストールされている
• 両方のマシンに入っているWebOTXのWebコンテナの動作モードが同じ

Caution
この機能では連携設定済みの環境に対して、設定項目のカスタマイズを行います。Webサーバとの連携ができていない場合は、先に環境設定ツールを使用して連携設定を行ってください。環境設定ツールを使用して連携設定を行うと、workers.properties/ior_workers.properties に対して行われた設定は全て初期化されます。

1.4.6.1. Web版統合運用管理コンソールから設定可能な項目

外部Webサーバ連携時には、使用するWebサーバの種類や、連携先のWebコンテナの動作モードによってWebサーバプラグイン用の複数の設定ファイルが使用されます。一部の設定ファイルについては、Web版統合運用管理コンソールや運用管理コマンドから設定できず、手動で設定を行う必要があります。以下は使用するWebサーバごとの設定ファイルとWeb版統合運用管理コンソールからの設定可否の一覧です。「コンソールからの設定」が「△」のファイルは、一部の機能を設定可能です。「×」のファイルについては、設定できません。

下表はWeb版統合運用管理コンソールや運用管理コマンドから設定可能な項目です。下表の「設定ファイル内での設定名」にある項目と workers.properties/ior_workers.properties に設定する項目についてはWeb版統合運用管理コンソールや運用管理コマンドから設定できます。上表で「コンソールからの設定」が「△」になっているファイルに設定する項目で、下表の「設定ファイル内での設定名」にない項目については手動で設定する必要があります。Web版統合運用管理コンソールや運用管理コマンドから設定を行った場合、設定内容に応じて「更新される設定ファイル」に出力されます。

以下では具体的な設定方法について、Web版統合運用管理コンソールを使用して説明を行います。

ブラウザを起動し、連携設定を行ったドメインの管理コンソール(http://<host>:<port>/manager)に接続し、ログインしてください。(domain1の場合の<port>の既定値は 5858 です。)

1.4.6.2. 動的反映機能/プラグインのログのローテーション/コネクションプールサイズの設定

プラグインの動的反映オプションやプラグインのログのローテーション、コネクションプールサイズの設定を行う方法を説明します。ログのローテーションの設定は、WebOTX Webサーバ使用時のみ有効です。 WebOTX Webサーバ以外のWebサーバでプラグインのログのローテーションの設定を行う場合は「ドメイン構築・基本設定ガイド > 8. ログ」を参照し、手動で設定を行ってください。

1. 管理コンソールの左側のツリーから「アプリケーションサーバ」-「Webコンテナ」-「Webサーバ連携設定」を選択します。
2. 「一般」タブおよび「ログの設定」タブで該当の項目を変更します。

   プラグインのログを5Mごとにローテーションする場合

   • 「ログの設定」タブで「ログのローテートの有効化」にチェックを入れます。
   • 「ログの設定」タブで「ログのローテート間隔」に "5M" を指定します。
   
   
   

   動的反映機能をオフにする場合

   • 「一般」タブで「プラグインの動的反映オプション」を「Off」にします。
   
   
   

   動的反映機能を起動後１回のみ有効にする場合

   • 「一般」タブで「プラグインの動的反映オプション」を「Once」にします。
   
   
   

   プラグインのコネクションプールサイズを100にする場合

   • 「一般」タブで「コネクションプールサイズ」に「100」を指定します。
   
   
   
3. 「更新」ボタンをクリックして、変更を設定ファイルに反映します。
4. 変更を反映するために、Webサーバを再起動してください。

1.4.6.3. workers.properties/ior_workers.properties ファイルの詳細設定

プラグインの設定項目のうち、workers.properties/ior_workers.properties ファイルに設定を行う項目は、「Webサーバ連携設定」に表示されていない項目でも以下の手順でWeb版統合運用管理コンソールから設定を行うことができます。 設定可能な項目一覧については「JKプラグイン、IIOPプラグイン共通の設定項目一覧」、「IIOPプラグインの連携設定項目」を参照してください。

1. 「操作」の表示レベルの変更

   コンソールの右上の「メニュービュー」から「設定」を選択します。
   「画面表示設定」タブの「操作の表示レベル」を「全レベル」に変更し、「確定」をクリックして設定してください。
   設定を画面に反映するためには、一度「Webサーバ連携設定」以外の項目を選択後、再度「Webサーバ連携設定」の項目を選択してください。
   設定が反映されると「操作」タブが表示されます。

2. 「操作」の実行
   • 設定項目の設定

     「操作」タブから「ワーカのプロパティの設定」を選択します。
     「プロパティ名」、「プロパティ値」に設定したい項目を入力し、「実行」ボタンをクリックして設定項目を追加/変更します。

   • 設定項目の確認

     「操作」タブから「ワーカのプロパティの取得」を選択します。
     「実行」ボタンをクリックして、プロパティの一覧を取得します。

   • 設定項目の削除

     「操作」タブから「ワーカのプロパティの削除」を選択します。
     削除したい「プロパティ名」を指定し、「実行」ボタンをクリックして設定項目を削除します。

3. Webサーバの再起動

   変更を反映するために、Webサーバを再起動してください。

1.4.7. HTTPセッション管理について

1.4.7.1. HTTPセッション管理について

セッション管理についてServlet2.4などに規定されている仕様や、クライアント（ブラウザ）側の動作などの一般的な動作の仕組みについて説明します。

セッションの管理方法にはCookieを使用する方法とURLRewritingを使用する方法があります。Cookieを使用する方法では、セッションを識別するためのセッションIDをCookieに保存します。URLRewritingを使用する方法では、セッションIDをURLのパラメータに追加します。

次項で２つのセッション管理方法の動作イメージを示します。

Cookieによるセッション管理

コンテナはクライアントにクッキーを送信します。その後、クライアントは、それぞれのリクエストのときにセッションを含むクッキーつけて、サーバに送信します。セッションのクッキーの名前は”JSESSIONID”を使用します。

図1.4.7.1-1

Cookieを使うセッションID管理方法は、セッションIDをWebブラウザのCookieに設定します。

URLRewritingによるセッション管理

ユーザアプリケーションはアクセス先URLを作成する際、URLにセッションIDを付加します。セッションIDは独自に編集するか、javax.servlet.http.HttpServletResponse#encodeURL()メソッドを用いて付加します。

図1.4.7.1-2

URLRewritingを使うセッションID管理方法は、セッションIDをHTMLの<Form>タグのactionのURLなどに付加します。

セッションタイムアウトについて

セッションには有効期限が存在します。指定した期間クライアントからのリクエストが無い場合、Webコンテナはセッションを破棄します。以降破棄されたセッションに対しリクエストがあった場合、新たにセッションが作成され要求されたセッションと入れ替えられます。

1.4.7.2. WebOTXの基本的な設定

WebOTXでのセッション管理に関連する基本的な設定について説明します。

セッション管理方法の切替

セッションをCookieで管理するかURLRewritingで管理するか、Webアプリケーション単位で切り替えます。

• 運用管理コンソールによる設定

• 運用管理コンソール(http://<host>:5858/manager/)を開きます。

  
  図1.4.7.2-1

  まず、上部の[設定]をクリックし、[画面表示設定]タブで[管理対象の表示レベル]を[全レベル]に変更し確定します。

  ツリーより[アプリケーション]-[Webモジュール]-[<対象アプリケーション>]-[module]-[<対象アプリケーション>]-[engine]-[web]-[web-module-config]を選択してください。表示された設定画面の「セッションIDの管理」チェックボックスを設定してください。
  チェックした場合はCookie管理、チェックしない場合はURLRewriting管理となります。

• nec-web.xmlによる設定

• 表1.4.7.2-1

  設定詳細
  設定箇所	<コンテキストルート>/WEB-INF/nec-web.xml
  既定値	true
  設定例	<nec-web-app> : <session-config> <session-properties> <property name="enableCookies" value="true" /> </session-properties> :
  説明	セッションの管理方法を指定、trueを設定した場合はCookie管理、falseを設定した場合はURLRewriting管理となります。
  備考	nec-web.xmlは予めwarアーカイブに格納しておいてください。

セッションのタイムアウト時間

セッションのタイムアウト時間(有効期限)を設定します。設定には幾つかの種類がありそれぞれ有効範囲が異なります。それぞれの設定について説明します。優先順位は後者ほど高くなります。

default-web.xmlによる設定

domain全体に対する設定になります。

  <web-app>
        :
    <session-config>
      <session-timeout>30</session-timeout>
    </session-config>
        :

nec-web.xmlによる設定

Webアプリケーション毎に有効な設定ですが、web.xmlの設定が無い場合に有効です。

  <nec-web-app>
      :
    <session-config>
      <session-properties>
        <property name="timeoutSeconds" value="5"/>
      </session-properties>
    </session-config>
      :

web.xmlによる設定

Webアプリケーション毎に有効な設定になります。

  <web-app>
      :
    <session-config>
      <session-timeout>30</session-timeout>
    </session-config>
      :

Webアプリケーションによる設定

セッション毎に有効な設定でユーザがWebアプリケーション中で指定します。

    :
  HttpSession session = request.getSession();
  session.setMaxInactiveInterval(300);
    :

セッション情報の保存

WebOTXでは何も設定しないデフォルトの状態ではdomainの停止と共にセッション情報は消えてしまいます。セッション情報をファイルに保存する設定を行うことでdomain再起動後もセッションをファイルから復元、継続して使用することができます。

※ WebOTXの環境がアドバンストモードで構築されている場合、セッションの保存方法には制限が存在します。 詳細は「1.4.7.4. WebOTXの高度な設定(アドバンスドモードでの設定) > アドバンスドモードでのセッション情報保存」 を参照してください。

※ セッション情報を保存したファイルの保存箇所は<domainディレクトリ>/generated/jsp/<Webアプリケーション名>配下がカレントになります。このディレクトリはWebアプリケーションを配備解除するとディレクトリが削除され、セッション情報が失われますのでご注意ください。

メモリ管理によるセッション保存

セッションはメモリ上に展開され、domainの停止時にファイルに出力されます。domainが正常に停止されない場合(突然のアボート等)、セッション情報はファイルに保存されないことがあります。

  <nec-web-app>
      :
    <session-config>
      <session-manager persistence-type="memory">
        <manager-properties>
          <property name="sessionFilename" value="/session.ser"/>
        </manager-properties>
      </session-manager>
    </session-config>
      :

※ WebOTXの環境がアドバンストモードで構築されている場合、セッションの保存方法には制限が存在します。 詳細は「1.4.7.4. WebOTXの高度な設定(アドバンスドモードでの設定) > アドバンスドモードでのセッション情報保存」 を参照してください。

ファイル管理によるセッション保存

セッションはメモリ、ファイル両方に展開されます。メモリ上で管理されているセッション情報を一定間隔(60秒)でファイルに出力します。セッション更新後ファイル出力をまたずdomainが正常に停止されない場合(突然のアボート等)、ファイルに最新情報が反映されない場合があります。

  <nec-web-app>
      :
    <session-config>
      <session-manager persistence-type="file">
        <manager-properties>
          <property name="sessionFilename" value="/session.ser"/>
        </manager-properties>
      </session-manager>
    </session-config>
      :

※ WebOTXの環境がアドバンストモードで構築されている場合、セッションの保存方法には制限が存在します。 詳細は「1.4.7.4. WebOTXの高度な設定(アドバンスドモードでの設定) > アドバンスドモードでのセッション情報保存」 を参照してください。

セッションの同時最大数設定

同時に作成できるセッションの最大数を設定します。

セッションレプリケーション時に本項目を指定するとセッション数増加に伴いセッションを払いだす時間が長くなります。ご注意ください。

  <nec-web-app>
      :
    <session-config>
      <session-manager>
        <manager-properties>
          <property name="maxSessions" value="200"/>
        </manager-properties>
      </session-manager>
    </session-config>
      :

セッションのCookieへのSecure属性の設定

セッションをCookie管理している場合、セッションIDを格納するCookieに自動でSecure属性の設定を行うことができます。 ただし、このオプションはユーザが作成したCookieには適用されません。ユーザが作成したCookieにSecure属性を付与する場合はCookieのAPI(javax.servlet.http.Cookie#setSecure())で設定してください。 Secure属性を設定したCookieはクライアントからHTTPSプロトコルでアクセスされた場合のみリクエストに付加され、HTTPプロトコルでアクセスされた場合は付加されなくなります。

  <nec-web-app>
      :
    <session-config>
      <cookie-properties>
        <property name="cookieSecure" value="true"/> 
      </cookie-properties>
    </session-config>
      :

URLのセッションID付加抑制の設定

HttpServletResponse.encodeURL()を実行しても、URLRewriting(セッションIDの付加)を行わない設定を行います。

  <nec-web-app>
      :
    <session-config>
      <session-properties>
        <property name="enableURLRewriting" value="false" />
      :

セッションを強制的に使えなくする設定

セッションを強制的に使えなくする設定です。動作的にはセッションオブジェクトが取得できないわけではなく、リクエストの終了時セッションがあれば無効化するような動作になります。 また、レスポンス(CookieやURLRewriting)にセッションIDは設定されません。

  <nec-web-app>
      :
    <session-config>
      <session-properties>
        <property name="enableSession" value="false" />
      :

jvmRouteオプションの設定

ドメインもしくはプロセスグループ単位でセッションIDに、指定した文字列を付加することができます。セッションIDを払い出したWebサーバを特定したい場合などに使用します。

  -DjvmRoute="hoho1"

  5B22AF53A66CAB1AB26490EB430D36C3.hoho1$3936
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~ ~~~~
  セッションID(32桁) . jvmRoute $ プロセスID

静的ファイルへのセッション時刻更新をスキップする設定

セッションを使用しない静的ファイル(html、gif等)へのリクエストに対して、セッションの時刻情報を更新しないように設定できます。 セッションID付け替えによる制限事項の軽減に対して有効です。

  <nec-web-app>
      :
    <session-config>
      <session-manager>
        <manager-properties>
          <property name="skipStaticFileSessionUpd" value="true"/>
        </manager-properties>
      </session-manager>
    </session-config>
      :

セッションIDの長さ設定

Webコンテナが生成するセッションIDの長さは、既定では16進で32桁（16byte==128bit）ですが、 設定により変更することが可能です。

  <nec-web-app>
      :
    <session-config>
      <session-manager>
        <manager-properties>
          <property name="sessionIdLength" value="16"/>
        </manager-properties>
      </session-manager>
    </session-config>
      :

1.4.7.3. セッションレプリケーション

セッションレプリケーションについて

システムの信頼性を高めるための複数のサーバ間でセッションデータを複製しておく仕組みをセッションレプリケーションと言います。セッションレプリケーションを設定することで１台のサーバがダウンした場合でも複製したセッション情報を元に他のサーバが処理を引き継ぐことができます。WebOTXのセッションレプリケーションはセッション情報をJNDI(または、データベース)に格納することで実現します。JNDIを使用する場合の情報共有に関しては 1.4.3. HTTPのみのセッションレプリケーション及び1.6.4. JNDIサーバをレプリケーションするための設定を参照してください。

セッションレプリケーションを行うにあたり、Webアプリケーションの作りに一部制限が存在します。詳細は [ 1.4.7.3. セッションレプリケーション > Webアプリケーション実装の注意/制限事項 ] を参照してください。

セッションレプリケーションの概要を図にします。

図1.4.7.3-1

WebOTXのレプリケーション機能の動作概要について記述します。

1. 共有されるセッション情報の範囲と共有のトリガ
   全てのセッション情報が共有され、セッションに格納している情報の更新があった場合、更新された差分のみが更新/共有されます。
   またHTTPリクエスト受信時、セッションが検出された場合、セッションへのアクセス時刻を更新/共有します。
   
   
2. レプリケーション時の性能
   レプリケーションした環境では無負荷状態で、クライアントへのレスポンスは約10mSec遅くなります。 セッションへのアクセス回数やJNDIサーバ(または、データベースサーバ)に登録されているセッション数に依存して遅くなります。
   セッションの最大数は、デフォルトでは無制限ですが、この値を設定すると、新規セッション生成時にはセッション数をJNDIサーバ(または、データベースサーバ)から 情報を取り出して現状のセッション数を数えるため、レスポンスが遅くなります。
   
   

Webアプリケーションにセッション情報をJNDIに登録するための設定を行います。

  <web-app>
      :
    <distributable/>
      :

レプリケーションモードについて

• 即時同期モード (RealtimeSynchro モード、RSモードと略します)
  従来のWebOTXと同じ動作するレプリケーションモードです。 Servlet処理中の情報更新(setAttribute()等の実行)に合わせてリアルタイムにセッション情報を格納先に反映する、信頼性重視のモードです。
  
  
• 同期モード (StandardSynchro モード、SSモードと略します)
  即時同期モードの動作に似ていますがServlet処理の延長ではセッション情報の格納先への反映は行いません。 リクエスト終了時にまとめて格納先への反映を行います。 信頼性と処理速度のバランスの取れたモードですが、Webアプリケーションの作りによってはセッション情報の整合性が取れない場合があります。
  
  
• 非同期モード (Asynchro モード、ASモードと略します)
  即時同期・同期モードとは異なる動作をします。 異なる点は大きく２つで、他のモードではリクエストをトリガに格納先への反映を行いますが非同期モードではWebコンテナがバックスレッドにて定期的にセッション情報の反映を行います。そのためセッション情報が格納先に反映される前にプロセスがアボートすると、前回反映処理から更新されたセッション情報は消えてしまいます。 もう一点は他のモードは格納先に格納されたセッション情報が最新の情報としている(格納先のセッション情報が主)のに対して、非同期モードはメモリ上のセッション情報が最新(メモリ情報のセッション情報が主)としている点です。たとえば非同期モードでは格納先にセッション情報が無くてもメモリ上のセッション情報を元に格納先へバックアップしますが、他のモードでは格納先に該当するセッション情報が無い場合、メモリ上のセッションは無いものとして破棄されます。
  
  

JNDIを利用するレプリケーション設定

※セッションレプリケーションを設定する場合、セッションの管理方法をメモリに設定する必要があります。 [1.4.7.2. WebOTXの基本的な設定 > メモリ管理によるセッション保存] 参照

異なるdomainのJNDIを連携設定することでセッション情報を共有します。設定方法によらず設定内容はセッションレプリケーションするJNDIサーバのURLを"rmiiiop://host1:port,host2:port"の形式で設定します。ここで２重化されるのはセッション情報のみです。

• 管理コンソールから設定する場合

  画面左ツリーより「Webアプリケーションサーバ」-「Webコンテナ」を選択し、「JNDI Servlet URL」を更新します。

  
  図1.4.7.3-2

• 運用管理コマンドから設定する場合

  運用管理コマンドより以下のコマンドを実行します。

  otxadmin> set server.web-container.session-replication-jndi-url=rmiiiop://host:port,host2:port

データベースを利用するレプリケーション設定

• 即時同期・同期モードの場合
  
  セッション情報・セッションAttribute情報格納テーブル作成

  CREATE TABLE webotx$sessions( app VARCHAR(100) NOT NULL, session_id VARCHAR(100) NOT NULL, createhost VARCHAR(64), createtime NUMBER, lastaccesstime NUMBER, thisaccesstime NUMBER, maxInactiveInterval NUMBER, invalidate NUMBER, createversion VARCHAR(64), PRIMARY KEY(app, session_id)); CREATE TABLE webotx$sessions$attributes( app VARCHAR(100) NOT NULL, session_id VARCHAR(100) NOT NULL, attributename VARCHAR(100) NOT NULL, attributevalue BLOB, PRIMARY KEY(app, session_id, attributename));

  
  インデックスの作成

  CREATE INDEX webotx$sessionsindex ON webotx$sessions( app, session_id, maxInactiveInterval, invalidate, createversion);

  
  
• 非同期モードの場合
  
  セッション情報格納テーブルの作成

  CREATE TABLE webotx$sessiondata( session_id VARCHAR(100) NOT NULL, app VARCHAR(100) NOT NULL, data BLOB, createversion VARCHAR(64), PRIMARY KEY(app, session_id));

  
  インデックスの作成

  CREATE INDEX webotx$sessiondataindex ON webotx$sessiondata( app, session_id, createversion);

  
  

• 管理コンソールから設定する場合
  
  画面左ツリーより「リソース」-「JDBCデータソース」を選択し、「JDBCデータソースの登録」を実行します。
  
  

  
  図1.4.7.3-3

  
  
• 運用管理コマンドから設定する場合
  
  運用管理コマンドより以下のコマンドを実行します。
  
  

  otxadmin> create-jdbc-datasource --dataSourceType JDBCEX_Oracle --jdbcMajorVersion 3 --jdbcUserName scott --jdbcPassword tiger --dataSourceName jdbc:oracle:thin:@localhost:1521:ORCL jdbc/Oracle

Infinispan を利用するレプリケーション設定

• 管理コンソールから設定する場合

  画面左ツリーの「アプリケーションサーバ」-「data-grids」-「data-grid」配下に存在するデータグリッドから、 利用するデータグリッドを選択し、「一般」タブにある属性「タイプ」に「infinispan」を指定します。
  
  

  
  図1.4.7.3-4

• 運用管理コマンドから設定する場合

  運用管理コマンドより以下のコマンドを実行します。
  ※以下のコマンドは既定のデータグリッド「__default_http_session」を利用する場合の例です。

  otxadmin> set server.data-grids.data-grid.__default_http_session.type = infinispan

  
  
  

• 管理コンソールから設定する場合

  画面左ツリーより 「Webアプリケーションサーバ」-「セッション構成」-「セッションマネージャ」-「マネージャプロパティ」 の 「セッションレプリケーション」タブを選択し、 「データグリッド名」に、利用するデータグリッド名を指定します。(既定値： __default_http_session )
  
  

  
  図1.4.7.3-5

• 運用管理コマンドから設定する場合

  運用管理コマンドより以下のコマンドを実行します。

  otxadmin> set server.session-config.session-manager.manager-properties.data-grid-name=<データグリッド名>

  
  
  

• 管理コンソールから設定する場合

  画面左ツリーより 「Webアプリケーションサーバ」-「セッション構成」-「セッションマネージャ」-「マネージャプロパティ」 の 「セッションレプリケーション」タブを選択し、 「保存先タイプ」において、「DATAGRID」を選択します。
  
  

  
  図1.4.7.3-6

• 運用管理コマンドから設定する場合

  運用管理コマンドより以下のコマンドを実行します。

  otxadmin> set server.session-config.session-manager.manager-properties.storage-type=DATAGRID

Oracle Coherenceを利用する設定

セキュリティポリシファイル（${INSTANCE_ROOT}/config/server.policy）を以下のように変更します。

grant codeBase "file:${com.nec.webotx.instanceRoot}/applications/-" {
    permission java.util.logging.LoggingPermission "control", "";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codeBase "file:${com.nec.webotx.instanceRoot}/applications/-" {
    permission java.util.logging.LoggingPermission "control", "";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";

    // for Coherence
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "getenv.*";
    permission java.lang.RuntimePermission "getStackTrace";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "selectorProvider";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.management.ManagementPermission "monitor";
    permission java.net.NetPermission "getNetworkInformation";
    permission java.net.SocketPermission "*:0-65535", "listen,accept,resolve";
    permission java.security.SecurityPermission "insertProvider.CoherenceSecurityProvider";
    permission java.security.SecurityPermission "putProviderProperty.CoherenceSecurityProvider";
    permission java.security.SecurityPermission "insertProvider.OracleCommonsSecurityProvider";
    permission java.security.SecurityPermission "putProviderProperty.OracleCommonsSecurityProvider";
    permission javax.security.auth.AuthPermission "getSubject";
};

※ SocketPermissionでのポート番号の指定は、Coherenceが使用する番号を指定してください。

※ セキュリティポリシファイルの変更は、ドメイン再起動で有効になります。

1. インスペクトコマンドの実行

   以下のようにインスペクトコマンドを実行します。

   > java -jar coherence/lib/webInstaller.jar <Webアプリケーションディレクトリ> -inspect -server:Generic

   
   コマンドの実行が完了すると、Webアプリケーションディレクトリにcoherence-web.xmlが生成されます。
   
   
2. coherence-web.xmlの変更
   

   インスペクトコマンドの実行により生成されたcoherence-web.xmlを以下のように変更します。

   修正前	<context-param> <param-name>coherence-servletcontext-clustered</param-name> <param-value/> </context-param> : : <context-param> <param-name>coherence-scopecontroller-class</param-name> <param-value>com.tangosol.coherence.servlet.AbstractHttpSessionCollection$ApplicationScopeController</param-value> </context-param>
   修正後	<context-param> <param-name>coherence-servletcontext-clustered</param-name> <param-value>true</param-value> </context-param> : : <context-param> <param-name>coherence-scopecontroller-class</param-name> <param-value>com.tangosol.coherence.servlet.AbstractHttpSessionCollection$GlobalScopeController<param-value> </context-param>

   
   
3. インストールコマンドの実行
   

   以下のようにインストールコマンドを実行します。

   > java -jar coherence/lib/webInstaller.jar <Webアプリケーションディレクトリ> -install

以上でWebアプリケーションへのCoherence組み込みは終了です。

Webアプリケーションディレクトリ配下をwarアーカイブしてドメインに配備してください。

既定では、Web アプリケーション側のCoherenceは保存領域を持たないため、外部プロセスとしてキャッシュサーバを起動する必要があります。また、WebOTX ASではクラスタの設定として、${INSTANCE_ROOT}/config/datagrid/coherenceにある設定ファイルを参照するため、キャッシュサーバもこの設定ファイルを参照するか同じ設定内容のファイルを参照する必要があります。WebOTX ASが使用するクラスタ設定ファイルの名前は、server.data-grids.coherence-cluster-file (既定値: webotx-coherence-cluster1.xml) で指定されます。キャッシュサーバ起動スクリプトの例を以下に示します。

• Windows の場合

  set AS_INSTALL=<WebOTXインストールディレクトリ>
  set INSTANCE_ROOT=%AS_INSTALL%\domains\<ドメイン名>
  set COHERENCE_HOME=%AS_INSTALL%\coherence
  
  set JAVA_HOME=<JDKホームディレクトリ>
  set JAVA_OPTS=-Xms1024m -Xmx1024m
  
  "%JAVA_HOME%\bin\java.exe" ^
    -server -showversion %JAVA_OPTS% ^
    -cp "%INSTANCE_ROOT%\config\datagrid\coherence";"%COHERENCE_HOME%\lib\coherence-web.jar";"%COHERENCE_HOME%\lib\coherence.jar" ^
    -Dtangosol.coherence.cacheconfig=default-session-cache-config.xml ^
    -Dtangosol.coherence.override=webotx-coherence-cluster1.xml ^
    -Dtangosol.coherence.session.localstorage=true ^
    com.tangosol.net.DefaultCacheServer
  

• Linux の場合

  AS_INSTALL="<WebOTXインストールディレクトリ>"
  INSTANCE_ROOT="$AS_INSTALL/domains/<ドメイン名>"
  COHERENCE_HOME="$AS_INSTALL/coherence"
  
  JAVA_HOME="<JDKホームディレクトリ>"
  JAVA_OPTS="-Xms1024m -Xmx1024m"
  
  "$JAVA_HOME/bin/java" \
    -server -showversion $JAVA_OPTS \
    -cp "$INSTANCE_ROOT/config/datagrid/coherence":"$COHERENCE_HOME/lib/coherence-web.jar":"$COHERENCE_HOME/lib/coherence.jar" \
    -Dtangosol.coherence.cacheconfig=default-session-cache-config.xml \
    -Dtangosol.coherence.override=webotx-coherence-cluster1.xml \
    -Dtangosol.coherence.session.localstorage=true \
    com.tangosol.net.DefaultCacheServer
  

Standard以上のエディションでは、配備時のCoherence自動組み込み機能を提供しています。配備のpreprocessorオプションに「CoherenceWebInstaller」を指定することで、上記の1〜3を配備処理中に自動で実行します。

Coherenceを<WebOTXインストールディレクトリ>/coherence以外の場所にインストールしている場合、Coherence自動組み込み機能を利用するためには、以下のいずれかの準備が必要です。

1. エージェントプロセスに以下のJVMオプションを追加する。
   ※ WebOTXと同じマシンにCoherenceをインストールしている場合は、こちらを推奨します。

   • -Dcom.nec.webotx.as.deployment.preprocess.CoherenceWebInstaller.coherence-home=<Coherenceインストールディレクトリ>
   
   

   コマンドでJVMオプションを追加する場合は、以下のとおりです。

   > otxadmin create-jvm-options -Dcom.nec.webotx.as.deployment.preprocess.CoherenceWebInstaller.coherence-home=<Coherenceインストールディレクトリ>

   ※ JVMオプションの追加は、ドメイン再起動で有効になります。

2. 以下の3ファイルを<WebOTXインストールディレクトリ>/coherence/libにコピーする。

   • webInstaller.jar
   • coherence.jar
   • coherence-web.jar

Coherence自動組み込み機能は、ディレクトリ配備に対して使用することはできません。また、Coherence自動組み込み機能がサポートするアプリケーションは、CoherenceのwebInstaller.jarがサポートするWARファイルおよびそのようなWARファイルを含むEARファイルです。

Coherence自動組み込み機能は、セキュリティポリシファイルの変更を行いません。別途変更を行ってください。

Webアプリケーション実装の注意/制限事項

セッションレプリケーションを使用するにあたってWebアプリケーションを実装する上での注意点を以下に記載しています。

1. レプリケーションした場合、セッションのAttributeに設定できるオブジェクトはシリアライズできるものに限られます。
   
   
2. 即時同期モードでレプリケーションした場合、セッションのAttributeに設定したオブジェクトとJNDI(あるいは、 データベース、DATAGRID)で管理されているオブジェクトは別インスタンスの扱いになります。
   
   
   どのような場合に問題になるか例を記述します。
   
   <ソースコード>
   

   HttpSession session = <HttpServletRequest>.getSession(); hohoClass clazz = new hohoClass(); clazz.buff = "ABC"; session.setAttribute("hoho", clazz); clazz.buff = "DEF"; hohoClass clazz2 = (hohoClass)session.getAttribute("hoho"); String buff = clazz2.buff;

   
   <ソースコード解説>

   あるクラスが持つStringオブジェクトに"ABC"を格納しセッションのAttributeに設定します。 Stringオブジェクトの内容を"DEF"に更新します。 セッションのAttributeからクラスのStringオブジェクトを取得します。 レプリケーション設定していない場合、取得したStringオブジェクトの内容は"DEF"ですが、 レプリケーション設定した場合、内容は"ABC"になります。

   レプリケーション前と同じ取得を"DEF"にしたい場合はiiとiiiの間で再度setAttribute()を実行する必要があります。

   HttpSession session = <HttpServletRequest>.getSession(); hohoClass clazz = new hohoClass(); clazz.buff = "ABC"; session.setAttribute("hoho", clazz); clazz.buff = "DEF"; session.setAttribute("hoho", clazz); hohoClass clazz2 = (hohoClass)session.getAttribute("hoho"); String buff = clazz2.buff;

   
   

3. セッションレプリケーションを設定するとセッション情報がJNDI(あるいは、データベース、 DATAGRID)に格納されるようになります。この際セッションに格納しているオブジェクトに関して注意点があります。

   セッション情報として、VectorやHashtableなど、同期化されたコレクションクラスを使用すると、シリアライズ/デシリアライズが同期化されてしまいます。同期化されてしまうと処理が直列化されて、大幅な性能低下につながるおそれがあります。そのためVectorやHashtableではなく同期化されないArrayListやHashMapをご使用ください。

   また、シリアライズ/デシリアライズは複雑なコレクションクラスの処理には時間が掛かります。セッション情報として使用するオブジェクトはシンプルなものをお勧めします。

1.4.7.4. WebOTXの高度な設定(アドバンスドモードでの設定)

アドバンストモードでは通常のセッション管理に加えてアドバンストモード特有の管理情報が追加されます。 通常レプリケーション設定が無い場合、セッションを構築したクライアントとサーバは１対１ですがアドバンストモードの場合、サーバ側で動作する プロセス数がプロセスグループの設定により複数になる可能性があります。

セッションを維持するためにはクライアントからのリクエストを、セッションを払いだしたプロセスに送る必要があります。そのためにWebコンテナは セッションIDを払いだす際に通常のセッションIDの後に"$"を区切りとして自身が動作しているプロセスのIDを付加します(※)。 次回リクエスト時、セッションIDにこのプロセスIDが付加されていた場合、該当するプロセスを探し出して転送します。

※ 環境の構成によってはプロセスIDが付加されない場合があります。詳細は次節参照

アドバンスドモードでのセッションID

アドバンストモードでのセッションIDには構成によりプロセスIDが付加されます。何かの事情によりプロセスIDを付加したくない場合、「強制的にプロセスIDを付加する/しない」 を設定することができます。

※ スタンダードモードではプロセスIDが付加されることはありません

構成によるプロセスIDの付加

プロセスIDを付加した場合セッションIDの例を示します。

C7C25B729C39629558DB02C5FA25E038$6212 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~ セッションID(32桁) $ プロセスID

アドバンスドモードでのセッション情報保存

WebOTXの環境がアドバンストモードの場合、構成によりセッション情報の保存方法に制限が存在します。

• プロセス数が１の場合
  制限はありません通常と同じ方法でセッション情報を保存することができます。
• プロセス数が複数の場合
  セッション情報をファイルに保存する方法が使用できません、セッションを保存するにはレプリケーション設定を行う必要があります。

1.4.7.5. Webブラウザの設定とセッションの関係

１つのホストのWebブラウザから、同じホストで起動する複数のドメインに対してリクエストを行った時、セッションIDが意図したとおりに取得できない事があります。

例えば次のようなケースで説明します。

• ホストXにドメインAを起動
• ホストXにドメインBを起動
• ドメインAにアプリケーションCCCを配備
• ドメインBにアプリケーションCCCを配備
  
  ※アプリケーションCCCは、画面D, Eを持ちます。
  ※ドメインA、Bに配備したアプリケーションのコンテキスト名は同じ。

上記のような構成で次のようにアクセスしたとします。
※下記アプリケーションのアクセスでHTTPセッションを生成するものとします。

1. Webブラウザを起動し、ドメインAの画面Dへ遷移（ウィンドウ１）
2. (1)のWebブラウザから別ウィンドウを起動し、ドメインBの画面Dへ遷移（ウィンドウ２）
3. ウィンドウ１で、画面Dのリンクをクリックし、ドメインAの画面Eへ遷移

この場合、(3)でアプリケーションが取得できるHTTPセッションは(1)で生成されたHTTPセッションではなく新たに生成されたHTTPセッションとなります。この時のセッションIDの生成と動きを次に説明します。

1. Webブラウザを起動し、ドメインAの画面Dへ遷移（ウィンドウ１）
   ドメインAはセッションID:FFFを生成
   以降、WebブラウザはドメインへFFFを送信
   
   
2. (1)のWebブラウザから別ウィンドウを起動し、ドメインBの画面Dへ遷移（ウィンドウ２）
   ドメインBはセッションID:GGGを生成
   以降、WebブラウザはドメインへはGGGを送信
   
   
3. ウィンドウ１で、画面Dのリンクをクリックし、ドメインAの画面Eへ遷移
   WebブラウザはドメインAへGGGを送信。ドメインAにはGGGというセッションIDは存在しないためHHHを生成。
   
   

(3)で(1)と異なるセッションIDが生成されるのは次の2の要素が原因です。

• WebブラウザがCookieを共有している事
• 2つのドメインに同じ(コンテキスト名の)アプリケーションが配備されている事

セッションIDはWebブラウザ毎にドメイン側で生成されます。そして、一度生成されたセッションIDはCookieを利用してWebブラウザとドメイン間でやり取りされます。

この時、ドメイン側ではリクエストに含まれるセッションIDを頼りに、過去にアクセスのあったWebブラウザなのかを判断します。新規のアクセスであればリクエストにセッションIDはありません。2回目以降のアクセスであればリクエストに含まれるセッションIDから過去にアクセスしたWebブラウザだと判断します。

また、セッションIDを格納するCookieにはPath属性としてアプリケーションのコンテキスト名が設定されています。

   例）
   Set-Cookie: JSESSIONID=51BD6DE9BCF62164C894AE85882A14A9; Path=/examples/

つまり、同じドメインへのアクセスでも、アプリケーション(のコンテキスト名)が異なると別物として扱います。逆に言えば、ドメインが異なってもアプリケーション(のコンテキスト名)が一緒の場合は同じCookieが送信されます。

このような環境で各ドメインのアプリケーション毎に生成したセッションIDを取得したい場合の対処としては次の方法があります。

• アプリケーションのコンテキスト名を別にする
• ドメインA、Bを別々のホストに配置する
• Webブラウザでウィンドウを開くときに「新規セッション」を利用する

[アプリケーションのコンテキスト名を別にする]

Webブラウザはアプリケーション(のコンテキスト名)が異なると別のセッションだと判断しますので、コンテキスト名を変えると、ドメインA, Bが同じホストで同じアプリケーションを配置していてもセッションIDは別となります。

[ドメインA、Bを別々のホストに配置する]

Webブラウザは同じアプリケーション(コンテキスト名)でもホスト毎にCookieを管理するため、セッションIDは別になります。

[IEでウィンドウを開くときに「新規セッション」を利用する]

通常Webブラウザは普通にウィンドウを複数起動するとCookieを共有します。例えば、Internet Explorer(IE)では、「ファイル」メニューから明示的に「新規セッション」を利用して別のウィンドウを開くと、ドメインA, Bが同じホストで同じアプリケーションを配置していても同じCookieを送信せず、セッションIDは別となります。

1.4.8. 文字コード設定について

1.4.8.1. 文字コードについて

Javaにおいて文字コードを意識する箇所を簡単に説明します。

Java内部では文字は全てUnicodeで処理されています。ですが例えば、あるファイルをServletから読み込む場合ファイルはShift_JISで書かれていたとすればShift_JIS<->Unicodeの変換を行わなければJava内部では文字列として使用することができません。

例のようにJavaは外部にI/Oする際に文字コードの変換が発生します。この変換する文字コードが指定されていない場合、Javaでデフォルトとなっている文字コードを使用しますが、デフォルトの文字コードはJavaが動作しているOS環境によって異なります。(Windowsであればwindows-31j、LinuxであればEUC-JP等)

Servlet(Java)への主なI/Oについて概要図を示します。

図1.4.8.1-1

1. HTTPリクエスト
   「リクエストのデータをどの文字コードとしてJavaで扱うUnicodeに変換するか」、の設定があります。
   
   詳細は [1.4.8.2. 文字コードの優先順位 > HTTPリクエスト] 参照
   
   ※URLに使用できる文字については [1.4.9.1. URL] を参照してください。
   
   
2. HTTPレスポンス
   「レスポンス出力時、Javaで扱うUnicodeをどの文字コードに変換してレスポンス出力するか」、の設定があります。
   
   詳細は [1.4.8.2. 文字コードの優先順位 > HTTPレスポンス] 参照
   
   
3. JSPファイルのコンパイル
   「JSPファイルをどの文字コードで読み込み、Javaで扱うUnicodeに変換するか」、の設定があります。
   
   詳細は [1.4.8.2. 文字コードの優先順位 > JSPファイルのコンパイル] 参照
   
   ※ファイル名に使用可能な文字については[1.4.9.1. URL]を参照してください。
   
   
4. JSPファイルのレスポンス
   「JSPを実行した際、Javaで扱うUnicodeをどの文字コードに変換してレスポンス出力するか」、の設定があります。
   
   詳細は [1.4.8.2. 文字コードの優先順位 > JSPファイルのレスポンス] 参照
   
   
5. ファイル入力/出力
   ファイルにアクセスするInputStream、OutputStreamを作成する際ユーザが文字コードを設定します。WebOTX独自の設定機能は存在しませんがJVMオプション (-Dfile.encoding=<MS932等>)設定によりデフォルトの文字コードを変更できます。
   
   ※ファイル名に使用可能な文字については[1.4.9.1. URL]を参照してください。
   
   
6. データベースアクセス
   JDBCドライバに依存します。
   
   

次節以降の表中で使用する用語について説明します。

• web.xml -> <コンテキストルート>/WEB-INF/web.xmlを表します。
• nec-web.xml -> <コンテキストルート>/WEB-INF/nec-web.xmlを表します。
• domain.xml -> <ドメインルート>/config/domain.xmlを表します。
  ※ domain.xmlを更新した場合、ドメインの再起動により有効になります。環境がアドバンスドモードでプロセスグループを再起動した場合、再起動したプロセスグループのみ有効になります。

使用できる文字コードはJavaのプラットフォームにより異なります。Javaのマニュアルにてご確認ください。

1.4.8.2. 文字コードの優先順位

文字コードの設定箇所と、それぞれの優先順位を記述します。

HTTPリクエスト

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

    :
((HttpServletRequest)request).setCharcterEncoding("Shift_JIS");
    :

<nec-web-app>
    :
  <locale-charset-info>
      <parameter-encoding form-hint-field="penc" default-charset="windows-31j"/>
  </locale-charset-info>
    :

HTTPレスポンス

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

<nec-web-app>   
    :
  <property name="priorityResponseEncoding-map:ja" value="EUC-JP"/>  
    :
  <property name="priorityResponseEncoding" value="windows-31j"/>  

otxadmin> set server.web-container
.property.priority-response-encoding=EUC-JP

<web-app>
    :
  <locale-encoding-mapping-list>
    <locale-encoding-mapping>
      <locale>ja</locale>
      <encoding>windows-31j</encoding>  
    </locale-encoding-mapping>
    <locale-encoding-mapping>
      <locale>ko</locale>
      <encoding>EUC-KR</encoding>
    </locale-encoding-mapping>
  </locale-encoding-mapping-list>
    :

    :
((HttpServletResponse)response).
        setContentType("text/html; charset=Shift_JIS")
    :

JSPファイルのコンパイル

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

<nec-web-app>
    :
  <jsp-config>
    <property name="priorityJspInEncoding" value="EUC-JP"/>
  </jsp-config>
    :

otxadmin> set server.web-container
.property.priority-jsp-in-encoding=EUC-JP

<%@ page pageEncoding="windows-31j"%>
      :

<%@ page contentType="text/html;charset=windows-31j"%>
      :

<web-app>
    :
  <jsp-config>
    <jsp-property-group>
      <url-pattern>/jsp/*</url-pattern>
      <page-encoding>Shift_JIS</page-encoding>  
    </jsp-property-group>
  </jsp-config>
    :

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

JSPファイルのレスポンス

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

<nec-web-app>
    :
  <jsp-config>
    <property name="priorityJspOutEncoding" value="EUC-JP"/>
  </jsp-config>
    :

otxadmin> set server.web-container
.property.priority-jsp-out-encoding=EUC-JP

<%@ page contentType="text/html;charset=windows-31j"%>
      :

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

1.4.9. 使用可能文字について

1.4.9.1. URL

RFC3986仕様より、URL 中に書くことが許されているのは、半角アルファベット、数字と以下の(半角)記号です

またURLのコンテキスト名以降の各パーツで使用可能な文字を記述します。

http://<server名>:<ポート名>/<コンテキスト名>/<パス>/<サーブレット名>?<パラメータ>

1. コンテキスト名
   Webアプリケーションを配備する際に指定したコンテキストルートに相当する部分です。
   "/hoho1/hoho2"のようにスラッシュで区切って設定することも可能ですが、セッションレプリケーションを利用できないなど制限があります。詳細は [全般 > 注意制限事項 > 3. Webコンテナ > 3.1. 注意事項] を参照してください。また、"/hoho1/."のようにピリオド区切り(/)間をピリオドのみで構成することはできません。
   
   

   半角アルファベット、数字と以下の(半角)記号が使用可能です。
   

   . $ ! ~ - _ ( )

   
   
   
2. サーブレット名
   web.xmlに記述する<servlet-mapping>の<url-pattern>に相当します。"/abc/Servlet1"のようにスラッシュで区切って設定することも可能です。
   アクセスする際は、コンテキスト名"/hoho1/hoho2"、サーブレット名"/abc/Servlet1"と設定した場合
   　　http://server:port/hoho1/hoho2/abc/Servlet1
   のようにアクセスします。
   

   半角アルファベット、数字と以下の(半角)記号が使用可能です。
   

   . $ , : = ! * ~ @ - _ ( ) [ ]

   
   
   
3. パス
   Webアプリケーション内のディレクトリ構成に相当します。
   

   半角アルファベット、数字と以下の(半角)記号が使用可能です。
   

   . $ , ! ~ @ - _ ( ) [ ]

   
   
   
4. ファイル名
   htmlやjspのファイル名です。
   

   半角アルファベット、数字と以下の(半角)記号が使用可能です。
   

   . $ , & = ! ~ @ - _ ( ) [ ]

   
   
   
   
5. パラメータ
   パラメータ名には、半角アルファベット、数字と以下の(半角)記号が使用可能です。
   ※２バイト文字を使用する場合はエンコードした形式(%XX)にする必要があります。通常はブラウザが自動的にエンコードしてくれます。
   

   . $ , ; : ? ! * ~ @ - _ ( ) [ ]

   
   パラメータの値には、半角アルファベット、数字と以下の(半角)記号が使用可能です。
   ※２バイト文字を使用する場合はエンコードした形式(%XX)にする必要があります。通常はブラウザが自動的にエンコードしてくれます。
   

   . $ , ; : = ? ! * ~ @ - _ ( ) [ ]

   
   

1.4.9.2. アカウント／パスワード

Webにおける認証(Basic/Form認証等)に使用するアカウント／パスワードについて記述します。

1. アカウント
   利用可能な文字は英数字と “-“、”_”です。
   
   
2. パスワード
   英数字と記号が利用できますが、「\」、「”」文字は利用できません。
   

1.4.9.3. XMLファイル

要素名、属性名の使用可能文字はXMLの仕様に従います。値にも次の文字は使用できません。

• 要素の値に使えない文字
  

• < & >

• 属性の値に使えない文字
  

• < & > " '

1.4.10. 配備記述子強制設定について

Webアプリケーション内の配備記述子（web.xml、nec-web.xml、web-fragment.xml）で設定された設定値を上書きします。本機能を利用することによりWebアプリケーションを再作成することなく、変更した配備記述子の設定でWebアプリケーションを動作させることができます。

1.4.10.1. 配備記述子強制設定機能を有効にする設定方法

配備記述子強制設定機能を利用するためには、次のJavaシステムプロパティを設定してください。

com.nec.webotx.enterprise.web.WebContainer.overrideWebxml=true

Javaシステムプロパティの設定方法については、「1.4.2.3.JavaVMオプションで設定可能な項目一覧」を参照してください。

1.4.10.2. 配備記述子の強制設定方法

配備記述子の強制設定は、domain.xml の deployment-config要素に登録されている強制設定情報(param要素)に従って行われます。
配備記述子の設定変更を反映するには、次の手順で行います。

1. 配備記述子強制設定情報の登録
2. Webアプリケーションのリロード

(1)配備記述子強制設定情報の登録

次の運用管理コマンド(otxadmin)を利用することで domain.xml の強制設定情報の登録、削除、参照を行うことができます。コマンドの詳細については「リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.2. 運用管理コマンド(otxadmin)」を参照してください。

set-web-param
unset-web-param
list-web-params

強制設定情報の登録

強制設定情報を domain.xml に登録するには set-web-param コマンドを利用します。
set-web-param コマンドの実行例を次に示します。

otxadmin> set-web-param --file web.xml --type update --elementname servlet/servlet-class --elementvalue className examples

上記の実行例のコマンドを実行することで、domain.xml の deployment-config要素には次の param要素が登録されます。

強制設定情報の削除

強制設定情報を domain.xml から削除するには unset-web-param コマンドを利用します。
unset-web-param コマンドの実行例を次に示します。

otxadmin> unset-web-param --file web.xml --type update --elementname servlet/servlet-class examples

上記の実行例のコマンドを実行することで、domain.xml の deployment-config要素に登録されている param要素が削除されます。コマンド実行前と実行後の domain.xml の内容を以下に示します。

強制設定情報の参照

domain.xml に登録されている強制設定情報を参照するには list-web-params コマンドを利用します。
list-web-params コマンドの実行例を次に示します。

otxadmin> list-web-params

上記の実行例のコマンドを実行することで、domain.xml の deployment-config要素に登録されている全ての param要素を表示することができます。

(2)Webアプリケーションのリロード

domain.xml に設定されている強制設定情報を配備記述子に反映するには、Webアプリケーションのリロードが必要なります。Webアプリケーションのリロード方法を次に示します。

Caution
Webアプリケーションのリロードを行っていない場合、domain.xml に強制設定情報が登録されていても、Webアプリケーションの配備記述子は更新されず、従来の動作のままとなります。

Web版統合運用管理コンソールを利用する場合

1. Web版統合運用管理コンソールへの接続

   Webブラウザを起動し、Web版統合運用管理コンソールへ接続します。"http://<host>:<port>/manager/"に接続してください。
   ※domain1のポート番号の既定値は 5858 です。

2. Webアプリケーションの再起動

   管理コンソールの左側のツリーで「アプリケーション」-「Webモジュール」を選択します。
   リロード対象のWebアプリケーションの停止ボタンをクリックし、停止した後に起動ボタンをクリックしてWebアプリケーションを起動してください。

   以上でWebアプリケーションのリロードは完了です。

運用管理コマンド(otxadmin)を利用する場合

次のように、invoke コマンドを利用することによりWebアプリケーションをリロードすることができます。

otxadmin> invoke server.web-container.reloadAllModules

配備記述子強制設定機能の注意事項

配備記述子の強制設定を行う上での注意点を以下に記載しています。

1. 配備記述子の次の要素については、強制設定の対象外になります。

   env-entry要素
   ejb-ref要素
   ejb-local-ref要素
   context-root要素

2. 配備記述子の設定変更はドメインの再起動、Webコンテナの再起動を行うことでも反映させることができますが、配備記述子の jsp-config要素配下の値に対して設定変更を行う場合には「(2)Webアプリケーションのリロード」で記載しているWebアプリケーションのリロードを行ってください。

   Caution
   jsp-config要素の設定変更を反映させるにはjspの再コンパイルが必要になります。しかしドメインの再起動、Webコンテナの再起動ではjspの再コンパイルは行わないため、Webアプリケーションのリロードが必要になります。

3. set-web-param コマンドを実行する際に次のオプションとオペランドである context-root の値がdomain.xml に登録されている param要素の値と完全一致する場合、一致している param要素の内容を更新します。

   ・fileオプション
   ・typeオプション
   ・paramtargetオプション
   ・elementnameオプション
   ・propertynameオプション
   ・attributenameオプション

   例えば elementvalue オプションの値のみが異なる set-web-param コマンドを続けて実行した場合、後に実行したコマンドの情報で最初に実行したコマンドの情報を上書きします。
   set-web-param コマンドとコマンド実行後の domain.xml の例を次に示します。

   set-web-param コマンド

   otxadmin> set-web-param --file web.xml --type update --elementname servlet/servlet-class --elementvalue className examples
   コマンド set-web-param は正常に実行されました。
   otxadmin> set-web-param --file web.xml --type update --elementname servlet/servlet-class --elementvalue newClassName examples
   コマンド set-web-param は正常に実行されました。
   

   domain.xml のdeployment-config要素

   <deployment-config> 　<param param-target="" context-root="examples" element-name="servlet/servlet-class" element-value="newClassName" file="web.xml" attribute-value="" property-name="" property-value="" attribute-name="" type="update"></param> </deployment-config>