コンテンツ

目次

一般

まず、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 の仕様をサポートしています。仕様のバージョン間の変更は、各仕様ドキュメントの変更点付録にあります。

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 属性のデフォルト値は、Tomcat の旧バージョンと同じ「ISO-8859-1」になります。

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

レルム

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

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

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

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

  • 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 で、別のプロジェクトです。

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

  • maxActive 構成オプションの名前が maxTotal に変更されました。
  • maxWait 構成オプションの名前が maxWaitMillis に変更されました。
  • JDBC ドライバー JAR は、ドライバークラスがその Web アプリケーションでのみ使用される場合、 $CATALINA_BASE/lib の代わりに WEB-INF/lib に配置できます。
  • 接続検証では、検証クエリと 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 は、Context のみが使用されるため、Container から Context に移動しました。
  • Mapper は、Mapper が特定のサービスのすべてのコネクタで同じであるため、Connector から Service に移動しました。
  • エイリアス、VirtualLoader、VirtualDirContext、JAR リソース、および外部リポジトリを、各機能ごとに個別に実装するのではなく、単一のフレームワークに統合する新しい Resources 実装。
  • セッション ID の生成を拡張可能にする新しいインターフェース SessionIdGenerator が追加されました。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/