1. コンフィグレーション(設定一覧)

1.1. 各サービスの属性

WebOTXの各サービスで提供している属性の設定方法について説明します。属性はMOの属性として提供しています。属性値の取得・設定を行なうには次の方法があります。

• 統合運用管理ツールより設定
• 運用管理コマンド
• JMX APIを利用したプログラムより設定

1.1.1. サービス一覧

WebOTXで提供しているサービス一覧を以下に示します。なお各サービスの属性については各サービスの設定項目についてを参照ください。

• 運用管理エージェント
• HTTPサーバ
• Webコンテナ
• EJBコンテナ
• JNDIサービス
• JMS
• JDBCデータソース
• Transactionサービス
• Object Broker
• TPシステム
• OLF/TP Adapter
• Working Domain Coordinator
• データベースコントローラ
• 共通SSL
• Webサービス
• 分散管理サーバ

1.1.2. 統合運用管理ツールを利用しての設定

WebOTXAdministratorで提供しているWebOTX統合運用管理ツールよりGUI画面で設定を行なうことが出来ます。統合運用管理ツールの使用方法は、 「運用ツールガイド > 2. 統合運用管理ツール(WebOTX Administrator)」を参照してください。

1.1.3. 運用管理コマンドを利用しての設定

WebOTX実行環境(Express,Standard,Enterpriseの各エディション)およびWebOTX Administratorで提供している運用管理コマンドよりコマンドベースで設定を行なうことができます。設定方法の例については「4. 運用管理コマンドリファレンス > 4.2. 運用管理コマンド(otxadmin) > 4.2.1. 使用方法 > 4.2.1.1. 運用管理コマンドの使用例」を参照してください。

1.1.4. JMX APIを利用した設定

JMX APIを利用したJavaプログラムより設定を行なうことが出来ます。なおJMXを利用したプログラミングについては [ アプリケーション開発ガイド（共通） > 5. JMXアプリケーションの開発 ] を参照ください。また各MOについては、「2. MO定義リファレンス」を参照ください。

1.2. 運用管理エージェント

運用管理エージェントに関する設定について説明します。

1.2.1. 運用管理エージェント設定項目・設定方法

運用管理エージェントの設定項目については全てMO化されています。項目の設定方法については、「1.1. 各サービスの属性」を参照してください。

1.2.2. 運用管理エージェント設定項目一覧

Dottedname : domain

Dottedname : server.J2EEServer

Dottedname : server.admin-service

Dottedname : server.admin-service.das-config

Dottedname : server.admin-service.jmx-connector.system-option

Dottedname : server.admin-service.jmx-connector.system

Dottedname : server.internal-lifecycle-module.service-name

Dottedname : server.java-config

• 管理ドメイン(WebOTXAdmin)の場合
  

  -client, -Djava.awt.headless=true, -Djavax.management.builder.initial=com.nec.webotx.enterprise.v9.admin.AppServerMBeanServerBuilder, -XX:+UnlockDiagnosticVMOptions, -Djava.endorsed.dirs=${com.nec.webotx.installRoot}/modules/endorsed${path.separator}${com.nec.webotx.installRoot}/lib/endorsed, -Djava.security.policy=${com.nec.webotx.instanceRoot}/config/server.policy, -Djava.security.auth.login.config=${com.nec.webotx.instanceRoot}/config/login.conf, -Dcom.nec.webotx.enterprise.security.httpsOutboundKeyAlias=webotx, -Djavax.net.ssl.keyStore=${com.nec.webotx.instanceRoot}/config/keystore.jks, -Djavax.net.ssl.trustStore=${com.nec.webotx.instanceRoot}/config/cacerts.jks, -Djava.ext.dirs=${com.nec.webotx.javaRoot}/lib/ext${path.separator}${com.nec.webotx.javaRoot}/jre/lib/ext${path.separator}${com.nec.webotx.instanceRoot}/lib/ext, -DANTLR_USE_DIRECT_CLASS_LOADING=true, -Dcom.nec.webotx.enterprise.config.config_environment_factory_class=com.nec.webotx.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory, -Dosgi.shell.telnet.port=16666, -Dosgi.shell.telnet.maxconn=1, -Dosgi.shell.telnet.ip=127.0.0.1, -Dgosh.args=--nointeractive, -Dfelix.fileinstall.dir=${com.nec.webotx.installRoot}/modules/autostart/, -Dfelix.fileinstall.poll=5000, -Dfelix.fileinstall.log.level=2, -Dfelix.fileinstall.bundles.new.start=true, -Dfelix.fileinstall.bundles.startTransient=true, -Dfelix.fileinstall.disableConfigSave=false, -Dlog4otx.configuration=file:///${com.nec.webotx.instanceRoot}/config/log4otx.xml, -Djava.util.logging.config.file=${com.nec.webotx.instanceRoot}/config/logging.properties, -Djava.util.logging.manager=com.nec.webotx.logging.WebOTXLogManager, -Dsun.lang.ClassLoader.allowArraySyntax=true

  
  
