Apache Tomcat^®

Apache Tomcat 7.0.xではJava 6以降が必要です。Apache Tomcat 6.0.xではJava 5が必要でした。

Apache Tomcat 7は、Java Servlet 3.0、JavaServer Pages 2.2、Expression Language 2.2、WebSocket 1.1の仕様をサポートしています。仕様のバージョン間の変更点は、各仕様ドキュメントの「変更点」付録に記載されています。

ワイルドカードインポート構文を使用するJSPページでは、Servlet APIに追加された新しいクラスがWebアプリケーション内のクラスと競合する可能性があります。例えば、パッケージ"a"にクラスPartが含まれている場合、Tomcat 7では以下のJSPページはコンパイルされなくなります。

<%@page import="a.*"%>
<% Part page = new Part(); %>

これは、javax.servlet.http.*の暗黙的なインポートとa.*の明示的なインポートが、Servlet 3.0で追加されたクラスPartの競合する定義を提供するためです。解決策は、明示的なインポートimport="a.Part"を使用することです。

正規表現を使用するすべての設定オプションは、カンマ区切りまたはセミコロン区切りの式のリストではなく、単一の正規表現 (java.util.regexを使用) を必要とするようになりました。

これは以下に関連します

• RemoteAddrFilter、RemoteHostFilter フィルタ、およびRemoteAddrValve、RemoteHostValve バルブのallowおよびdeny属性。
• RemoteIpFilter、RemoteIpValveのinternalProxies、trustedProxies属性。
• ReplicationValveのfilter属性。
• HTTPコネクタのrestrictedUserAgents、noCompressionUserAgents属性。

個別の正規表現は、「|」演算子 (OR) を使用して連結できることに注意してください。「|」を使用すると、現在のTomcatバージョンと以前のTomcatバージョンの両方で機能します。

XMLコンテキスト記述子 (META-INF/context.xmlファイル) は、デプロイされたWARおよびディレクトリからホストのxmlBaseにコピーされなくなりました。Tomcat 6のデフォルトの動作は、Host要素のcopyXML属性をtrueに設定することで有効にできます。

ホストのappBase外のWARは、バージョン7.0.12から7.0.47まで（両端を含む）のHostのunpackWARs設定の値にかかわらず、展開されません。この展開はバージョン7.0.48以降でのみサポートされていることに注意してください。問題51294を参照してください。

マネージャーアプリケーションはTomcat 7以降で再構築され、一部のURLが変更されました。マネージャーアプリケーションにアクセスするために使用されるすべてのURLは、以下のいずれかのオプションで始まる必要があります。

• HTML GUIの場合は<ContextPath>/html
• テキストインターフェースの場合は<ContextPath>/text
• JMXプロキシの場合は<ContextPath>/jmxproxy
• ステータスページの場合は<ContextPath>/status

テキストインターフェースのURLが「<ContextPath>」から「<ContextPath>/text」に変更されたことに注意してください。

マネージャーアプリケーションを使用するために必要なロールは、単一のmanagerロールから以下の4つのロールに変更されました。アクセスしたい機能に必要なロールを割り当てる必要があります。

• manager-gui - HTML GUIとステータスページへのアクセスを許可します。
• manager-script - テキストインターフェースとステータスページへのアクセスを許可します。
• manager-jmx - JMXプロキシとステータスページへのアクセスを許可します。
• manager-status - ステータスページのみへのアクセスを許可します。

HTMLインターフェースはCSRFから保護されていますが、テキストおよびJMXインターフェースは保護されていません。CSRF保護を維持するには、

• manager-guiロールを持つユーザーには、manager-scriptまたはmanager-jmxロールのいずれも付与されるべきではありません。
• manager-scriptまたはmanager-jmxロールを持つユーザーがブラウザを通じてマネージャーアプリケーションにアクセスする場合（例：これらのインターフェースは人間ではなくツール向けであるため、テキストまたはJMXインターフェースをテストする場合）、セッションを終了するために、その後すべてのブラウザウィンドウを閉じる必要があります。

ロールコマンドは、デフォルト設定では機能せず、ほとんどのレルムがロールのリスト提供をサポートしていないため、マネージャーアプリケーションから削除されました。

ホストマネージャーアプリケーションはTomcat 7以降で再構築され、一部のURLが変更されました。ホストマネージャーアプリケーションにアクセスするために使用されるすべてのURLは、以下のいずれかのオプションで始まる必要があります。

