WebOTX Manual V10.2 (第4版) 目次を表示

---

4. Webコンテナ

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

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

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

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

運用管理コンソールでは各種情報の設定ができます。なお運用管理コンソールの使い方と詳細については、「操作方法 > 運用管理コンソール」を参照してください。

MOによる参照と設定

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

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

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.cross-context=true

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

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

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

otxadmin> set  server.web-container.property.priority-jsp-in-encoding=windows-31j

otxadmin> set  server.web-container.property.priority-jsp-out-encoding=windows-31j

otxadmin> set  server.web-container.property.priority-response-encoding=windows-31j

Dottedname : server.web-container.plugin-config

!<設定値1>=*
!<設定値2>=*
...

Dottedname : server.web-container.current-version-config.current-version.<コンテキストルート名>

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

Dottedname : server.http-service

otxadmin> set server.http-service.virtual-server.server.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.<バーチャルサーバ名>

Dottedname : server.http-service.virtual-server.<バーチャルサーバ名>.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.<ネットワークリスナ名>

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

WebOTX V9よりHTTPリスナの設定を変更しています。設定はtransport、protocol、thread-poolに分散して行い、それぞれを選択することでHTTPリスナを定義します。また種類の異なる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.<トランスポート名>

Dottedname : server.network-config.protocols.protocol.<プロトコル名>

Dottedname : server.network-config.protocols.protocol.<プロトコル名>.http

otxadmin> set server.network-config.protocols.protocol.http-protocol.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.<プロトコル名>.http.property

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

otxadmin> set server.network-config.protocols.protocol.http-protocol.http.property.server="Application Server"

Dottedname : server.thread-pools.thread-pool.<スレッドプール名>

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

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

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

*2) 一部の項目は、旧バージョンと同様にシステムプロパティでも設定することが可能です。「 JavaVMオプションで設定可能な項目一覧」を参照してください。

Dottedname : server.network-config.protocols.protocol.<プロトコル名>.ssl

Dottedname : server.applications.web-module.<アプリケーション名>.module.<Webモジュール名>.engine.web.web-module-config

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

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

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

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

4.2.2. プロセスグループ(アプリケーションをプロセスグループに配備した場合のみ)の環境変数で設定可能な項目一覧

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

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システムプロパティ」の欄に設定を記述してください。
「名前」に項目名を記述し、「値」に指定する値を記述してください

設定例：

設定項目一覧

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 属性に設定します。

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

4.3.1.1. 運用手順

(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) 設定の反映

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

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

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

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

WebOTXには、Webアプリケーションが配備されたことを自動的に　WebOTX WebServer / Apache HTTP Server / IIS などの外部Webサーバに反映させる仕組みがあり、デフォルトではこの機能が有効になっています。　この機能により、ドメインを再起動することなく新規に配備されたWebアプリケーションの存在を外部Webサーバに認識させています。そのため運用中にWebアプリケーションを追加する事が無い場合は無効にすることもできます。

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

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

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

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

1. 運用管理コンソールへの接続

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

2. 設定の変更

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

3. Webサーバの再起動

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

B: 手動での設定手順

分離トポロジのWebサーバ等の理由で運用管理コンソールを利用した設定手順が行えない場合は、以下の手順で手動設定を行ってください。

1. 外部Webサーバの停止
2. Webサーバプラグイン定義ファイルの設定
   
   • IISの場合

     ${INSTANCE_ROOT}/config/WebCont/isapi_redirect.properties の次のプロパティをoffにしてください。

     dynamic_reflection=off

   • WebOTX Webサーバ または Apache HTTP Serverの場合

     ${INSTANCE_ROOT}/config/WebCont/mod_jk-24.conf の次のディレクティブをoffにしてください。

     JkDynamicReflection off

   
   
   
3. 外部Webサーバの起動
   

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

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

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

Webサーバプロセスの起動直後にのみ動的反映を行いますので、WebOTX WebServer / Apache HTTP Server を使用している場合は起動直後に、IISを使用している場合は初回リクエスト時に動的反映を行います。

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

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

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

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

1. 運用管理コンソールへの接続

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

2. 設定の変更

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

3. Webサーバの再起動

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

B: 手動での設定手順

