コンテンツ

目次

一般

まず、一般的な移行ガイドページをお読みください。Apache Tomcat® のバージョン間の移行またはアップグレードに適用される一般的な考慮事項について説明しています。

7.0.x から 8.0.x への移行

このセクションでは、アップグレード時に後方互換性の問題を引き起こす可能性のある、7.0.x と 8.0.x の間の既知のすべての変更点をリストします。

Java 7 が必要

Apache Tomcat 8.0.x には Java 7 以降が必要です。 Apache Tomcat 7.0.x には Java 6 が必要でした。

仕様 API

Apache Tomcat 8 は、Java Servlet 3.1、JavaServer Pages 2.3、Java Unified Expression Language 3.0、および Java API for WebSocket 1.1 仕様をサポートしています。仕様のバージョン間の変更は、各仕様ドキュメントのChanges付録に記載されています。

Servlet 3.1 API

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

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

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

JavaServer Pages 2.3

Unified Expression Language 3.0 では、静的フィールドとメソッドを参照するためのサポートが追加されました。 JSP でこの機能をサポートするには、javax.servlet.jsp.el.ScopedAttributeELResolverの実装を変更して、インポートされたクラスまたはフィールドの名前であるかどうかを識別子もチェックする必要がありました。状況によっては、この変更により大幅な速度低下が発生します。これは、ページ、リクエスト、セッション、またはアプリケーションスコープの変数を示す可能性のある識別子、または未定義である可能性のある識別子に影響します。未定義の場合、インポートされたクラスまたはフィールドであるかどうかをチェックするようになったため、識別子の解決に非常に時間がかかります。この速度低下を回避するには、次のようなコードを

${undefined}

次のように置き換える必要があります。

${requestScope.undefined}

または、変数が定義されている適切なスコープを使用して、同様の方法で置き換えます。

Jar スキャン

Servlet 3.1 の実装中に、Tomcat 7 の Servlet 3.0 プラガビリティの実装でいくつかのエラーが特定されました。具体的には

  • SCI スキャンがクラスローダーの順序に従っていませんでした。
  • コンテナ JAR 内のフラグメントが無視されるのではなく処理されました。
  • コンテナが提供する SCI が無視されることがありました。

これらの問題は Tomcat 8 用に修正されましたが、修正にはJarScannerコンポーネントへの重要な API 変更と構成オプションへの変更が必要だったため、Tomcat 7 にはバックポートされませんでした。

Tomcat 8 に移行する場合、Jar スキャンの構成を見直し、新しい構成オプションに合わせて調整する必要があります。また、カスタムJarScannerの実装を更新して、新しい API を実装する必要があります。

デフォルトのコネクタ実装

デフォルトの HTTP および AJP コネクタの実装は、Java ブロッキング IO 実装 (BIO) から Java 非ブロッキング IO 実装 (NIO) に切り替えられました。 BIO は引き続き使用できますが、非ブロッキング IO を使用する Servlet 3.1 および WebSocket 1.0 の機能は代わりにブロッキング IO を使用するため、予期しないアプリケーションの動作が発生する可能性があります。

デフォルトの URL エンコーディング

HTTP および AJP コネクタのURIEncoding属性のデフォルト値が、"ISO-8859-1" から "UTF-8" に変更されました（「厳密なサーブレット準拠」モードがオフの場合。これがデフォルトです）。この設定は、リクエスト URI のパスおよびクエリ内の '%xx' エンコードされたバイトをデコードするために使用される文字エンコーディングを指定します。

サーバーが「厳密なサーブレット準拠」で構成されている場合、コネクタのURIEncoding属性のデフォルト値は "ISO-8859-1" であり、Tomcat の古いバージョンと同じです。

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

レルム

ダイジェストされたパスワードの処理は、新しいCredentialHandlerコンポーネントに移動されました。関連するRealm属性は 8.0.x でも引き続き機能しますが、非推奨となり、Tomcat 8.5.x 以降では削除されました。

Web アプリケーションリソース

Web アプリケーションにリソースを追加する方法を提供していたエイリアス、VirtualLoader、VirtualDirContext、JAR リソース、および外部リポジトリの機能はすべて、個別に実装するのではなく、単一のフレームワークに置き換えられました (これは維持がますます困難になっていました)。resourcesドキュメントには、新しい実装の使用方法の詳細が記載されています。

リソースのリファクタリングにより、デフォルトの Context 実装 (org.apache.catalina.core.StandardContext) から多くの属性が削除されました。次の属性は、Web アプリケーションで使用されるresources実装を介して構成できるようになりました。

  • allowLinking
  • cachingAllowed
  • cacheMaxSize
  • cacheObjectMaxSize
  • cacheTtl (名前が変更されました: Tomcat 7 では cacheTTL でした)

たとえば、Tomcat 7 と Tomcat 8 の構成は次のようになります。

<!-- Tomcat 7: -->
<Context allowLinking="true" />

<!-- Tomcat 8: -->
<Context>
  <Resources allowLinking="true" />
</Context>

データベース接続プーリング

