|
|
WebOTX Manual V10.3 (第4版) 目次を表示 |
|
|
|
WebOTX Manual V10.3 (第4版) 目次を表示 |
Webコンテナを利用する際の注意制限事項について説明します。
初期設定を行うと、ドメインの config/WebCont 配下にある以下のファイルが初期化されます。これらのファイルを編集している場合はバックアップを取っておいてください。
運用管理コンソールについては、[ 運用管理コンソール ]を参照してください。
JSP のログレベルを "DEBUG" 以上に変更すると、JSP でリクエストパラメータを取得した時に文字化けが発生します。
ログレベルを "DEBUG" に変更すると、JSP処理コンポーネントが処理するデータをログに記録します。障害調査などを目的としたログであるためブラウザから渡されてきたそのままのデータを記録します。このため、JSP でリクエストパラメータ取得時の文字コードを設定する前にリクエストパラメータを分解します。この結果、文字コードの設定が効かずアプリケーションで文字化けが発生します。
本ログレベルを上げるのは、JSPにおいてリクエストの内容がどのようになっているかを確認する時だけにしてください。そして、内容を確認した後は、必ず "CONFIG" レベルに戻してください。
多量のパラメータを持つリクエストを処理すると、パラメータ解析処理に過剰な負荷が掛かかりドメインが動作できなくなる問題（Tomcatの脆弱性 CVE-2012-0022、CVE-2011-4858）に対処するため、処理可能なリクエストパラメータ数の上限を10000に設定しています（既定値）。リクエストパラメータ数の上限を変更したい場合、maxParameterCount で調整してください。
詳細は以下を参照してください。
[
リファレンス
> 設定
> Webコンテナ
> Webコンテナ設定項目一覧
> MOで設定可能な項目一覧
> Dottedname : server.network-config.protocols.protocol.protocol-name.http.property.maxParameterCount
> maxParameterCount]
WebOTX が動作しているマシン上の全てのIPアドレスでリクエストを受け付けるように設定する場合、domain.xml の domain > configs > config > network-config > network-listeners > network-listener > http-listener の address 属性で "0.0.0.0" と指定してください。例えば "any" や "ANY" といった文字列は指定できません。指定した場合には通信ができなくなります。
address 属性の既定値は "0.0.0.0" です。
IIS + Webコンテナの環境で、リクエストURLに「/scripts/jrun.dll/」という文字列が先頭に付加されている場合にJSPファイルを実行するとエラー(404)が発生します。
この現象は IIS ＋ JRun の環境を過去に構築した事があると発生します。 IIS の script
ディレクトリに「jrun.ini」があるので、その中で「scripts/jrun.dll」の文字列が付加されていれば、「jrun.ini」を削除(待避)してください。
IISと連携している時、Webサイトの設定でディレクトリセキュリティの「認証方法」で“匿名アクセスを有効にする”のチェックを外している場合、servlets-examplesなど一般の Webアプリケーション へのアクセス時にも認証が必要となります。
これは、IISへのアクセスに関して認証が要求されているという事ですので、システムに存在するいずれかのユーザでログインしてください。
IIS連携時、isapiプラグインから設定ファイルuriworkersmap.propertiesが読み込めていないために、「ファンクションが間違っています」と表示される場合があります。その場合、次の設定を行ってください。
IIS連携時に、JKコネクタ（Webサーバプラグイン）のログが指定しているディレクトリに出力されない場合があります。
次の処理を行ってください。
Webコンテナをアンインストールしても 連携する Webサーバの設定が残っています。そのまま Webサーバを使い続けた場合、システムによっては 503エラーを返却するなどWebサーバが正常に起動しなくなる可能性があります。特に Unix 環境でWebサーバを自動起動に設定している場合、最悪 Unix が起動しなくなる恐れがあります。
また、WebOTX AS V9.2 以降 では ISAPI フィルター名にドメイン名を domain1_webcont のようにつけるため、WebOTX AS V9.1 以前で使用していた IIS サイトに対して連携設定を行ったり、 別のドメインと行うと古い設定が残ったままとなり、連携ができず 503 エラーとなります。そのため、古い設定が残っている場合は、IISマネージャにて古いISAPI フィルターを削除してください。
WebOTX Webサーバのインストールディレクトリのconfディレクトリ配下にあるhttpd.confファイルを編集します。「# TM_WS_PLUGIN-start 」~「# TM_WS_PLUGIN-end」の記述を削除してください。
# TM_WS_PLUGIN-start
include "${INSTANECE_ROOT}/config/WebCont/mod_jk-24.conf"
# TM_WS_PLUGIN-end
Webサーバと連携中に配備解除したWebアプリケーションにアクセスするなどした場合(通常は
HTTP404エラー)、ブラウザの設定によりダウンロード処理が始まることがあります。
ブラウザの設定を変更することで回避することができます。
例) IE6の場合次のチェックをONにする
メニューより「ツール」-「インターネットオプション」-「詳細設定」で「ブラウズ」-「HTTPエラーメッセージを簡易表示する」
PathCheck fn="find-index" index-names="index.html,home.html,index.jsp"
外部Webサーバと連携した場合、logsディレクトリに以下のようなファイルが作成されます。
Apache の場合："jk_runtime_status"と"jk_runtime_status.lock"
これらは、JKコネクタ（Webサーバプラグイン）の制御ファイルです。
外部Webサーバ連携時は、Webサーバ側に配置したコンテンツにアクセスすることによりWebサーバプラグインのログにエラーが出力される場合があります。
アクセスしたコンテンツがWebコンテナにないかクエリを行い、その結果、コンテンツがないためにエラーログが出力されます。動的反映を無効にするか、Webサーバ起動時に１回だけクエリする設定(queryonce)によりエラーログを抑制することができます。
IIS動作マシンにWebOTX Clientをインストールして、環境構築ツールから「Webサーバ連携を実施」するか、初期設定ツールを起動してIISとの連携初期設定を行ってください。
WebOTX AS V8.2以降ではアプリケーションをプロセスグループに配備した場合でも、Webサーバとの連携設定に使用する設定ファイル(mod_jk-24.conf)を自動で出力します
旧バージョンのWebOTXと同様に、これらのファイルを自動で変更したくない場合は、以下のコマンドでJVMオプションを設定してください。ただし、以下のオプションを指定している場合、統合運用管理ツールから設定できる「Webサーバ連携設定」の項目のうち、*.confに出力される設定項目も無効になります。
otxadmin> create-jvm-options -Dwebotx.webcontainer.serverconfig.OMlistener.OutputConfAuto=false
また、上記オプションの設定有無に関わらず、ファイルが存在しない場合は自動で作成されます。
外部Webサーバ連携時、JkMountディレクティブの記述の仕方によってはリクエストが正常に振り分けられない事があります。例えば、次のような場合です。
JkMount /sample/* agent-ajp
JkMount /sample/aaa agent-ajp
上記の記述では、どちらの条件にもマッチするため正常に振り分けられません。
複数のアプリケーションを異なるドメインに配置している時（例えば /sample/aaa と /sample/bbb を異なるドメインに配備した場合）、次のような設定をしても正常に振り分ける事はできません。
JkMount /sample/* agent-ajp
WebサーバとWebコンテナが別マシン構成の場合、統合運用管理ツールや運用管理コマンドからプラグインの設定項目(Webサーバ連携設定)の変更を行うためには、以下の条件を満たしている必要があります。
初期設定ツールは、IISとの連携に必要な以下の役割サービスを自動でインストールします。
WebOTX AS V10では動的反映機能の見直しにより、コンテキスト情報を取り込むタイミングがリクエストトリガーではなくなりました。 コンテキスト情報はリクエストとは別スレッドで一定間隔で取得します。そのためアプリケーションを配備した直後は、配備したアプリケーションに対するリクエストが404エラーになります。 配備したアプリケーションのコンテキスト情報を反映するには、一定間隔(既定値：60秒)の経過を待つか、外部Webサーバを再起動する必要があります。 アプリケーションの開発段階で配備/配備解除が頻繁に行われるような状況では、コンテキスト情報を取り込む間隔を短く設定する方法を検討してください。 コンテキスト間隔の設定方法を記述します。
otxadmin> get server.web-container.plugin-config.plugin-dynamic-reflection-kind
・値が"query"の場合、Webサーバプラグイン〜Webコンテナ間で通信を行い、コンテキスト情報を取得します。
・値が"file"の場合、Webコンテナが出力するコンテキスト情報を記述したファイルをWebサーバプラグインが読み取ることでコンテキスト情報を取得します。
otxadmin> set server.web-container.plugin-config.plugin-query-interval=10
・取得間隔を秒単位で指定します。
otxadmin> set server.web-container.plugin-config.jk-mount-file-reload=10
・取得間隔を秒単位で指定します。
外部Webサーバもしくはドメインの再起動で反映します。また、動的反映機能は、uriworkermap.propertiesに定義された全てのコンテキストマッピング情報を内部的にオーバーライドします。
そのため、uriworkermap.propertiesに手動で定義を行う場合は動的反映機能を無効にしてください。
設定方法は
[ リファレンス
> 設定
> Webコンテナ
> Webコンテナ設定項目一覧
> MOで設定可能な項目一覧
> Dottedname : server.web-container.plugin-config
> plugin-query-mode]
を確認してください。
WebコンテナとWebサーバ連携する Apache HTTP Server 2.4 は、APRのスレッド機能を有効(--enable-threads)にしてビルドされている必要があります。
Webサーバ連携している環境でリクエストを実行すると502エラーが返却される場合があります。
502エラー発生時、該当するログ(*1)が記録されている場合、Webサーバプラグインのリクエスト転送とWebコンテナの一定時間未使用によるコネクション切断が交差してエラーになったことを示します。
(*1) {ドメインディレクトリ}/logs/web/mod_jk-24.log_XXXXXXXX
(ajp13) Web Container is down or refused connection. No response has been sent to the client (yet)(error=32,Broken pipe)(Lapsed time after using connection at the end: 60s) (ajp13) sending request to Web Container failed (unrecoverable), (attempt=1)
上記502エラーは次の設定で現象発生を軽減することが可能です。
Servlet API 仕様 2.4 に準拠したWebアプリケーションで、web.xml に空の <load-on-startup>要素を含む場合は、そのWebアプリケーション（war）は配備できません。
WebOTX に付属する「ファイル転送サンプル」を実行する場合、実行に先立って次のポリシーをドメインディレクトリの config/server.policy に追加してください。
grant {
permission java.io.FilePermission
"${com.nec.webotx.instanceRoot}${/}applications${/}fileupdownload${/}-", "read,write,delete";
};
Webアプリケーションを配備すると、内部では Webアプリケーション名とコンテキストルートの２つで Webアプリケーションを識別します。これらは、配備済みの Webアプリケーションと同じ名称を指定する事はできません。Webアプリケーション毎に一意の指定をしてください。
JSP を含む Webアプリケーション を実行すると、パーミッションエラーで JSP のコンパイルが失敗する事があります。
この場合、使用する JDK のバージョンに合ったクラスが使用されているかを確認してください。具体的には、利用している JDK に付属の tools.jar が使用されているかを確認します。異なったバージョンの tools.jar がクラスパスに指定されていると正しくコンパイルできない恐れがあります。
Webコンテナで設定できる「セッションIDの管理」ですが、この動作は次のようになります。なお、使用するブラウザによっては必ずしも下記の通りにはならない事もあります。
ブラウザ Webコンテナ 1) Cookie有効 セッションIDの管理-ON → Cookieによってセッション管理される 2) Cookie有効 セッションIDの管理-OFF → Cookieによってセッション管理される 3) Cookie無効 セッションIDの管理-ON → URLによってセッション管理される 4) Cookie無効 セッションIDの管理-OFF → URLによってセッション管理される
JSPページから、同じ Webアプリケーション内のクラスを参照する場合、そのクラスはパッケージ化（package宣言）されている必要があります。
Webアプリケーションの web.xml の XML宣言部分にエンコーディングとして "SJIS" を指定した場合、Webアプリケーションが正しく読み込めない場合があります。この場合、エンコーディングとして "Shift_JIS" を指定してください。
Webアプリケーションを運用管理コンソールから、一時停止し、このWebアプリケーションに含まれるHTMLファイルにアクセスした場合、一時停止中にも関わらずエラーにならないことがあります。ServletやJSPにアクセスした場合には、エラーになります。
あるサイズ以上（数百KBから数MB）の WARファイルを Webコンテナに配備すると、次のエラーが発生する事があります。
"Internal server error. reason: JNDI information get error: error in opening zip file" |
"-Xss512k" |
配備するWARファイルのファイル名に２バイト文字を指定すると、一部文字化けする文字(外字域、機種依存域、等)があります。２バイト文字を指定しないでください。
ServletContextListener、ServletContextAttributeListener、HttpSessionActivationListener内でJNDI（名前環境のルックアップ等）を利用すると、Exceptionが発生する場合があります。
エラーページに page ディレクティブで contentType や pageEncodingを指定するとエラーページの表示で文字化けします。エラーページでは page ディレクティブを指定しないようにしてください。指定しなければ、文字化けさせずに表示できます。
root 以外の運用管理ユーザでドメインを運用している時に、WebOTX AS 付属のサンプルを autodeploy で配備する場合には、 WARファイルに運用管理ユーザが読み書きできるパーミッションを与えてください。
Servlet 2.5 以前では、Webアプリケーションの配備情報をweb.xmlから取得しているため、Webアプリケーションには web.xmlは必須です。web.xmlがない、もしくは、正しく記述されていない場合には、Webアプリケーションを配備することができません。
Windowsでは、WebアプリケーションのWEB-INFディレクトリ配下などに格納したファイル（*.propertiesなど）をJDBCやXMLパーサなどで処理する場合、これらのファイルが参照状態になり配備解除に失敗することがあります。ドメインを停止後、domain
のディレクトリの applications ディレクトリ配下にあるWebアプリケーションのディレクトリのWEB-INF配下の
"lib"、classes"、"nec-web.xml"、"web.xml"以外のファイルを手動で削除して、ドメインを起動後配備解除してください。
例えば、Apache Portals Project で公開されている Jetspeed
がこのWebアプリケーションに該当します。
WebOTX AS V7.1からセッション情報を格納する仕様が異なります。このため、WebOTX AS V7.1以降とWebOTX V6.5以前にまたがってセッションレプリケーションの連携をすることができません。
セッションレプリケーションを行う場合、格納するオブジェクトに注意事項があります。
また、この注意事項はアプリケーションをプロセスグループに配備し「プロセス間コンテキスト属性共有」を行う場合にも該当します。
詳細は以下を参照してください。
[
セッションレプリケーションのWebアプリケーション実装注意事項について
]
セッションレプリケーション非同期モードには、以下の注意点があります。
セッションレプリケーション同期モードには、以下の注意点があります。
セッションレプリケーションを使用するにあたってWebアプリケーションを実装するには、以下の注意点があります。
|
|
レプリケーション前と同じ取得を"DEF"にしたい場合はiiとiiiの間で再度setAttribute()を実行する必要があります。
|
セッションレプリケーションを設定するとセッション情報がJNDI(あるいは、データベース)に格納されるようになります。この際セッションに格納しているオブジェクトに関して注意点があります。
セッション情報として、VectorやHashtableなど、同期化されたコレクションクラスを使用すると、シリアライズ/デシリアライズが同期化されてしまいます。同期化されてしまうと処理が直列化されて、大幅な性能低下につながるおそれがあります。そのためVectorやHashtableではなく同期化されないArrayListやHashMapをご使用ください。
また、シリアライズ/デシリアライズは複雑なコレクションクラスの処理には時間が掛かります。セッション情報として使用するオブジェクトはシンプルなものをお勧めします。
Oracle Coherenceを使用する場合、以下の注意点があります。
J2SE 5.0 で新しく予約語になった用語を JSPファイルで変数などとして使用していた場合コンパイル時にエラーとなります。この場合、nec-web.xml で compilerSourceVM オプションを利用して任意のバージョンを指定するか、名称を変更してください。
<jsp-config>
<property name="compilerSourceVM" value="1.4"/>
なお、Java の予約語は以下の通りです。
原始型（プリミティブ型）を表す予約語
byte,char,short,int,long,float,double,boolean,true,false,void
クラス、パッケージに関する予約語
class,interface,extends,implements,this,super,new,null,instanceof,import,package,
修飾子
public,protected,private,final,static,abstract,native,synchronized,volatile,transient
基本的な制御に関する予約語
for,while,do,if,else,switch,case,default,break,continue,return,
例外処理に関連する予約語
try,catch,finally,throw,throws,
その他の予約語
const,goto,strictfp
追加
assert(1.4),enum(5.0)
WebOTX ではアプリケーション配備時にそのアプリケーションに含まれる web.xml および nec-web.xmlの内容をドメイン配下に保存します（${INSTANECE_ROOT}/generated/xml/[AP名]/appDescr.dat）。
このため、配備したアプリケーションの web.xml 等を直接編集しても反映されません。内容を変更したい場合は再配備してください。
複数の仮想サーバを定義している状態で、アプリケーションを配備する際に仮想サーバ（Virtual Server）を指定しなかった場合は全ての仮想サーバで配備したアプリケーションが利用可能な状態になります。
V8.1 より
Webアプリケーションの認証処理が一部変更になり、その関係で静的なファイルへのリクエストでキャッシュが効かず毎回リクエストしてしまう、という現象が発生する場合があります。これは、初回リクエストに対するHTTPレスポンスヘッダに以下のパラメータが含まれているためです。
Pragma: No-cache
Cache-Control: no-cache
このパラメータを付加したくない場合（V7以前と同じ動作をさせたい場合）は、次のシステムプロパティを設定してください。
-Dcom.nec.webotx.enterprise.checkURLPatternAfterMatching=false
また、":"を含むURLにアクセスした時に 400エラーになってしまう場合も上記プロパティを設定することで回避可能です。
Internet Explorerのバグにより以下の条件を全て満たす場合、SSL通信でのXMLドキュメントの取得に失敗します。
詳細は以下のサイトを参照してください。
http://support.microsoft.com/kb/272359/en-us
取得する XML ファイルが web.xml で定義された <security-constraint> の範囲外にある場合、 checkURLPatternAfterMatching の設定により、この現象を回避できることがあります。 詳細は[ 移行 > Tomcatからの移行 > 移行作業 > WebOTX独自のWebアプリケーション配備記述子（nec-web.xml） > no-cache の設定 ] を参照してください。
Internet Explorerでホスト名に _(アンダースコア)等を含むURLにアクセスした場合、そのサイトの
Cookie は保存されません。そのため、セッションを利用する運用管理コンソールなどのアプリケーションが利用できません。
Cookie
を使用する場合、IPアドレスを指定してアクセスするか、Firefox等別のブラウザを使用してアクセスしてください。
詳細は以下のサイトを参照してください。
http://support.microsoft.com/kb/275033/en-us
WebOTX
V8以前からV9へアップグレードする際には、ベースとなるTomcatのバージョンが変更されていることにより互換性を保つための設定が必要となる場合があります。
詳細は、[
移行
> Tomcatからの移行
> 移行作業
> Tomcatの差異による対応
] を参照してください。
コンテキストパス（http://<ホスト名>:<ポート番号>/<ContextPath>/<ServletPath>/ の <ContextPath> の部分）に、例えば "/sample/ap" のように "/" を含む場合、一部機能が利用できません。
利用できないのは次の機能です。
a) セッションレプリケーション
b) アプリケーションをプロセスグループに配備した場合のリクエスト振り分け
対処：
いずれの場合も、コンテキストパスは "sample_ap" のように "/" は含めない形で配備してください。
また、"/" は含めない形で配備はしても、クライアントからのアクセスURLを変更したくない場合は次の
ように対処してください。
LoadModule rewrite_module "/opt/WebOTX/WebServer2/modules/mod_rewrite.so"
RewriteEngine on RewriteRule ^/samplep/ap/(.*)$ /sample_ap/$1 [PT,L] RewriteRule ^/sample_ap/(.*)$ /sample/ap/$1 [R,L]
コンテキストパスに "/" を含む URL にも Cookie を送付するよう明示的に指定します。設定場所は、WebOTX 独自のWebアプリケーションの配備記述子である nec-web.xml です。このファイルに次のような記述を追加します。
<?xml version="1.0" encoding="UTF-8"?><nec-web-app>
<context-root>sample_ap</context-root>
<class-loader delegate="false"/>
<session-config>
<cookie-properties>
<property name="cookiePath" value="/sample/ap"/>
</cookie-properties>
</session-config>
</nec-web-app>
追記が終わったらWARファイルをアーカイブし直して配備します。
JSPファイル参照時に、コンパイルされたclassファイルの読み込みで、 JVMの問題による「java.lang.InternalError:name is too long to represent」という 例外が発生する場合があります。 この例外が発生する場合は、次のいずれかの対処を行ってください。
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
:
<init-param>
<param-name>suppressSmap</param-name>
<param-value>true</param-value>
</init-param>
JSR-045デバッグ情報は、JSPコードとコンパイルしたclassファイルを関連付けるための情報です。
HTTPリスナやAJPリスナの属性やプロパティを変更すると、リスナが再起動して 接続中のコネクションが切断されるためHTTPクライアントがエラーとなります。
以下の様なログが出力されてクラスのロードに失敗する場合は下記のセキュリティポリシー定義を追加して下さい。
yyyy-mm-dd hh:MM:ss,sss INFO WEBCONT - Security Violation, attempt to use Restricted Class: ＜パッケージ名＞.＜クラス名＞ [http-thread-pool-80(1)]
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.sun")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366)
at java.security.AccessController.checkPermission(AccessController.java:560)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1529)
at com.nec.webotx.enterprise.security.J2EESecurityManager.checkPackageAccess(J2EESecurityManager.java:104)
at com.nec.webotx.as.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:2308)
${INSTANCE_ROOT}/config/server.policy に以下の定義を追加してください
grant codeBase "file:${com.nec.webotx.instanceRoot}/applications/＜アプリケーション名＞/-" {
permission java.lang.RuntimePermission "accessClassInPackage.＜パッケージ名＞";
permission java.lang.RuntimePermission "defineClassInPackage.＜パッケージ名＞";
};
なお、server.policy にポリシーを追加しても Security Violation のメッセージが抑止できない場合があります。現在確認できているのは次のケースです。
これは、log4j2 の処理の延長で Java の中の JavaScriptエンジンである「Nashorn」関連のクラスがログメッセージ用のリソースを取得する際にアクセス権限が無いため発生しています。このケースでは、Java の中の処理においてアクセス権のコンテキスト付け替えを行っているため、server.policy のポリシーが適用されません。
しかし、本ケースでは Security Violation のメッセージは出力されるもののWebアプリケーションの動作への影響はありません。このため、このメッセージは無視していただくようお願いいたします。
なお、log4j2を利用した本ケースに限らず同じ問題が発生する可能性があります。
Webアプリケーション内の WEB-INF/lib 配下のJarファイル内に以下のリソースが存在する場合は配備解除後も ${INSTANCE_ROOT}/applications/${アプリケーション名} ディレクトリが削除されません。
META-INF/services/javax.servlet.ServletContainerInitializer
当該Jarファイルを任意のディレクトリに移動してnec-web.xmlのclass-loader要素 のextra-class-pathでJarファイルのパスを指定してください。
<nec-web-app>
<class-loader extra-class-path="Jarファイルのパス名"/>
</nec-web-app>
※任意のディレクトリに移動したJarファイルは、アプリケーション配備後はドメインを停止するまで削除できません。
WebOTX AS V9.2以前は、Webアプリケーションのサーブレット実行中に例外が発生した場合、リクエスト元のブラウザに例外のスタックトレースを含んだエラーレポートが表示されていました。
WebOTX AS V9.3では、例外が発生する前にサーブレットからレスポンスが出力されていた場合、そちらの内容を優先して返却するよう変更しています。 例外スタックトレースの確認は以下のログファイルを参照してください。
アプリケーションをエージェントプロセスに配備した場合、ServletとEJBを混在させたEARでServletに対するEJBのインジェクションができません。 アプリケーションをエージェントプロセスに配備した場合、EARを作成せずにEJBとWARを個別に配備してください。
Webアプリケーションの配備時に "--precompilejsp=true" を指定して JSP のプリコンパイルを行う機能では、UNCパスを指定したディレクトリ配備には対応していません。
Webアプリケーション(warファイル)内にサーブレットAPI(javax.servlet.XXXパッケージの)クラスが存在すると、
JSPのコンパイルに失敗します。WebアプリケーションからサーブレットAPI実装を削除して配備してください。
次の条件に当てはまるアプリケーションはリクエストパラメータをデコードする際の文字コードがWebOTX AS V9以前と異なります。
WebOTX AS V9ではアプリケーションからの文字コード指定が行われていない場合、文字コード"ISO-8859-1"固定(B)でデコードしたパラメータを取得しますが、WebOTX AS V10ではアプリケーションからの文字コード指定が行われていない場合、URIencoding(C)で指定した文字コードでデコードしたパラメータを取得します。
WebOTX AS V9でパラメータが"ISO-8859-1"でデコードされることを前提にアプリケーションを作成(D)していた場合、WebOTX AS V10では文字化けが発生します。
この部分の処理に合わせアプリケーション単位(A)もしくはHTTPリスナ単位(B)で文字コードを"ISO-8859-1"に設定すると、forward前でもリクエストパラメータを取得している場合そちらが文字化けしてしまいます。 そのような場合、文字化けを解消するにはアプリケーション処理(D)の部分を修正するか、次の様にアプリケーションにサーブレットFilterを設定し、必要な部分にsetCharacterEncoding()を行う事で対処する必要があります。
<web-app>
:
<filter>
<filter-name>Set Character Encoding</filter-name>
<filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>ISO-8859-1</param-value>
</init-param>
<init-param>
<param-name>ignore</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>Set Character Encoding</filter-name>
<url-pattern>/hoho</url-pattern>
</filter-mapping>
:
</web-app>
<url-pattern>にはgetParameter()を実行しているサーブレット、JSPのパスを指定します。
Webアプリケーションをロードする際、セキュリティ設定をチェックします。その結果次のようなエラーログが出力されることがあります。
Webアプリケーションの動作に影響はありませんが、認証処理が行われないパターンがあることを警告するものです。
セキュリティ設定の見直しをご検討ください。
ERROR CATALINA - For security constraints with URL pattern [/jsp/*] only the HTTP methods [POST GET] are covered. All other methods are uncovered.
以下の設定を例に説明いたします。URL /jsp/* へのリクエストのうち、HTTPメソッドがGETもしくはPOSTであれば認証処理を行います。 しかしPUTやDELETEなどそれ以外のHTTPメソッドの場合は認証処理を行いません。GET、POST以外のHTTPメソッドのリクエストが認証されず 問題となる場合は、<http-method>の設定なくす(<http-method>を設定しない場合は全てのHTTPメソッドが認証処理の対象)などの見直しを行います。
<web-app>
:
<security-constraint>
:
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/jsp/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
:
マイクロサービス環境のMicroProfile Health Check(/health エンドポイント)にInternet Explorerブラウザよりアクセスした場合 レスポンス結果をファイルに保存しようとします。この時、Health Checkの結果がネガティブでありレスポンスのステータスコードが 503であった場合、ブラウザのファイルへの保存処理が終了しない現象が発生する場合があります。 この現象はInternet Explorerブラウザ固有の動作であり回避する方法はありません。ブラウザからHealth Check結果を確認する必要が ある場合は他のブラウザからアクセスしてください。
full-profile環境ではマイクロサービスのヘルスチェック、メトリクス機能が動作するため /health、/metricsエンドポイントを使用します。 しかし、マイクロサービスが有効な状態でアプリケーションのコンテキストルートを/health、/metricsで配備した場合、リクエストは配備したアプリケーションが優先されます。 マイクロサービスのヘルスチェック、メトリクス機能を使用する場合、コンテキストルートに/health、/metricsを使用しないでください。
StandardでWebアプリケーションがプロセスグループ上で動作している場合、forwardによって呼び出せるWebアプリケーションは同じアプリケーショングループ、プロセスグループに配備されているWebアプリケーションのみです。これは、forwardの処理は、同一プロセスないで行うため、プロセスをまたがったWebアプリケーションの呼び出しができないためです。
StandardでWebアプリケーションがプロセスグループ上で動作している場合、WebアプリケーションからのEJBの呼び出しはデフォルトではローカル呼び出しです。
Standardにおいて
Webアプリケーションがプロセスグループ（複数プロセス）で動作している場合、HTTPリクエストを前回利用したプロセスに振り分けるために、セッションIDにプロセスIDを含めます。このためセッションIDのフォーマットが次のように変わります。
"セッションID(32桁) $
プロセスID" 例：C7C25B729C39629558DB02C5FA25E038$6212
jvmRouteを付加した場合は次のように変わります。
"セッションID(32桁) . jvmRoute $
プロセスID" 例:5B22AF53A66CAB1AB26490EB430D36C3.hoho1$3936
※プロセス数が１で、動的にプロセス数を変更する場合などプロセスIDを付加したい場合は、"-Dorg.apache.catalina.session.CompulsionPid=on"をプロセスグループのJVMオプションに設定してください。詳細は[ リファレンス >
設定 >
Webコンテナ >
HTTPセッション管理について >
WebOTXの高度な設定(アプリケーションをプロセスグループに配備した場合の設定) ] を参照してください。
このような場合はアプリケーションの作りによりそのままアプリケーションを移行しただけですと例外が発生するケースがあります。
例えば、Spring や Struts などのフレームワークを利用している場合がこれに該当する場合があります。
上記のようなフレームワークでは、認証に関する処理もフレームワークの中に実装している場合があります。このような場合、認証処理が J2EE
に準拠した動作をする場合があります。これはアプリケーションが J2EE
を意識するかしないかに関わらず動作する可能性があります。
このようなアプリケーションを V8.1以前の Web Edition で動作させていた場合は J2EE
に関する処理は動作しません。
しかし V8.1以前の Standard-J Edition 以上、もしくは V8.2以降
でこのようなアプリケーションを動作させた場合、Web Edition では動作していなかった J2EE
の処理が動作し、予期せぬエラーが発生する場合があります。
もし、J2EE に準拠しない純粋な Webアプリケーションとして作成している場合は、上記のような現象が発生した場合 WebOTX を
Web Edition 相当の動作をするよう設定変更してください。
設定方法：
j2ee-enabled と sso-enabled を false に設定します。
運用管理コマンドの例：
otxadmin> set server.web-container.property.j2ee-enabled=false otxadmin> set server.http-service.virtual-server.<仮想サーバ名>.sso-enabled=false
＃マニュアルでは次の箇所を参照してください。
[
リファレンス
> 設定
> Webコンテナ
> Webコンテナ設定項目一覧
> MOで設定可能な項目一覧
] のj2ee-enabled と sso-enabledの箇所
RequestDispatcherクラスの forward メソッドを利用してリクエストの別のサーブレットに転送した場合に、レスポンスがflush（コミットされてクライアントに返却される）されるタイミングがV7.x と V8.x で異なります。
上記のように、V7.x では forward先サーブレットの処理が終了しforward元に処理が戻り forward元のリクエストの処理も完全に 終了してからレスポンスがflushされます。一方 V8.x は forward先サーブレットの処理が終了して forward元サーブレットに戻った時点でレスポンスがflushされます。
既定値では上記の動作ですが、設定により変更が可能です。設定方法は次の2通りです。
JavaVMオプションでは次のオプションを指定します。
com.nec.webotx.enterprise.forwardResponseFlush
例）
otxadmin> create-jvm-options -Dcom.nec.webotx.enterprise.forwardResponseFlush=true
nec-web.xmlでは次のプロパティで指定します。
<nec-web-app>
<context-root>コンテキストA</context-root>
<property name="forwardResponseFlush" value="true"/>
:
両方とも、true(V8.xの動作)/false(V7.xの動作)が指定可能です。既定値はV8.xの場合はtrue、V7.xの場合はfalseとなります。
JavaVMオプションの有効範囲は全Webアプリケーション、nec-web.xmlの有効反映はWebアプリケーション内です。両方指定された場合はnec-web.xmlでの指定が優先します。
※本設定はアプリケーションをエージェントプロセスに配備した場合のみ有効です。アプリケーションをプロセスグループに配備した場合は常に V7.x の動作となります。
ドメイン停止中にリクエストが来た場合にagent.logに以下のログが出力される事がありますが、これはドメイン停止処理中に同時にリクエスト処理が実行されたことによるものですのでシステムへの影響はありません。
WARN com.nec.webotx - Uncaught thread exception. Thread: ＜スレッド名＞
アプリケーションをプロセスグループに配備している場合に、ドメイン起動時やプロセスグループ起動時にagent.logに以下のログが出力される事がありますが、これはJNDIに対し既に他のプロセスによって"__SYSTEM_webcont_pid_list"が作成済みである事を示すもので、アプリケーションへの影響はありません。
WARN JNDI - OTX04090017: Exception occurred in createSubcontext: [CORBAPooledThread-x] javax.naming.NameAlreadyBoundException: Subcontext "__SYSTEM_webcont_pid_list" already present
制限事項は特にありません。
制限事項は特にありません。