• ユーザドメインの場合
  

  -server, (*1) -Djava.awt.headless=true, -Djavax.management.builder.initial=com.nec.webotx.enterprise.v9.admin.AppServerMBeanServerBuilder, -XX:+UnlockDiagnosticVMOptions, -Djava.endorsed.dirs=${com.nec.webotx.installRoot}/modules/endorsed${path.separator}${com.nec.webotx.installRoot}/lib/endorsed, -Djava.security.policy=${com.nec.webotx.instanceRoot}/config/server.policy, -Djava.security.auth.login.config=${com.nec.webotx.instanceRoot}/config/login.conf, -Dcom.nec.webotx.enterprise.security.httpsOutboundKeyAlias=webotx, -Djavax.net.ssl.keyStore=${com.nec.webotx.instanceRoot}/config/keystore.jks, -Djavax.net.ssl.trustStore=${com.nec.webotx.instanceRoot}/config/cacerts.jks, -Djava.ext.dirs=${com.nec.webotx.javaRoot}/lib/ext${path.separator}${com.nec.webotx.javaRoot}/jre/lib/ext${path.separator}${com.nec.webotx.instanceRoot}/lib/ext, -Djdbc.drivers=org.apache.derby.jdbc.ClientDriver, -DANTLR_USE_DIRECT_CLASS_LOADING=true, -Dcom.nec.webotx.enterprise.config.config_environment_factory_class=com.nec.webotx.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory, -Dosgi.shell.telnet.port=6666, (*2) -Dosgi.shell.telnet.maxconn=1, -Dosgi.shell.telnet.ip=127.0.0.1, -Dgosh.args=--nointeractive, -Dfelix.fileinstall.dir=${com.nec.webotx.installRoot}/modules/autostart/, -Dfelix.fileinstall.poll=5000, -Dfelix.fileinstall.log.level=2, -Dfelix.fileinstall.bundles.new.start=true, -Dfelix.fileinstall.bundles.startTransient=true, -Dfelix.fileinstall.disableConfigSave=false, -XX:NewRatio=2, -Dlog4otx.configuration=file:///${com.nec.webotx.instanceRoot}/config/log4otx.xml, -Djava.util.logging.config.file=${com.nec.webotx.instanceRoot}/config/logging.properties, -Djava.util.logging.manager=com.nec.webotx.logging.WebOTXLogManager, -Dsun.lang.ClassLoader.allowArraySyntax=true

  (*1) ご利用頂いているバージョンが 9.10.00.00 の場合は「-client」になります。9.10.00.01以降のバージョンでは「-server」になります。
  (*2) インストール時にユーザドメインも作成した場合、そのドメインでは値が「6667」になります。

Dottedname : server.log-service

Dottedname : server.log-service.module-log-levels

Dottedname : server.log-service.log-file-config

Dottedname : server.monitoring-service.module-monitoring-levels

Dottedname : server.security-service

Dottedname : server.security-service.audit-module.default

Dottedname : server.security-service.auth-realm.admin-realm

Dottedname : server.security-service.auth-realm.certificate

Dottedname : server.security-service.auth-realm.file

Dottedname : server.security-service.jacc-provider.default

Dottedname : server.diagnostic-service

Dotted-name:server.diagnostic-service.statistics-report

1.3. HTTPサーバ

WebOTX では、Javaベースの内蔵Webサーバのほかに、ApacheベースのWebサーバ (以降「WebOTX Webサーバ」と記載します)をバンドルしています。 WebOTX Webサーバは、インストール時の指定によりVer2.2 (Apache HTTP Server 2.2 ベース)を選択してインストールすることができます。