• HTML GUIの場合は<ContextPath>/html
• テキストインターフェースの場合は<ContextPath>/text

テキストインターフェースのURLが「<ContextPath>」から「<ContextPath>/text」に変更されたことに注意してください。

ホストマネージャーアプリケーションを使用するために必要なロールは、単一のadminロールから以下の2つのロールに変更されました。アクセスしたい機能に必要なロールを割り当てる必要があります。

• admin-gui - HTML GUIとステータスページへのアクセスを許可します。
• admin-script - テキストインターフェースとステータスページへのアクセスを許可します。

HTMLインターフェースはCSRFから保護されていますが、テキストインターフェースは保護されていません。CSRF保護を維持するには、

• admin-guiロールを持つユーザーには、admin-scriptロールを付与するべきではありません。
• admin-scriptロールを持つユーザーがブラウザを通じてホストマネージャーアプリケーションにアクセスする場合（例：このインターフェースは人間ではなくツール向けであるため、テキストインターフェースをテストする場合）、セッションを終了するために、その後すべてのブラウザウィンドウを閉じる必要があります。

セッションID生成の変更を含む、セッションの生成と破棄のパフォーマンスを向上させるため、セッションマネージャーに多くの変更が加えられました。セッションID生成の変更は、セッションID生成が最初に書かれた時以降のjava.secure.SecureRandomの改善を利用しています。設定変更点は以下の通りです。

• ManagerのrandomClass属性がsecureRandomClassに変更され、提供されるクラスはjava.secure.SecureRandomを継承する必要があります。
• SecureRandomの実装を選択できるように、secureRandomAlgorithmとsecureRandomProviderの2つの新しいプロパティが追加されました。
• algorithm属性は削除されました。
• entropy属性は削除されました。

java.secure.SecureRandomの既知の問題の1つは、その初期化にエントロピーソースからのランダムなデータが必要であることです。一部のエントロピーソース実装では、十分なランダムなデータを収集するのに時間がかかる場合があります。セッションIDジェネレータの初期化に顕著な時間 (100ms以上) がかかる場合、診断メッセージがログに記録されます。例:

日付 org.apache.catalina.util.SessionIdGenerator createSecureRandom
INFO: [SHA1PRNG]を使用したセッションID生成のためのSecureRandomインスタンスの作成に[406]ミリ秒かかりました。

システムプロパティを定義することで、JREが使用するエントロピーソースを変更することが可能です。例:
-Djava.security.egd=file:/dev/./urandom

上記の値の「/./」文字は、JREの問題 #6202721を回避するためのものです。

Servlet 3.0仕様にSessionCookieConfigが追加されたことにより、設定およびコードの複雑さを軽減するため、いくつかのセッションクッキー設定オプションが削除されました。

• Connector.emptySessionPath: これは削除されました。同等の効果は、グローバルcontext.xml (CATALINA_BASE/conf/context.xml内) でsessionCookiePath="/"を設定することで得られます。
• org.apache.catalina.SESSION_COOKIE_NAMEシステムプロパティ: これは削除されました。同等の効果は、グローバルcontext.xml (CATALINA_BASE/conf/context.xml内) でsessionCookieName属性を設定することで得られます。
• org.apache.catalina.SESSION_PARAMETER_NAMEシステムプロパティ: これは削除されました。同等の効果は、グローバルcontext.xml (CATALINA_BASE/conf/context.xml内) でsessionCookieName属性を設定することで得られます。
• Context.disableURLRewriting: これは削除されました。同等の効果は、ウェブアプリケーションまたはグローバルなCATALINA_BASE/conf/web.xmlファイルでsession-config/tracking-mode要素を設定することで得られます。

Tomcat 7では、セッションクッキーとSSOクッキーはデフォルトでHttpOnlyフラグを付けて送信されます。これはブラウザに対し、JavaScriptからこれらのクッキーへのアクセスを禁止するよう指示するためです。これはより安全であると考えられますが、JavaScriptがクッキーの値にアクセスできなくなります。この機能は、Context要素のuseHttpOnly属性によって制御できます。(この機能はTomcat 6.0の最新バージョンでも実装されていますが、デフォルトではオフになっています。ウェブアプリケーションまたはグローバルなCATALINA_BASE/conf/context.xmlファイル内のContext要素にuseHttpOnly="true"を設定することで有効にできます)。