Tomcat 8 も Tomcat 7 と同様に、データベース接続プールの 2 つの実装が同梱されています。最初の実装（デフォルトの実装。厳密に言うと、これはjavax.sql.DataSource.Factoryシステムプロパティを介して変更できます）は、Apache Commons DBCP 2.x プロジェクトのコピーであり、別のパッケージに名前が変更されています。2 番目の実装は、Tomcat JDBC Connection Pool という別のプロジェクトです。

Apache Commons DBCP 1.x (Tomcat 7 以前で使用) と Apache Commons DBCP 2.x の間には、構成の変更が必要になる可能性のある、いくつかの注目すべき変更があります。

  • maxActive 構成オプションの名前が maxTotal に変更されました
  • maxWait 構成オプションの名前が maxWaitMillis に変更されました
  • JDBC ドライバークラスがその Web アプリケーションのみで使用される場合は、$CATALINA_BASE/lib の代わりに WEB-INF/lib に JDBC ドライバー JAR を配置できます。
  • 接続の検証では、検証クエリと testXxx 属性の少なくとも 1 つを true に設定する必要があります。検証クエリが定義されておらず、testxxx 属性の少なくとも 1 つが true の場合、接続は Connection.isValid() を使用して検証されます。
  • removeAbandoned 構成オプションは、removeAbandonedOnBorrow および removeAbandonedOnMaintenance に置き換えられました。

さらに、Commons DBCP には、多くの新しい構成オプションが追加されました。これらのオプションを見直し、どれを使用する必要があるか判断する必要があります。

Tomcat JDBC Connection Pool (またはサードパーティのデータベース接続プールの実装) を使用している場合は、上記の変更は必要ないことに注意してください。

クラスタリング

Servlet 3.1 でHttpServletRequest.changeSessionId()メソッドが追加されたため、org.apache.catalina.ha.session.JvmRouteSessionIDBinderListenerは不要になったため削除されました。 Tomcat 8 にアップグレードする場合は、クラスタ構成から削除する必要があります。

デバッグ

リモートデバッグを有効にするためにjpdaオプションを指定して Tomcat を起動すると、Tomcat 8 はデフォルトでlocalhost:8000をリッスンします。以前のバージョンでは、*:8000をリッスンしていました。必要に応じて、このデフォルトは、たとえばsetenv.[bat|sh]でJPDA_ADDRESS環境変数を設定することでオーバーライドできます。

内部 API

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

特に注意すべき点は次のとおりです。

  • Manager、Loader、および Resources は、Container から Context に移動しました。これは、Context でのみ使用されるためです。
  • Mapper は、Connector から Service に移動しました。これは、Mapper が特定の Service のすべての Connector で同じであるためです。
  • エイリアス、VirtualLoader、VirtualDirContext、JAR リソース、および外部リポジトリを、各機能ごとに個別に実装するのではなく、単一のフレームワークにマージする新しい Resources 実装。
  • 新しいインターフェース SessionIdGenerator が追加され、セッション ID の生成が拡張可能になりました。 ID ジェネレータークラス名を取得および設定するメソッドが Manager インターフェースに追加されました。

デプロイメント

WAR ファイルとして Web アプリケーションをデプロイし、Tomcat が WAR を展開しないように構成すると、起動時間が大幅に遅くなり、実行時のパフォーマンスも低下します。起動時間は 3 倍から 10 倍遅くなると測定されています。ランタイムへの影響は、アプリケーションの構造に大きく依存します。

Host でunpackWARs="false"を設定したり、Context でunpackWAR="false"を設定したりしないことを強くお勧めします。以下は、展開を無効にする一般的な理由と、Tomcat 8 の推奨される代替案のリストです。

  • セキュリティ (appBase は Tomcat ユーザーに対して読み取り専用) - (別のユーザーとして) WAR ファイルではなく、展開されたディレクトリを appBase にデプロイします。
  • 複数のホスト間で appBase を共有 - WAR ファイルを共通の場所にデプロイし、context.xml ファイルを使用して、必要に応じて Web アプリケーションをホストに追加します。複数のホスト間で appBase を共有することは、どのような状況でも強く推奨されないことに注意してください。
  • オフラインデプロイメント - Tomcat 8.0.21 以降では、Tomcat は実行されていないときに WAR が更新されたことを検出し、次に起動したときに、古い展開されたディレクトリを削除し、更新された WAR ファイルをデプロイします。したがって、unpackWAR="true"を使用し、Tomcat が実行されていないときに WAR をデプロイし続けてください。

8.0.x のアップグレード

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

Tomcat 8.0.x の注目すべき変更点

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

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

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

Tomcat 8.0.x の設定ファイルの違い

以下のボックスから構成ファイル、古いバージョン、および新しいバージョンを選択し、[差分を表示] をクリックして差分を表示します。差分は新しいタブ/ウィンドウに表示されます。

次のコマンドと同様の Subversion コマンドも使用できます (すべて 1 行)

svn diff
  --old=http://svn.apache.org/repos/asf/tomcat/archive/tc8.0.x/tags/TOMCAT_8_0_1/conf/
  --new=http://svn.apache.org/repos/asf/tomcat/archive/tc8.0.x/tags/TOMCAT_8_0_3/conf/