WebOTXでは、その他に利用可能なWebサーバとして、IIS/Apache などの外部Webサーバをサポートしています。

WebOTX AS Express インストール時のデフォルト設定は、Javaベースの内蔵Webサーバを利用し、 WebOTX AS Standard/Enterprise インストール時のデフォルト設定は、WebOTX Webサーバを利用します。 WebOTX にバンドルされたWebサーバを利用する場合、インストール後に設定する項目は 特にありません。 外部Webサーバを利用する場合には、インストール後に「環境設定ツール」を起動し、外部Webサーバとの連携設定を行う必要があります。

1.3.1. Javaベース内蔵Webサーバ設定方法

項目の設定

Javaベースの内蔵Webサーバの設定方法については、次の２通りがあります。

Webコンテナ管理コンソールによる設定

Webコンテナの運用管理コンソールの「コネクタ」項目で、Javaベースの内蔵Webサーバの設定ができます。コネクタの「種類」が"HTTP"と表示されているものが内蔵Webサーバです。詳細は「1.4. Webコンテナ」を参照してください。

MOによる参照と設定

Javaベースの内蔵Webサーバの設定は、WebコンテナのMOを介してもアクセス可能です。対象となる MO の Dottedname は「server.http-service.http-listener.http-listener-name」です。属性 protocol の値が "HTTP/1.1" となっているものが内蔵Webサーバです。詳細は「1.4. Webコンテナ」を参照してください。

1.3.1.1. SSL通信の設定方法

1.3.2. WebOTX Webサーバ設定方法

ここでは、WebOTXで利用するWebサーバとして、「WebOTX Webサーバ」を利用する場合の設定方法について記載します。その他の外部Webサーバを利用する場合については、「1.3.3. 外部Webサーバ設定方法」項目を参照してください。

WebOTXの運用管理コマンドでは、WebOTX Webサーバの定義情報の変更/参照およびWebサーバの起動/停止ができます。また、従来どおり定義情報ファイル (httpd.conf)をエディタで編集して、定義情報の更新することもできます。

なお、 Javaベースの内蔵Webサーバの設定については、「1.4. Webコンテナ」を参照してください。

項目の設定

WebOTX Webサーバの定義情報を設定(変更)するには、otxadmin コマンドを利用するか、WebOTX Webサーバの定義情報ファイル(httpd.conf) を直接編集します。

>otxadmin set --user admin --password adminadmin server.WebServer.属性名=設定値

${INSTANCE_ROOT}/config/WebServer/httpd.conf

設定項目の詳細については、ApacheのマニュアルまたはWebサイトを参照してください。

例えば、WebOTX Webサーバが利用するポート番号を80番から8080番に変更する場合には、 次の方法を利用します。

otxadmin コマンド利用時
>otxadmin set --user admin --password adminadmin server.WebServer.port=8080

httpd.conf 直接編集時
  #Listen 80
  Listen 8080

SSL(HTTPS)通信用の設定について

HTTPS通信を行うには、SSL通信用のモジュールのインストールと、次節のMO設定においてSSL通信を行うかどうかの設定 (security_enabled )を、「有効」(ture)に設定する必要があります。

なお、SSL(HTTPS)通信に関する定義情報を変更する場合は

${INSTANCE_ROOT}/config/WebServer/ssl.conf

の設定項目を変更する必要があります。

詳細については、マニュアルの「注意制限事項」「Webサーバ」「SSL(HTTPS)通信について」を参照してください。

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

以下はMOから設定可能なWebOTX Webサーバの定義情報項目の一覧です。

各定義情報は、${INSTANCE_ROOT}/config/WebServer/httpd.conf または${INSTANCE_ROOT}/config/WebServer/ssl.conf を直接編集することでも変更可能です。

Dottedname : server.WebServer

1.3.2.2. 定義情報ファイル

WebOTX Webサーバの定義情報は、定義情報ファイル(httpd.conf)に格納され、WebOTX Webサーバ起動時に読み込まれます。

定義情報ファイルは、WebOTX のドメイン毎に格納されるため、ドメイン毎に 定義情報を変更する必要があります。

定義情報を更新した場合には、WebOTX Webサーバの再起動が必要になります。

格納場所
  ${INSTANCE_ROOT}/config/WebServer/httpd.conf

なお、SSL通信用ライブラリをインストールした場合、SSL設定に関する 定義情報は、ssl.confファイルに格納されます。