Tomcatはデフォルトで、仕様に準拠しない名前のみのクッキーを受け入れなくなりました。ただし、名前のみのクッキーを受け入れるために使用できる新しいシステムプロパティorg.apache.tomcat.util.http.ServerCookie.ALLOW_NAME_ONLYが追加されました。

クッキーの値またはパスに、(RFC2109仕様に従い) 引用符で囲む必要がある文字が含まれている場合、クッキーはクライアントに送信される前に自動的に「バージョン0」クッキーから「バージョン1」クッキーに変換され、それらの値は二重引用符で囲まれます。どの文字を引用符で囲む必要があるかは、org.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATORなどのいくつかのシステムプロパティによって制御されます。Internet Explorerが「バージョン1」クッキーの処理に問題があることが知られています。(バグ57872)。

SSLセッションIDにアクセスするために提供されていたカスタムリクエスト属性javax.servlet.request.ssl_sessionは、Servlet仕様で定義されている新しい標準リクエスト属性javax.servlet.request.ssl_session_idを優先して非推奨になりました。このカスタム属性のサポートはTomcat 8で削除されます。

セキュリティマネージャー下でCometが正しく動作するようにするため、Cometクラスはorg.apache.catalinaパッケージからorg.apache.catalina.cometパッケージに移動されました。Cometを使用するコードは、新しいパッケージ名を反映するように更新および再コンパイルする必要があります。

XML検証の設定が簡素化されました。xmlValidationおよびxmlNamespaceAware属性がHost要素から削除されました。これらの属性は、tldValidationおよびtldNamespaceAwareとともに、Context要素ごとに設定されるようになりました。デフォルト (各属性ともfalse) は変更されていません。ただし、Servlet仕様の要件に従い、org.apache.catalina.STRICT_SERVLET_COMPLIANCEシステムプロパティがtrueに設定されている場合、XML検証と名前空間認識はデフォルトで有効になります。

org.apache.catalina.STRICT_SERVLET_COMPLIANCEシステムプロパティは、その効果をより細かく制御できるように変更されました。各動作変更は、専用のシステムプロパティによって制御されるようになりました。デフォルトの動作は変更されていません。org.apache.catalina.STRICT_SERVLET_COMPLIANCEシステムプロパティは、他のシステムプロパティに対して仕様準拠のデフォルトが使用されるかどうかを制御するようになりました。org.apache.catalina.STRICT_SERVLET_COMPLIANCEがtrueであっても、個々のシステムプロパティの設定が常に優先されます。

org.apache.coyote.MAX_TRAILER_SIZEは削除され、ConnectorのmaxTrailerSize属性に置き換えられました。

Servlet 3.0仕様は、ウェブフラグメントとアノテーションからアプリケーションのweb.xmlファイルを結合する方法を定義しています。これらのルールを実装した結果、サーバー全体のデフォルトを定義するグローバルなconf/web.xmlファイルの処理が変更されました。

顕著な違いの1つは、グローバルなconf/web.xmlで定義されたフィルタが、ウェブアプリケーションで定義されたフィルタに先行するのではなく、それに続くようになったことです。詳細については、問題51754および52138を参照してください。

ウェルカムファイルの処理は、Servlet 3.0仕様の明確化に従って変更されました。ウェルカムファイルのリストにサーブレットによって処理されるファイル（*.jspなど）が含まれている場合、動作の変更が見られるかもしれません。ContextのresourceOnlyServletsオプションを参照してください。

Servlet 3.0仕様で義務付けられているアノテーションスキャンは、ウェブアプリケーションの起動時間に影響を与え、スキャンされたクラスをロードするために必要なメモリ要件を増加させる可能性があります。Servlet EGからの明確化により、Servlet 2.4およびそれ以前のバージョンの仕様を使用するアプリケーションでさえスキャンされていることに注意してください。問題53619およびユーザーメーリングリストでの関連議論を参照してください。

この問題に対処する方法はいくつかあります。推奨される方法は、アノテーションスキャンを必要としないアプリケーションをそのようにマークすることです。これは、アプリケーションのWEB-INF/web.xmlで以下の手順を実行することで可能です。

• web-app要素を更新し、ウェブアプリケーションが仕様バージョン3.0を使用していることを示します。version、xsi:schemaLocation、xmlns、およびxmlns:xsi属性の値は、デフォルトのconf/web.xmlファイルからコピーできます。
• web-app要素にmetadata-complete="true"属性を追加します。
• 空の<absolute-ordering />要素を追加します。