分離トポロジのWebサーバ等の理由で、運用管理コンソールを利用した設定手順が行えない場合は、以下の手順で手動設定を行ってください。

1. 外部Webサーバの停止
2. Webサーバプラグイン定義ファイルの設定
   
   • IISの場合

     ${INSTANCE_ROOT}/config/WebCont/isapi_redirect.properties の次のプロパティをonceにしてください。

     dynamic_reflection=once

   • WebOTX Webサーバ または Apache HTTP Serverの場合

     ${INSTANCE_ROOT}/config/WebCont/mod_jk-24.conf の次のディレクティブをonceにしてください。

     JkDynamicReflection once

   
   
   
3. 外部Webサーバの起動
   

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

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

以下はWebサーバプラグイン共通の設定項目一覧です。

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

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

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

連携設定項目：isapi_redirect.properties

連携設定項目：uriworkermap.properties

コンテキストとworkerのマッピングを定義するファイルです。

/abc/servlet=$(default.worker)

/abc/*=$(default.worker)

/abc/*.do=$(default.worker)

!*.html=$(default.worker)

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

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

設定方法

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

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

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

2. 設定

   ${INSTANCE_ROOT}/config/WebCont/mod_jk-**.conf の 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" agent-ajp
     　JkMount "/aaa/*" agent-ajp
     　･･･
     　</VirtualHost>

   • バーチャルホストB

     <VirtualHost *:8080>
     　JkMount "/bbb" agent-ajp
     　JkMount "/bbb/*" agent-ajp
     　･･･
     　</VirtualHost>

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

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

4.5. 運用管理コンソールを利用したプラグインの設定方法

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

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

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

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

4.5.1. 運用管理コンソールから設定可能な項目

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

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

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

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

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

プラグインの動的反映オプションやプラグインのログのローテーション、コネクションプールサイズの設定を行う方法を説明します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cookieによるセッション管理

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

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

URLRewritingによるセッション管理

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

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

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

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

4.6.2. WebOTXの基本的な設定

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

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

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

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

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

  
  

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

• 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アーカイブに格納しておいてください。

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

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

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);
    :

4.6.2.3. セッション情報の保存

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

※ アプリケーションをプロセスグループに配備した場合、セッションの保存方法には制限が存在します。 詳細は「 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の高度な設定(アプリケーションをプロセスグループに配備した場合の設定) > アプリケーションをプロセスグループに配備した場合のセッション情報保存」 を参照してください。

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

セッションはメモリ、ファイル両方に展開されます。メモリ上で管理されているセッション情報を一定間隔(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の高度な設定(アプリケーションをプロセスグループに配備した場合の設定) > アプリケーションをプロセスグループに配備した場合のセッション情報保存」 を参照してください。

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

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

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

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

4.6.2.5. セッションの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>
      :

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

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

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

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

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

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

4.6.2.8. jvmRouteオプションの設定

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

  -DjvmRoute="hoho1"

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

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

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

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

4.6.2.10. セッション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>
      :

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

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

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

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

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

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

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

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

  <web-app>
      :
    <distributable/>
      :

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

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

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

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

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

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

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

  
  

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

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

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

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

• 即時同期・同期モードの場合
  
  セッション情報・セッション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データソースの登録」を実行します。
  
  

  
  

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

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

4.6.4. WebOTXの高度な設定(アプリケーションをプロセスグループに配備した場合の設定)

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

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

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

4.6.4.1. アプリケーションをプロセスグループに配備した場合のセッションID

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

※ アプリケーションをエージェントプロセスに配備した場合はプロセスIDが付加されることはありません

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

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

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

4.6.4.2. アプリケーションをプロセスグループに配備した場合のセッション情報保存

アプリケーションをプロセスグループに配備した場合、構成によりセッション情報の保存方法に制限が存在します。

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

4.6.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は別となります。

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

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

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

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

4.7.2.1. 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>
    :

4.7.2.2. 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")
    :

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

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

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

4.8.1. URL

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

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

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

1. コンテキスト名
   Webアプリケーションを配備する際に指定したコンテキストルートに相当する部分です。
   "/hoho1/hoho2"のようにスラッシュで区切って設定することも可能ですが、セッションレプリケーションを利用できないなど制限があります。詳細は [全般 > 注意制限事項 > 3. Webコンテナ > 注意事項] を参照してください。また、"/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)にする必要があります。通常はブラウザが自動的にエンコードしてくれます。
   

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

   
   

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

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

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

4.8.3. XMLファイル

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

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

• < & >

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

• < & > " '

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

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

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

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

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

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

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

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

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

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

次の運用管理コマンド(otxadmin)を利用することで domain.xml の強制設定情報の登録、削除、参照を行うことができます。コマンドの詳細については [ リファレンス > コマンドリファレンス > 運用管理コマンド(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要素を表示することができます。

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

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

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

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

1. 運用管理コンソールへの接続

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

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

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

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

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

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

otxadmin> invoke server.web-container.reloadAllModules

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

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

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>

4.10. Webコンテナと連携するWebサーバを切り替える方法

Caution
今まで利用していたWebサーバを別のWebサーバへ切り替える場合に本設定を行ってください。

静的コンテンツの処理と動的コンテンツの処理を別マシンや別プロセスに分離できるよう、以下のWebサーバと連携することが可能です。

• WebOTX Webサーバ
• Apache HTTP Server
• Microsoft Internet Information Services (IIS)

連携可能なWebサーバの詳細は、 [インストールガイド] の各OSのインストールガイドを参照してください。

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

Webサーバ/Webコンテナを同一マシンで構成することを「共存トポロジー」と呼びます。また、Webサーバ/Webコンテナを異なるマシンで構成することを「分離トポロジー」と呼びます。

4.10.1. Javaベースの内蔵Webサーバから外部Webサーバへ切り替える場合

4.10.1.1. Webコンテナの設定作業

Caution
共存トポロジーまたは分離トポロジーのWebコンテナで実施する作業です。

Javaベースの内蔵Webサーバを使用する設定から、WebOTX Webサーバ、Apache HTTP ServerまたはIIS等の外部Webサーバを使用する設定に変更します。

1. ドメインの設定変更

   以下のコマンドを実行してください。連携設定を行うドメインが複数存在する場合は、ドメインごとに実行してください。

   AS Expressの場合
   

   otxadmin> set server.http-service.virtual-server.server.network-listeners=agent-ajp-listener
   otxadmin> set server.network-config.network-listeners.network-listener.agent-ajp-listener.enabled=true
   otxadmin> set server.network-config.network-listeners.network-listener.http-listener-1.enabled=false
   otxadmin> set server.network-config.network-listeners.network-listener.http-listener-2.enabled=false

   AS Standardの場合
   

   otxadmin> set server.http-service.virtual-server.server.network-listeners=agent-ajp-listener,tpsystem-ajp-listener
   otxadmin> set server.network-config.network-listeners.network-listener.agent-ajp-listener.enabled=true
   otxadmin> set server.network-config.network-listeners.network-listener.tpsystem-ajp-listener.enabled=true
   otxadmin> set server.network-config.network-listeners.network-listener.http-listener-1.enabled=false
   otxadmin> set server.network-config.network-listeners.network-listener.http-listener-2.enabled=false

2. ドメインの再起動

4.10.1.2. 初期設定ツールの実行

Caution
共存トポロジーまたは分離トポロジーのWebサーバで実施する作業です。

[初期設定ツールの利用方法] を参照して、新しく連携するWebサーバの連携設定を行います。

4.10.2. 外部WebサーバからJavaベースの内蔵Webサーバへ切り替える場合

4.10.2.1. Webコンテナの設定作業

Caution
共存トポロジーまたは分離トポロジーのWebコンテナで実施する作業です。

WebOTX Webサーバ、Apache HTTP ServerまたはIIS等の外部Webサーバを使用する設定からJavaベースの内蔵Webサーバを使用する設定に変更します。

1. ドメインの設定変更

   以下のコマンドを実行してください。連携設定を行うドメインが複数存在する場合は、ドメインごとに実行してください。

   otxadmin> set server.http-service.virtual-server.server.network-listeners=http-listener-1,http-listener-2
   otxadmin> set server.network-config.network-listeners.network-listener.agent-ajp-listener.enabled=false
   otxadmin> set server.network-config.network-listeners.network-listener.tpsystem-ajp-listener.enabled=false
   otxadmin> set server.network-config.network-listeners.network-listener.http-listener-1.enabled=true (※HTTPを利用する場合のみ)
   otxadmin> set server.network-config.network-listeners.network-listener.http-listener-2.enabled=true (※HTTPSを利用する場合のみ)

2. ドメインの再起動

4.10.2.2. Webサーバの連携設定の削除

Caution
共存トポロジーまたは分離トポロジーのWebサーバで実施する作業です。

[Webサーバ連携設定の削除方法] を参照して、今まで利用していたWebサーバの連携設定を手動で削除します。

4.10.3. 外部Webサーバから別の外部Webサーバへ切り替える場合

4.10.3.1. 初期設定ツールの実行

Caution
共存トポロジーまたは分離トポロジーのWebサーバで実施する作業です。

[初期設定ツールの利用方法] を参照して、新しく連携するWebサーバの連携設定を行います。

4.10.3.2. Webサーバの連携設定の削除

Caution
共存トポロジーまたは分離トポロジーのWebサーバで実施する作業です。

[Webサーバ連携設定の削除方法] を参照して、今まで利用していたWebサーバの連携設定を手動で削除します。

4.10.4. 初期設定ツールの利用方法

初期設定ツールはWebサーバに対するプラグインの設定を行います。そのため共存トポロジーまたは分離トポロジーのWebサーバで行います。

Caution
初期設定ツールで初期設定を行うと以下のファイルが初期化されますので、必要なファイルはバックアップを取っておいてください。

${INSTANCE_ROOT}/config/WebCont (ドメインが無い場合は、${連携設定ディレクトリ}/config/WebCont) 配下

• workers.properties
• uriworkermap.properties
• isapi_redirect.properties (IISとの連携を初期設定した場合のみ)
• mod_jk-24.conf (WebOTX Webサーバ 2.4またはApache HTTP Server 2.4との連携を初期設定した場合のみ)

4.10.4.1. 対話形式での初期設定

Windowsで動作するWebサーバの場合

1. 共存トポロジーの場合は連携設定の対象となるドメインが停止していることを確認します。以下のコマンドを実行してください。

   otxadmin> list-domains

   起動状態の場合、以下のコマンドで停止してください。

   otxadmin> stop-domain <ドメイン名>

2. 連携対象の外部Webサーバを停止してください。
   
   
3. 外部Webサーバに対してWebOTXと連携設定を行います。 この操作は、初期設定ツールを使用します。
   (分離トポロジーの場合、この作業は外部Webサーバが動作するマシン上で行います)
   
   [スタート]-[プログラム]-[WebOTX]-[初期設定ツール]メニューを選択し、ツールを起動します。
   起動された初期設定ツール画面に情報を入力して、WebコンテナとWebサーバとの連携設定を行っていきます。
   複数のドメインが存在する場合、この設定はドメイン毎に設定します。

   Webコンテナの構成

   
   

   表2.3.1.4-3

   設定項目		説明
   共存トポロジ(同一のマシンに存在)		WebコンテナとWebサーバが同じマシン上に存在する場合に選択します。
   分離トポロジ(別々のマシンに存在)		WebコンテナとWebサーバが別々のマシン上に存在する場合に選択します。
   連携するドメインのホスト名またはアドレス名		分離トポロジのWebコンテナが動作するホスト名またはIPアドレスを入力します。 ※分離トポロジを選択した場合にのみ入力可能になります。
   連携するWebOTXのエディション	Express	分離トポロジのWebコンテナがAS Expressの場合に選択します。 ※分離トポロジを選択した場合にのみ入力可能になります。
   	Standard	分離トポロジのWebコンテナがAS Standardの場合に選択します。 ※分離トポロジを選択した場合にのみ入力可能になります。

   Webサーバの構成

   
   

   表2.3.1.4-3

   設定項目		説明
   種別	WebOTX Web Server 2.4	WebOTX Web Server 2.4 に連携設定する場合に選択します。(既定値)
   	Apache HTTP Server 2.4	Apache HTTP Server 2.4 に連携設定する場合に選択します。
   	Internet Information Servers(IIS)	Internet Information Servers(IIS) に連携設定する場合に選択します。
   インストールディレクトリ		「種別」「Apache HTTP Server 2.4」を選択した場合、Apache HTTP Server 2.4のインストールディレクトリを指定します。 「WebOTX Web Server 2.4」または「Internet Information Services (IIS)」を選択した場合、指定する必要はありません。 以下に「Apache HTTP Server 2.4」を選択する場合の指定例を示します。 C:\Apache24
   IISサイト名		IISを使用する場合には、連携させるIISサイト名を指定します。

   連携設定ファイルの生成先情報

   
   

   表2.3.1.4-3

   設定項目		説明
   ドメインディレクトリ		Webサーバと連携するWebコンテナのドメインを指定します。 ドメインの指定例を次に示します。 C:\WebOTX\domains\domain1 分離トポロジのWebサーバでドメインが存在しない場合は配下に "config\WebCont"ディレクトリを作成するディレクトリを指定します。 ディレクトリの指定例を次に示します。(この場合、C:\WebOTX\config\WebCont が作成されその配下に連携設定に必要なファイルが生成されます) C:\WebOTX

   連携ポート番号情報

   
   

   表2.3.1.4-3

   設定項目		説明
   エージェントのAJPリスナポート番号		エージェントプロセスのWebコンテナとWebサーバとの連携に使用するポート番号を指定します。 domain1の既定値は「8099」です。 エージェントプロセスのWebコンテナを使用しない場合はチェックを外します。
   TPシステムのAJPリスナポート番号		TPシステムのWebコンテナとWebサーバとの連携に使用するポート番号を指定します。 domain1の既定値は「20102」です。 TPシステムのWebコンテナを使用しない場合はチェックを外します。

   コンテキスト名動的反映オプション

   
   

   表2.3.1.4-3

   設定項目		説明
   定期的に行う		コンテキストの情報を定期的に問い合わせます。Webアプリケーションを新規に配備した後、Webサーバを再起動する必要がありません。(既定値)
   動的反映間隔		コンテキストの情報を定期的に問い合わせる間隔を秒単位で指定します。既定値は60秒です。
   行わない		コンテキストの情報の問い合わせを行いません。Webアプリケーションを新規に配備した後、Webサーバを再起動する必要があります。 本番環境のようにWebアプリケーションの配備・配備解除を頻繁に行わない環境ではこの設定を推奨します。(*1) ※分離トポロジにて指定する場合は別途 uriworkermap.propertiesファイルにコンテキストのマッピング定義を手動で定義する必要があります。
   Webサーバ起動時の1回のみ行う		Webサーバ起動後、Webアプリケーションに最初にアクセスする時、動的反映を１回だけ行います。 この場合、新規に配備したWeb アプリケーションを外部Web サーバに認識させるには、Webサーバの再起動が必要です。

   *1 動的反映の処理では現在配備されているコンテキスト名の最新情報を定期的にWebコンテナへ問い合わせます。

   
   
   「OK」ボタンを押下して設定を完了すると、Webコンテナの各種定義ファイル、および Webサーバの設定ファイルに設定情報を反映します。 「キャンセル」ボタンを押下すると反映せずにツールを終了します。
   

   Caution
   初期設定ツールで初期設定に失敗した場合、エラー情報は ${INSTALL_ROOT}/logs/setinfo_operetion.log に出力されます。このファイル内容を開発部門にお問い合わせください。

   
   

Linux, HP-UXで動作するWebサーバの場合

1. 共存トポロジーの場合は連携設定の対象となるドメインが停止していることを確認します。以下のコマンドを実行してください。

   otxadmin> list-domains

   起動状態の場合、以下のコマンドで停止してください。

   otxadmin> stop-domain <ドメイン名>

2. 連携対象の外部Webサーバを停止してください。
   
   
3. 外部Webサーバに対してWebOTXと連携設定を行います。 この操作は初期設定ツールを使用します。
   (分離トポロジーの場合、この作業は外部Webサーバが動作するマシン上で行います)
   
   ${AS_INSTALL}/bin/setconf.sh を実行します。
   

   $ cd ${AS_INSTALL}/bin
   $ ./setconf.sh

   コンソールに情報を入力して、WebコンテナとWebサーバとの連携設定を行っていきます。
   複数のドメインが存在する場合、この設定はドメイン毎に設定します。

   Webコンテナの構成

   Please enter topology of the web server and the Web Container.[1]
      1. Coexistence topology.
      2. Separation topology.

   表2.3.1.4-3

   設定項目		説明
   1. Coexistence topology.		WebコンテナとWebサーバが同じマシン上に存在(共存トポロジ)する場合に選択します。
   2. Separation topology.		WebコンテナとWebサーバが別々のマシン上に存在(分離トポロジ)する場合に選択します。

   Please enter host name or IP address of the Web Container to be connected.

   表2.3.1.4-3

   設定項目		説明
   連携するドメインのホスト名またはアドレス名		分離トポロジのWebコンテナが動作するホスト名またはIPアドレスを入力します。 ※分離トポロジを選択した場合にのみ入力可能になります。

   Please enter type of WebOTX AS where a Web Container runs.[2]
       1. Express
       2. Standard

   表2.3.1.4-3

   設定項目		説明
   連携するWebOTXのエディション	1. Express	分離トポロジのWebコンテナがAS Expressの場合に選択します。 ※分離トポロジを選択した場合にのみ入力可能になります。
   	2. Standard	分離トポロジのWebコンテナがAS Standardの場合に選択します。 ※分離トポロジを選択した場合にのみ入力可能になります。

   Webサーバの構成

   Please select Web server.[1]
      1. WebOTX Web Server 2.4
      2. Apache HTTP Server 2.4

   表2.3.1.4-3

   設定項目		説明
   種別	1. WebOTX Web Server 2.4	WebOTX Web Server 2.4 に連携設定する場合に選択します。(既定値)
   	2. Apache HTTP Server 2.4	Apache HTTP Server 2.4 に連携設定する場合に選択します。

   Please enter web server installation directory.
   []

   表2.3.1.4-3

   設定項目		説明
   Webサーバのインストールディレクトリ		「種別」「Apache HTTP Server 2.4」を選択した場合、Apache HTTP Server 2.4のインストールディレクトリを指定します。 以下に「Apache HTTP Server 2.4」を選択する場合の指定例を示します。 /opt/Apache24

   連携設定ファイルの生成先情報

   Please enter a domain directory.[/opt/WebOTX/domains/domain1]

   表2.3.1.4-3

   設定項目		説明
   ドメインディレクトリ		Webサーバと連携するWebコンテナのドメインを指定します。 ドメインの指定例を次に示します。 /opt/WebOTX/domains/domain1 分離トポロジのWebサーバでドメインが存在しない場合は配下に "config/WebCont"ディレクトリを作成するディレクトリを指定します。 ディレクトリの指定例を次に示します。(この場合、/opt/WebOTX/config/WebCont が作成されその配下に連携設定に必要なファイルが生成されます) /opt/WebOTX

   連携ポート番号情報

   Please enter port for communication with WebOTX Web Container on the Agent.[8099]
   (Please enter 0 when not using.)
   
   Please enter port for communication with WebOTX Web Container on the TP System.[20102]

   表2.3.1.4-3

   設定項目		説明
   エージェントのAJPリスナポート番号		エージェントプロセスのWebコンテナとWebサーバとの連携に使用するポート番号を指定します。 domain1の既定値は「8099」です。 エージェントプロセスのWebコンテナを使用しない場合は0を入力します。
   TPシステムのAJPリスナポート番号		TPシステムのWebコンテナとWebサーバとの連携に使用するポート番号を指定します。 domain1の既定値は「20102」です。

   コンテキスト名動的反映オプション

   Please select context name dynamic reflection option of Web application.[1]
      1. Dynamic reflection option is on.
      2. Dynamic reflection option is once.
      3. Dynamic reflection option is off.

   表2.3.1.4-3

   設定項目		説明
   1. Dynamic reflection option is on.		コンテキストの情報を定期的に問い合わせます。Webアプリケーションを新規に配備した後、Webサーバを再起動する必要がありません。
   2. Dynamic reflection option is once.		Webサーバ起動後、動的反映を１回だけ行います。 この場合、新規に配備したWeb アプリケーションを外部Web サーバに認識させるには、Webサーバの再起動が必要です。
   3. Dynamic reflection option is off.		コンテキストの情報の問い合わせを行いません。Webアプリケーションを新規に配備した後、Webサーバを再起動する必要があります。 本番環境のようにWebアプリケーションの配備・配備解除を頻繁に行わない環境ではこの設定を推奨します。(*1) ※分離トポロジにて指定する場合は別途 uriworkermap.propertiesファイルにコンテキストのマッピング定義を手動で定義する必要があります。

   *1 動的反映の処理では現在のコンテキストの状況を定期的にWebコンテナへ問い合わせます。

   
   
   

   The following information has been set.
     Topology of the web server and the Web Container:Coexistence
     Host name or address of the domain which cooperates:localhost
     WebOTX Web Container installation directory:/opt/WebOTX
     Domain directory:/opt/WebOTX/domains/domain1
     Web server:WebOTX Web Server 2.4
   
     Web server installation directory:/opt/WebOTX/WebServer24
     Port for communication with WebOTX Web Container on the Agent:8099
     Port for communication with WebOTX Web Container on the TP System:20102
     Web server plugin dynamic reflection option:on
   Would you like to continue?(y/n)

   "y"を入力してEnterキーを押下すると、Webコンテナの各種定義ファイル、および Webサーバの設定ファイルに設定情報を反映します。 "n"を入力してEnterキーを押下すると、反映せずにスクリプトを終了します。

4.10.4.2. バッチでの初期設定

プロパティファイルを作成して初期設定ツールの起動オプションに "-b <プロパティファイル名>"を指定して実行する事によってバッチでの初期設定が可能になります。 実行方法とプロパティの説明を行います。

実行方法

• Windowsの場合

  > cd ${AS_INSTALL}\bin
  > SetInfo.exe -b <プロパティファイル名>

• Linux, HP-UXの場合

  # cd ${AS_INSTALL}/bin
  # ./setconf.sh -b <プロパティファイル名>

プロパティ例

• 共存トポロジの場合
  • WebOTX Webサーバ 2.4を使用する場合
    

    domain.path=${連携設定を行うドメインのパス}
    domain.webserver.type=WebServer24
    web-plugin.topology=co-located
    web-plugin.dest.ajp.port=${エージェントプロセスのajpリスナのport番号(※1)}
    web-plugin.dest.tp-ajp.port=${TPシステムのajpリスナのport番号(※1)}

  • Apache HTTP Server 2.4 を使用する場合

    domain.path=${連携設定を行うドメインのパス}
    domain.webserver.type=Apache24
    domain.webserver.path=${Apache HTTP Server 2.4のインストールパス}
    web-plugin.topology=co-located
    web-plugin.dest.ajp.port=${エージェントプロセスのajpリスナのport番号(※1)}
    web-plugin.dest.tp-ajp.port=${TPシステムのajpリスナのport番号(※1)}

  • IIS を使用する場合

    domain.path=${連携設定を行うドメインのパス}
    domain.webserver.type=IIS
    web-plugin.topology=co-located
    web-plugin.dest.ajp.port=${エージェントプロセスのajpリスナのport番号(※1)}
    web-plugin.dest.tp-ajp.port=${TPシステムのajpリスナのport番号(※1)}
    web-plugin.iis.site.display-name=${IISのサイト名}

• 分離トポロジの場合
  • WebOTX Webサーバ 2.4を使用する場合
    

    domain.path=${連携設定を行うドメインのパス}
    domain.webserver.type=WebServer24
    web-plugin.topology=separate-web
    web-plugin.dest.host=${Webコンテナのホスト名}
    web-plugin.dest.ajp.port=${エージェントプロセスのajpリスナのport番号(※1)}
    web-plugin.dest.tp-ajp.port=${TPシステムのajpリスナのport番号(※1)}

  • Apache HTTP Server 2.4 を使用する場合

    domain.path=${連携設定を行うドメインのパス}
    domain.webserver.type=Apache24
    domain.webserver.path=${Apache HTTP Server 2.4のインストールパス}
    web-plugin.topology=separate-web
    web-plugin.dest.host=${Webコンテナのホスト名}
    web-plugin.dest.ajp.port=${エージェントプロセスのajpリスナのport番号(※1)}
    web-plugin.dest.tp-ajp.port=${TPシステムのajpリスナのport番号(※1)}

  • IIS を使用する場合

    domain.path=${連携設定を行うドメインのパス}
    domain.webserver.type=IIS
    web-plugin.topology=separate-web
    web-plugin.dest.host=${Webコンテナのホスト名}
    web-plugin.dest.ajp.port=${エージェントプロセスのajpリスナのport番号(※1)}
    web-plugin.dest.tp-ajp.port=${TPシステムのajpリスナのport番号(※1)}
    web-plugin.iis.site.display-name=${IISのサイト名}

※1 利用しない場合は 0 を指定します。

4.10.5. Webサーバ連携設定の削除方法

外部Webサーバと連携済みの環境でJavaベースの内部Webサーバに切り替えた場合は外部Webサーバの連携設定を削除してください。

• WebOTX Webサーバ 2.4 の場合
  

  ${INSTANCE_ROOT}/config/WebServer ディレクトリ配下にあるhttpd.confファイルをエディタで編集します。
  「# TM_WS_PLUGIN-start 」から「# TM_WS_PLUGIN-end」の記述を削除してください。
  

  # TM_WS_PLUGIN-start include "${INSTANCE_ROOT}/config/WebCont/mod_jk-24.conf" # TM_WS_PLUGIN-end

   
• Apache HTTP Server 2.4 の場合
  

  Apache HTTP Server 2.4インストールディレクトリ配下にある conf/httpd.conf ファイルをエディタで編集します。
  「# TM_WS_PLUGIN-start 」から「# TM_WS_PLUGIN-end」の記述を削除してください。
  

  # TM_WS_PLUGIN-start include "${INSTANCE_ROOT}/config/WebCont/mod_jk-24.conf" # TM_WS_PLUGIN-end

   
• IIS の場合
  

  IISのサイトにISAPIプラグインの設定が残っている場合は正常にIISが動作しない場合があります。
  古い設定が残っている場合はIISマネージャより削除を行ってください。IISマネージャは「管理ツール」-「インターネット インフォメーションサービス（IIS）マネージャ」より起動できます。

  • ISAPI および CGI の制限 の削除

    説明が「webcont」で登録されているISAPI および CGI の制限 を削除してください。

    1. 「管理ツール」-「インターネット インフォメーションサービス（IIS）マネージャ」を起動
    2. 左画面よりサーバーの管理ノードを選択
    3. 右画面より「ISAPI および CGI の制限」を選択
    4. ISAPI および CGI の制限の一覧で、連携していたドメインのパスがパス部分に含まれており、かつ説明が「webcont」の行を削除
    
    
  • 連携していたサイトの ISAPI フィルタの削除

    連携していたサイトの ISAPI フィルタに「<ドメイン名>_webcont」と登録されているISAPI フィルターを削除してください。

    1. 「管理ツール」-「インターネット インフォメーションサービス（IIS）マネージャ」を起動
    2. 左画面より連携するIISサイトを選択
    3. 右画面より「ISAPI フィルタ」を選択
    4. ISAPI フィルタの一覧で「<ドメイン名>_webcont」を削除
    
    
  • 連携していたサイトの仮想ディレクトリの設定

    連携していたサイトの仮想ディレクトリ「<ドメイン名>_webcont」を削除してください。

    1. 「管理ツール」-「インターネット インフォメーションサービス（IIS）マネージャ」を起動
    2. 左画面より連携するIISサイトの配下の「<ドメイン名>_webcont」の仮想ディレクトリを削除

4.11. HTTP/2の利用方法

Javaベースの内蔵WebサーバでHTTP/2を利用する場合は、現状のWebブラウザのHTTP/2実装がTLS 1.2を利用するため、HTTPSのリスナである"http-listener-2"を利用する必要があります。 "http-listener-2"はデフォルトではHTTP/2に対応していないため以下の設定変更が必要です。

4.11.1. HTTP/2に対応したprotocolへの変更

4.11.1.1. Javaバージョンが8または11の場合

1. "http-listener-2"の利用するprotocolをapr-http2-protocolに変更します。
   

   otxadmin> set  server.network-config.network-listeners.network-listener.http-listener-2.protocol=apr-http2-protocol

2. ドメインを再起動します。
   

4.11.1.2. Javaバージョンが11の場合

1. "http-listener-2"の利用するprotocolをnio-http2-protocolに変更します。
   

   otxadmin> set  server.network-config.network-listeners.network-listener.http-listener-2.protocol=nio-http2-protocol

2. ドメインを再起動します。