SSL通信で利用するポート番号や証明書／秘密鍵ファイルを設定／変更する場合、 このファイルに定義された情報を変更する必要があります。

格納場所
  ${INSTANCE_ROOT}//config/WebServer/ssl.conf

1.3.2.3. 基本定義

ここでは、WebOTX Webサーバが動作するために必要となる定義情報について 説明します。
定義情報ファイルには、次の定義が最低でも含まれている必要があります。

• ServerRoot
• Listen (または Port)
• User / Group
• DocumentRoot
• ErrorLog
• LoadModule

1.3.2.3.1. ServerRoot

1.3.2.3.2. Listen

1.3.2.3.3. User/Group

1.3.2.3.4. DocumentRoot

1.3.2.3.5. ErrorLog

1.3.2.3.6. LoadModule

1.3.2.4. サーバ動作に関する設定

ここでは、WebOTX Webサーバの動作プロセス数に関する設定を説明します。

Windows 版は、１つの子プロセス上で複数スレッドが動作し、各スレッド上で クライアントからのリクエストを受け付けます。つまり、１リクエストに対して、 １スレッドが割り当てられます。

上記のような動作の違いにより、Windows 版と UNIX 版では、定義内容が 異なります。また、 2.2 でも定義内容が異なる場合があります。
動作プロセスに関連する主な設定は次の指示子となります。

• MaxClients
• ThreadsPerChild
• MinSpareThreads / MaxSpareThreads
• StartServers
• ServerLimit / ThreadLimit
• MaxRequestPerChild

1.3.2.4.1. MaxClients

1.3.2.4.2. ThreadsPerChild

1.3.2.4.3. MinSpareThreads / MaxSpareThreads

1.3.2.4.4. StartServers

1.3.2.4.5. ServerLimit / ThreadLimit

1.3.2.4.6. MaxRequestsPerChild

1.3.2.5. SSL 定義

ここでは SSL通信を行う場合、定義情報ファイルに定義する 主な設定を説明します。
SSLに関する設定は、ssl.confファイルに格納されています。 ssl.confファイルは、SSL通信用パッケージをインストール することで追加されます。

• SSLEngine
• SSLCertificateFile
• SSLCertificateKeyFile
• SSLCACertificateFile
• SSLVerifyClient
• SSLOptions

1.3.2.5.1. SSLEngine

1.3.2.5.2. SSLCertificateFile

1.3.2.5.3. SSLCertificateKeyFile

1.3.2.5.4. SSLCACertificateFile

1.3.2.5.5. SSLVerifyClient

1.3.2.5.6. SSLOptions

1.3.2.6. ユーザ認証、アクセス制御

ここでは WebOTX Webサーバがサポートするユーザ認証機能と、 クライアントのアクセス制御に関する設定を記述します。

• AuthType
• AuthName
• AuthUserFile
• Require
• Order
• Allow / Deny

1.3.2.6.1. AuthType

1.3.2.6.2. AuthName

1.3.2.6.3. AuthUserFile

1.3.2.6.4. Require

1.3.2.6.5. Order

1.3.2.6.6. Allow / Deny

1.3.2.7. LDAP 連携

LDAP連携する場合に必要となる定義情報を記載します。

• AuthLDAPUrl

1.3.2.7.1. AuthLDAPUrl

1.3.2.8. ログ出力

WebOTX Webサーバが出力するログ情報に関する定義情報について説明します。

• ErrorLog
• CustomLog
• LogFormat
• LogLevel

1.3.2.8.1. ErrorLog

1.3.2.8.2. CustomLog

1.3.2.8.3. LogFormat

1.3.2.8.4. LogLevel

1.3.2.9. 起動待ち合わせ時間の設定

WebOTX Webサーバのアライブチェックモニタ処理は、WebOTX Webサーバの起動処理が完了してから開始しますが、システムの状態やWebサーバのモジュール起動タイミングによっては、WebOTX Webサーバが起動しているにもかかわらず、「Webサーバが起動していない」というメッセージが出力される場合があります。これを回避するために、次の設定により、WebOTX Webサーバ起動後にアライブチェックモニタ処理を開始する時間を秒単位で指定します。

ここでは、WebOTX Webサーバの起動が完了してから10秒後にアライブチェックモニタを開始する場合の設定例を記載します。

otxadmin>create-jvm-options -Dwebotx.webserver.startup_wait_count=10