metadata-complete属性はServlet 2.5仕様からサポートされています。absolute-ordering要素はServlet 3.0を必要とします。

2つ目の方法は、JarScannerコンポーネントを設定して、特定のJARファイルをその名前に従って無視するようにすることです。これは通常、conf/catalina.propertiesファイルで設定されます。詳細については、設定リファレンスのシステムプロパティ章にあるjarsToSkipプロパティのドキュメントを参照してください。Tomcat 7.0.30以降では、Servlet 3.0スキャン（アノテーションとウェブアプリケーションフラグメントのスキャン）、TLDスキャン（タグライブラリ）、またはその両方でスキップするJARを個別に設定することが可能です。Tomcatのさらなるバージョンでは、この機能を制御するためのより良い方法が提供されるかもしれません。

TLD処理にはいくつかの改善が加えられました。整合性を向上させ、重複を減らすための内部リファクタリングに加えて、いくつかの機能改善があります。これらは以下の通りです。

• タグファイル内のEL処理が、そのタグファイルに対して宣言されたJSPバージョンと一致するようになりました。
• JSP仕様のJSP.7.3.1節の要件が適用されるようになり、TLDファイルをWEB-INF/libまたはWEB-INF/classesに配置することは許可されなくなりました。

Tomcat 7の内部APIはTomcat 6と概ね互換性がありますが、詳細レベルで多くの変更があり、バイナリ互換性はありません。Tomcatの内部とやり取りするカスタムコンポーネントの開発者は、関連するAPIのJavaDocを確認する必要があります。

特に注目すべき点は以下の通りです。

• すべてのコンポーネントが拡張するLifecycleインターフェースの標準実装。
• ジェネリクスの使用。
• ホスト内のContextの一意な識別子として、ContextパスではなくContext名を使用すること。

パフォーマンス最適化の1つを制御するJspServletの初期化パラメータが、genStrAsCharArrayからgenStringAsCharArrayに名称変更され、Apache AntのJasperタスクにおける関連属性名と一致するようになりました。

Tomcat開発者は、各パッチリリースが以前のリリースと完全に後方互換性を持つことを目指しています。しかし、バグを修正するために後方互換性を破る必要がある場合があります。ほとんどの場合、これらの変更は気づかれないでしょう。このセクションでは、完全に後方互換性がない、またはアップグレード時に破損を引き起こす可能性のある変更点をリストアップします。

• 7.0.51以降では、ウェブアプリケーションクラスローダーは、クラスのロードにおいてシステムクラスローダーよりも優先度が高くなりました。

• 7.0.63以降では、コネクタのmaxPostSize属性における値0の意味が、maxSavePostSizeと一致させ、より直感的にするために、「制限なし」ではなく「ゼロの制限」を意味するように変更されました。

  参照: HTTPコネクタ、AJPコネクタ。

• 7.0.100以降では、AJPコネクタのデフォルトのlistenアドレスが、すべてのIPアドレスではなくループバックアドレスに変更されました。

  参照: AJPコネクタ。

• 7.0.100以降では、AJPコネクタのrequiredSecret属性は非推奨となり、secret属性に置き換えられました。

  参照: AJPコネクタ。

• 7.0.100以降では、AJPコネクタにsecretRequired属性が追加されました。この属性がデフォルトのtrueに設定されている場合、secretが指定されていない限りAJPコネクタは起動しません。

  参照: AJPコネクタ。

• 7.0.100以降では、AJPコネクタにallowedRequestAttributesPattern属性が追加されました。認識されない属性を持つリクエストは、403エラーでブロックされるようになりました。

  参照: AJPコネクタ。

Apache TomcatのインスタンスをTomcat 7のあるバージョンから別のバージョンにアップグレードする場合、特に$CATALINA_HOMEと$CATALINA_BASEに異なる場所を使用している場合、新しい属性やデフォルトの変更など、設定ファイルの変更がアップグレードの一部として適用されていることを確認する必要があります。これらの変更を特定するために、以下のフォームを使用してTomcat 7の異なるバージョンの設定ファイル間の差分を表示できます。

以下のボックスから設定ファイル、旧バージョン、新バージョンを選択し、「差分を表示」をクリックして差分を確認してください。差分は新しいタブ/ウィンドウに表示されます。

注意: 差分がない場合は、エラーページが表示されます。

作業コピー内から、以下のGitコマンドに似たものを使用することもできます。

git diff 7.0.0 7.0.80 -- conf/