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 が含まれている場合、次の JSP ページは Tomcat 7 でコンパイルできなくなります。

<%@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 属性。

個別の正規表現は、「|」演算子（または）を使用して連結できることに注意してください。「|」を使用すると、このバージョンと以前の 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 以降でのみサポートされていることに注意してください。issue 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 の生成の変更は、セッション ID の生成が最初に作成されてから java.secure.SecureRandom が改善されたことを利用しています。構成の変更は次のとおりです。

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

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

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

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

上記の値の "/./" 文字は、JRE issue #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: これは削除されました。同等の効果は、Web アプリケーションまたはグローバル CATALINA_BASE/conf/web.xml ファイルの session-config/tracking-mode 要素を構成することで得られます。

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

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

Cookieの値またはパスに、引用符で囲む必要がある文字（RFC2109仕様に基づく）が含まれている場合、Cookieはクライアントに送信される前に自動的に「バージョン0」のCookieから「バージョン1」のCookieに変換され、それらの値は二重引用符で囲まれます。引用符で囲む必要がある文字は、org.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATORなどのいくつかのシステムプロパティによって制御されます。Internet Explorerが「バージョン1」のCookieを処理する際に問題があることが知られています。（バグ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検証の設定が簡略化されました。Host要素からxmlValidationおよびxmlNamespaceAware属性が削除されました。これらの属性は、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ファイルをWebフラグメントとアノテーションから結合する方法が定義されています。サーバー全体のデフォルトを定義するグローバルなconf/web.xmlファイルの処理は、これらの規則の実装の結果として変更されました。

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

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

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

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

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

metadata-complete属性は、Servlet 2.5仕様以降でサポートされています。absolute-ordering要素にはServlet 3.0が必要です。

2番目の方法は、名前によって特定のJARファイルを無視するようにJarScannerコンポーネントを構成することです。これは通常、conf/catalina.propertiesファイルで構成されます。詳細については、構成リファレンスのシステムプロパティの章のjarsToSkipプロパティに関するドキュメントを参照してください。Tomcat 7.0.30以降では、Servlet 3.0のスキャン（アノテーションとWebアプリケーションフラグメントのスキャン）、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インターフェースの標準実装。
• ジェネリックの使用。
• Host内のContextの一意の識別子として、ContextパスではなくContext名を使用すること。

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

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

• 7.0.51以降では、Webアプリケーションクラスローダーが、システムクラスローダーよりもクラスをロードする際の優先度が高くなりました。

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

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

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

  参照: AJPコネクタ。

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

  参照: AJPコネクタ。

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

  参照: AJPコネクタ。

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

  参照: AJPコネクタ。

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

下のボックスから構成ファイル、古いバージョン、新しいバージョンを選択し、「違いを表示」をクリックすると、違いが新しいタブ/ウィンドウに表示されます。

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

作業コピー内から次のようなGitコマンドを使用することもできます。

git diff 7.0.0 7.0.80 -- conf/