1.3.2.10. その他の定義情報

その他の定義情報の詳細については、次のURLを参照してください。

• http://httpd.apache.org/docs/2.0/mod/

• http://httpd.apache.org/docs/2.2/mod/

1.3.3. 外部Webサーバ設定方法

項目の設定

外部Webサーバを利用する場合は、事前に環境設定ツールを使って連携のための設定が必要です。設定方法は、「セットアップガイド > 2. インストール > 2.3. インストール後の作業」を参照してください。

外部Webサーバの設定方法については次の２通りがあります。なお、下記は外部Webサーバと連携するためのコネクタに関する設定です。Webサーバ自体の設定については、それぞれのマニュアルを参照してください。

Webコンテナ管理コンソールによる設定

Webコンテナの運用管理コンソールの「コネクタ」項目で、外部のWebサーバと連携するためのコネクタの設定ができます。コネクタの「種類」が"AJP"と表示されているものが外部Webサーバ連携用のコネクタです。詳細は「1.4. Webコンテナ」を参照してください。

MOによる参照と設定

外部Webサーバ連携用コネクタの設定は、WebコンテナのMOを介してもアクセス可能です。対象となる MO の Dottedname は「server.http-service.http-listener.http-listener-name」です。属性 protocol の値が "AJP/1.3" となっているものが外部Webサーバ連携用コネクタです。詳細は「1.4. Webコンテナ」を参照してください。

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

Web版統合運用管理コンソールまたは運用管理ツールでは 「アプリケーションサーバ」-「Webコンテナ」-「Webサーバ連携設定」のノードが対応します。

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 旧名（非互換です）

Web版運用管理コンソールまたは運用管理ツールでは「アプリケーションサーバ」-「ネットワーク構成」-「ネットワークリスナ構成」-「network-listener」-「ネットワークリスナ名」のノードが対応します。

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サーバプラグイン(スタンダードモード)、IIOPプラグイン(アドバンスドモード)共通の設定項目一覧です。
対象ワーカタイプは次のとおりです。

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_om-22.conf-auto（IIOPプラグイン）
※ドメインを再起動すると、mod_jk-22.conf-auto、mod_jk_om-22.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 にする。

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

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

例えばバーチャルホスト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>

バーチャルホスト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プラグインで連携する仕組みになっています。

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のエラードキュメントの設定を行ってください。エラーの内容により有効になる設定箇所が変わります。

※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管理している場合、セッションIDを格納するCookieをはじめユーザが作成したCookieにも自動でセキュアオプションの設定を行うことができます。セキュアオプションを設定したCookieはクライアントからHTTPSプロトコルでアクセスされた場合のみリクエストに付加され、HTTPプロトコルでアクセスされた場合は付加されなくなります。

  <nec-web-app>
      :
    <session-config>
      <property name="alwayCookieSecure" value="true"/> 
    </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.net.NetPermission "getNetworkInformation";
    permission java.net.SocketPermission "*:0-65535", "listen,accept,resolve";
    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アーカイブしてドメインに配備してください。

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

1.5. EJBコンテナ

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

1.5.1. EJBコンテナ設定項目・設定方法

EJBコンテナに関する設定項目には次のものがあります。

EJBインスタンスプール

EJBインスタンスキャッシュ

Entity Beanトランザクションコミットオプション

組み込みIIOPリスナ

それぞれ設定項目については全てMO化されています。項目の設定方法については「1.1. 各サービスの属性」を参照してください。

エディションによる違い

Standard/EnterpriseではEJBはTPモニタのプロセスグループ上で動作します。このためTPモニタの設定に影響されます。詳しくはTPモニタの設定の章を参照してください。

組み込みIIOPリスナについて

組み込みIIOPリスナとは、ExpressにおけるEJBに対する要求や、JNDIサーバに対するRMI-IIOPのリクエストを処理するリスナです。これはエージェントプロセス内で動作します。EJBやJNDIサーバに対する通信ポート番号やSSLの使用の有無などを設定する場合は、この組み込みIIOPリスナの設定を変更してください。

Standard/EnterpriseにおけるEJBの通信リスナはTPモニタのIIOPリスナとなりますのでそちらの設定に従います。このため、組み込みIIOPリスナの設定はJNDIサーバに対してのみ有効となります。

既定値ではEJBコンテナとJNDIサーバに対する通信ポートは7780となります。

