Servletサービスの実行環境について
Servletサービスの実行環境はTomcat5.5.23をベースとしています。
Tomcat5.5.23とTomcat5.5.xの仕様の違いにより、Tomcat5.5.xで動作するServletもしくはJSPアプリケーションであっても動作しない場合があります。
Servletサービスのセション管理用クッキーについて
WebサーバがSSL環境で動作している場合には、セション管理用クッキーに自動的にSecure属性を付加します。
SSLアクセラレータを使用しておりWebサーバが非SSL(HTTP)で動作している場合にはSecure属性は自動的に付加しません。Secure属性を付加する方法については、「セキュリティシステム運用ガイド」の「Servletサービスにおける環境設定」を参照してください。
なお、クッキーによるセション管理はServletコンテナにより自動で行われます。アプリケーションでセション管理用クッキーの追加などの操作は行わないでください。セション継続やセキュリティ上の問題が発生する場合があります。
ServletサービスのJSPの更新反映について
配備済みのWebアプリケーションのJSPや、JSPから静的includeしているファイルを置き換えた場合、IJServerの再起動、モジュールの再活性、JSPのリロード機能により反映されますが、ファイルの日付が、前回JSPをコンパイルした日時より過去の場合は反映されません
以下のいずれかにより反映可能です。
ファイルの日付をマシンの現在時刻に更新する。
JSP事前コンパイルを-aオプションを指定して実行する。
コマンドの詳細は、「リファレンスマニュアル(コマンド編)」の「ijscompilejsp」を参照してください。
「コンテキストの共有」機能について
「コンテキストの共有」機能を使用して他のWebアプリケーションにディスパッチを行い、かつセションを使用するアプリケーションでは、以下に注意してください。
ディスパッチ先でセションを生成すると、ディスパッチ元でセションが存在しない場合はディスパッチ元でセションが自動的に生成されます。
ディスパッチ元でセションを破棄した場合、ディスパッチ先で生成済みセションがあっても、参照できません。
getSession()、getSession(true)では新規セション、getSession(false)ではnullとなります。
また、ディスパッチ元でセションを破棄しても、ディスパッチ先のセションは自動的に破棄されません。
必ず、ディスパッチ先のセションを破棄してからディスパッチ元のセションを破棄してください。
JSPのリロード機能について
JSPのリロード機能を使用し「リクエスト時」を設定している場合、JSPで発生する例外(IOExceptionやRuntimeExceptionなど)がServletExceptionのサブクラスでラップされて呼び出し元(フィルタや、ディスパッチ元のサーブレットやJSP)に通知される場合があります。
Servletサービスのチャンク形式エンコーディングについて 
Webサーバとして、Microsoft(R) Internet Information Servicesを利用する場合、Webアプリケーションに対してチャンク形式エンコーディングは適用できません。
Webブラウザなどのクライアントアプリケーションからリクエストメッセージを送信するには、Content-Lengthヘッダを指定するか、またはInterstage HTTP Serverを使用してください。
ロードバランサを使用しての負荷分散について
使用するロードバランサの設定に、一意性保証のキーワード重複チェックを行わない設定がある場合は、チェックを行わない設定にしてください。