組み込みIIOPリスナのMO名は「embedded-iiop-service」、それ以外の上記3つに対応するMO名は「ejb-container」です。

1.5.2. EJBコンテナ設定項目一覧

以下はMOで設定可能なEJBコンテナ設定項目一覧です。

Dottedname : server.ejb-container

Dottedname : server.mdb-container

Dottedname : server.embedded-iiop-service

※ これらプールに関する設定は、ローカルインタフェースおよびローカルビジネスインタフェースを持つEJBに対しては全エディションで有効ですが、リモートインタフェースおよびリモートビジネスインタフェースを持つ EJBに対しては、Expressでのみ有効です。Standard/Enterpriseにおけるプールの設定については、[ 高度な管理と運用サイクルガイド > 2. チューニング > 2.8. EJBコンテナ ]を参照してください。

1.5.3. タイマBeanの使用方法について

EJB 2.1仕様ではコンテナ管理のタイマ機能が新たに追加されました。

WebOTXでこのタイマ機能を使用するためには、タイマ機能で使用するデータソースとデータベースのテーブルが必要となります。インストール時にはこれらは設定されていませんので、タイマ機能を使用するためには以下の手順でセットアップを行う必要があります。

(1) データソースの登録

タイマを使用するドメインに対して "jdbc/__TimerPool" という名前のデータソースを追加してください。また対応するJDBCドライバをドメインのクラスパスに追加してください。

(2) テーブルの作成

${AS_INSTALL}/lib/install/databasesにOracle、Derby、DB2、SQL Server、Sybase用のテーブル作成SQLファイルがありますので、これを使用して追加したデータソースで接続するデータベース上にテーブルを作成してください。他のデータベースを使用する場合もこのSQLを参考にして同じテーブル名、カラム名でテーブルを作成してください。

(3) ドメイン再起動

ドメインを再起動すると、タイマ機能が使用可能になります。

1.6. JNDIサービス

JNDIサービスに関する設定について説明します。

1.6.1. JNDI設定項目・設定方法

JNDIサービスの設定項目については全てMO化されています。項目の設定方法については「1.1. 各サービスの属性」を参照してください。

1.6.2. JNDIサービス設定項目一覧

以下はMOで設定可能なJNDIサービス設定項目一覧です。

Dottedname : server.jndi-service

1.6.3. JNDIサーバの通信リスナの設定

JNDIサービスはEJBと同じく、RMI-IIOPを使用して通信を行ないます。 このため通信用ポートなどの設定は組み込みIIOPリスナの設定で行ないます。組み込みIIOPリスナについてはEJBコンテナの設定方法を参照してください。

1.6.4. JNDIサーバをレプリケーションするための設定

HTTPセッション情報のみをレプリケーションする場合は以下の手順は必要ありません。代わりにWebコンテナのsession-replication-jndi-url属性で設定します。詳しくは、「1.4.3. HTTPのみのセッションレプリケーション」を参照してください。

JNDIサーバの名前情報全体を複数ドメイン間でレプリケーションするためには、それぞれのドメインで同じCosNamingサーバと連携するように設定します。あらかじめJNDIサーバのbind-to-nameservice属性をtrueに設定しておく必要があります。

(1) CosNamingサーバと連携する場合

corbaname://server:port1,corbaname://server:port2

(2) キャッシュ名前サーバと連携する場合

レプリケーションを行うと、JNDIサーバへのバインドなどの名前を更新する処理は上記のCosNamingサーバのURLに登録されている全てのJNDIサーバに対して行われます。 あるドメインのJNDIサーバを後から起動した場合でも、他の動作中のJNDIサーバから登録情報を取得して自身の登録情報にマージします。 レプリケーション対象のJNDIサーバのリストはObject BrokerのCosNamingサーバに登録されますが、ドメインを停止するとCosNamingサーバ上のリストがクリアされます。 そのためJNDIサーバをレプリケーションしている環境で、あるドメインを起動したまま別のレプリケーション対象のドメインを再起動した場合、 再起動したドメインのCosNamingサーバに対して停止しなかったドメインのJNDIサーバを再登録する必要があります。

JNDIサーバの再登録および登録解除は、統合運用管理ツールのJNDIサービスで行います。運用管理コマンドを使用する場合は以下のように行います。 この操作を行っても、JNDIサーバの名前情報に影響はありません。

otxadmin>invoke server.jndi-service.bindRemoteReference

otxadmin>invoke server.jndi-service.unbindRemoteReference

1.7. JMS

JMSに関する設定について説明します。

1.7.1. JMS設定項目・設定方法

JMSサーバは独立したプロセスで実装しており、WebOTXのアプリケーションサーバ本体には、リソースアダプタにより接続連携しています。

JMSサーバや、JMSリソース、および、送信先の基本的な管理は、運用管理コマンド(otxadmin)、あるいは、統合運用管理ツールで行います。さらに詳細な管理を行うためには、JMSサーバが提供している専用の運用管理ツールを利用します。

運用管理コマンド、あるいは、統合運用管理ツールからの各項目の設定方法については、「1.1. 各サービスの属性」を参照してください。また、JMSサーバが提供している専用の各運用管理ツールについては、「4. 運用管理コマンドリファレンス > 4.4. JMS」を参照してください。

1.7.1.1. JMSサーバに対する設定

JMSサーバの運用に関するプロパティは、JMSサービス(jms-service)と、JMSホスト(jms-host)のMOから設定できます。

運用管理コマンドや、統合運用管理ツールでは、それぞれ以下のように指定します。

JMSサーバは、1〜4のプロパティを取り込みます。優先順位は、後ろのものほど高くなっています。

1. default.propertiesファイル

   プロパティのデフォルト値が定義されたファイルで、次の位置にあります。

   ${AS_INSTALL}/wojms/lib/props/broker/default.properties

   注意 :

   利用者は直接編集を行わないで下さい。

   
   

2. install.propertiesファイル

   インストール時に指定されたプロパティが格納されるファイルで、次の位置にあります。

   ${AS_INSTALL}/wojms/lib/props/broker/install.properties

   注意 :

   利用者は直接編集を行わないで下さい。

   
   

3. config.propertiesファイル

   ドメイン固有のJMSサーバに対するプロパティ設定を記述するファイルで、次の位置にあります。ファイルはドメイン生成時に作成されます。

   ${INSTANCE_ROOT}/wojms/instances/<JMSサーバインスタンス識別子>/props/config.properties

   備考 :

   <JMSサーバインスタンス識別子>の既定値は「wojmsbroker」です。

   
   

4. JMSサーバの起動引数(server.jms-service.start-args)

   起動引数で指定したプロパティは、すべてのプロパティ設定ファイルに対して優先されます。

1.7.1.2. コネクションファクトリに対する設定

コネクションファクトリリソース

コネクションファクトリリソースは、Java EEアプリケーションからJNDIを通して利用します。項目の設定や、参照を行う場合、運用管理コマンドや、統合運用管理ツールでは、それぞれ以下のように指定します。
「connection-factory-name」は、コネクションファクトリリソースの定義名で、JNDIの登録名になります。

1.7.1.3. 送信先に対する設定

送信先

物理的な送信先の設定や、項目の参照を行う場合、運用管理コマンドや、統合運用管理ツールでは、それぞれ以下のように指定します。「physical-destination-name」は、送信先の定義名です。

送信先リソース

送信先リソースは、Java EEアプリケーションからJNDIを通して利用します。項目の設定や、参照を行う場合、運用管理コマンドや、統合運用管理ツールでは、それぞれ以下のように指定します。
「logical-destination-name」は、送信先リソースの定義名で、JNDIの登録名になります。

1.7.2. JMS設定項目一覧

運用管理コマンド、統合運用管理ツールで制御できるMOの属性と、そのベースとなるJMSのプロパティ／属性一覧を示します。

1.7.2.1. MOの属性一覧

JMSに関連するMOのうち、属性を設定できるものは、以下の5種類です。以降、各MOについて設定できる属性を説明します。

• JMSサービス（jms-service）
• JMSホスト（jms-host）
• コネクションファクトリリソース（jms-connection-factory）
• 送信先（jms-physical-destination）
• 送信先リソース（jms-logical-destination）

1.7.2.2. JMSサービス

連携するJMSサーバに関する情報を定義します。
この定義は、運用管理コマンドのcreate-domainによるドメイン生成時に自動的に設定されます。
MOのdottednameは「server.jms-service」です。設定可能な属性や、操作については、「2. MO定義リファレンス > jms-service」を参照してください。
なお、jms-serviceの「プロパティ」として設定できるのは、以下の項目です。

1.7.2.3. JMSホスト

JMSサーバの起動、JMSサーバへの接続に必要な情報を定義します。
この定義は、create-domainコマンドによるドメイン生成時に自動的に設定されます。ポート番号については、create-domainコマンドの--fileオプションで指定するプロパティファイル(ドメイン設定ファイル)に、domain.jms.portとして指定することができます。
MOのdottednameは「server.jms-service.jms-host.default_JMS_host」です。設定可能な属性や、操作については、「2. MO定義リファレンス > jms-host」を参照してください。

1.7.2.4. コネクションファクトリリソース

JNDIを通してアクセスするコネクションファクトリリソースを定義します。
この定義は、運用管理コマンドのcreate-jms-resource、統合運用管理ツールでは、「WebOTX管理ドメイン[<ホスト名>].<ドメイン名>.リソース.JMSリソース」の「コネクションファクトリリソースの作成」操作で作成されます。コネクションファクトリリソースの作成方法については、「ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.3. JMS > 7.3.3. JMSリソースの操作」を参照してください。
コネクションファクトリリソース(jms-connection-factory)作成時には、コネクタリソース(connector-resource)、コネクタコネクションプール(connector-connection-pool)、および、リソース参照(resource-ref)を自動的に作成し、属性値を設定します。 属性値を変更する場合は、コネクションファクトリリソースのMOを介して行います。 各MOのdottednameは以下のとおりです。

設定可能な属性や、操作については、「2. MO定義リファレンス」を参照してください。

注意 :

コネクションファクトリリソース作成時、「プロパティ」に属性と同じ名前の項目を指定した場合は、「プロパティ」に指定されたものが優先されます。

1.7.2.5. 送信先

物理的な送信先を定義します。
この定義は、運用管理コマンドのcreate-jmsdest、統合運用管理ツールでは、「WebOTX管理ドメイン[<ホスト名>].<ドメイン名>.アプリケーションサーバ.JMSサービス」の「送信先作成」操作で作成されます。送信先の作成方法については、「ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.3. JMS > 7.3.2. 送信先の操作」を参照してください。
MOのdottednameは「server.jms-service.jms-physical-destination.destination-name」です。設定可能な属性や、操作については、「2. MO定義リファレンス > jms-physical-destination」を参照してください。

注意 :

送信先作成時、「プロパティ」に属性と同じ名前の項目を指定した場合は、「プロパティ」に指定されたものが優先されます。

1.7.2.6. 送信先リソース

JNDIを通してアクセスする送信先リソースを定義します。
この定義は、運用管理コマンドのcreate-jmsresource、統合運用管理ツールでは、「WebOTX管理ドメイン[<ホスト名>].<ドメイン名>.リソース.JMSリソース」の操作である「送信先リソースの作成」で作成されます。送信先リソースの作成方法については、「ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.3. JMS > 7.3.3. JMSリソースの操作」を参照してください。
送信先リソース(jms-logical-destination)作成時には、管理オブジェクトリソース(admin-object-resource)と、リソース参照(resource-ref)を自動的に作成し、属性値を設定します。
属性値を変更する場合は、送信先リソースのMOを介して行います。
各MOのdottednameは以下のとおりです。

設定可能な属性や、操作については、「2. MO定義リファレンス」を参照してください。

注意 :

送信先リソース作成時、「プロパティ」に属性と同じ名前の項目を指定した場合は、「プロパティ」に指定されたものが優先されます。

1.7.2.7. JMSのプロパティ／属性一覧

ここでは、以下のプロパティや属性について説明します。

JMSサーバのプロパティ

「1.7.1. JMS設定項目・設定方法 > 1.7.1.1. JMSサーバに対する設定」で説明した、「config.propertiesファイル」に設定できるプロパティです。以下のカテゴリに分けて説明しています。

• JMSサーバ全体のプロパティ
• コネクションサービスに関するプロパティ
• セキュリティに関するプロパティ
• 永続ストアに関するプロパティ
• ログ出力に関するプロパティ
• メモリ管理に関するプロパティ
• 自動生成送信先に関するプロパティ
• クライアント監視に関するプロパティ
• JMSサーバクラスタに関するプロパティ

JMSクライアントのプロパティ

非Java EE環境下で動作するJavaアプリケーションに有効であり、Javaシステムプロパティとして設定します。