Tomcat 7からTomcat8にアップグレードする必要がありますか
私のプロジェクトは現在Tomcat 7で実行されています。Tomcat8にアップグレードする必要がありますか？それを行うことの長所と短所は何ですか？ Tomcat 8はパフォーマンス、メモリ使用率の点で優れていますか？
プロジェクトは既にTomcat 7で実行されているため、しばらくは現状を維持することをお勧めします。 Tomcat 8のパフォーマンスの改善に関するデータはあまりありません。製品の新しいリリースに共通するいくつかの問題がインターネット上で報告されています。
Tomcat 8は、並行環境でのパフォーマンスが向上しています。
Tomcat製品での私の経験からすると、非常にリソースを集中的に使用するアプリケーションがない限り、アップグレードによってパフォーマンスが大幅に向上することはほとんどありません。アップグレード前に以下のリンクをお読みください
重要な変更
Java 1.7 ==>最初の重要な変更は、Tomcat 8を実行するためにJava 7以降が必要になったことです。したがって、以前のTomcatバージョンから移行する場合はJava 7
Specification Changes
Servlet 3.1 (JSR 340)
JSP 2.3 (JSR 245 maintenance release)
EL 3.0 (JSR 341)
WebSocket 1.0 (JSR 356)
Specification Changes: EL 3.0
Coercion of nulls to Number, Character or Boolean
- EL 2.2 and earlier (0, 0, false)
- EL 3.0 and later (null, null, null)
System property
– org.Apache.el.parser.COERCE_TO_ZERO
– Set to true for EL 2.2 behaviour
Specification Changes: JSP 2.3
Minor changes to reflect the changes in EL 3.0
JSP 2.3
– Supported: GET, POST and HEAD
– Undefined: Everything else
JSP 2.2 and earlier
– Undefined: Most implementations assumed all
Tomcat only permits GET, POST and HEAD
– Protection against verb tampering
Specification Changes: WebSocket 1.0
Tomcat 7 initially shipped with a proprietary WebSocket API
- Tomcat 8 ships with a JSR 356 WebSocket implementation
– Also back-ported to Tomcat 7
- The proprietary WebSocket API is deprecated in Tomcat 7
- Applications using the proprietary API need to migrate
– Relatively simple
– https://svn.Apache.org/r1424733
Specification Changes: Servlet 3.1
- Session ID changes by default on authentication
– Prevents session fixation
Tomcat Changes:
Connectors
Default connector has changed from BIO to NIO
– BIO is likely to be dropped for Tomcat 9
- Only BIO option not supported by NIO is irrelevant for NIO
– disableKeepAlivePercentage
- May notice different network / CPU loads
– More established, idle connections
– Marginally higher CPU load
Static Resources
Tomcat 7
– Aliases
– VirtualLoader
– VirtualDirContext
– JAR resources
– External repositories
- All variations on a theme
- Each implemented differently
Tomcat 8
– New WebResources implementation
▪ JAR resources
– External resources for class loader
- Completely new configuration
- Caching attributes removed from Context
Resources now defined by as:
– Pre-resources
– Main resources
– JAR resources
– Post-resources
Resources attributes:
– base
– internalPath
– webappMount
– readOnly
Internal APIs
- Lots of changes
– Manager, Loader and Resources are now Context only
– Mapper moved from Connector to Service
– WebResources
- If you extend a Tomcat class, review the API docs
Database Connection Pools
- Tomcat 7 and earlier based on DBCP 1
- Tomcat 8 based on DBCP 2
- Better performance in concurrent environments
– Comparable to Tomcat’s JDBC pool
- There are some changes to configuration attributes
– Reflect consistency changes made in Commons Pool 2
- maxActive -> maxTotal
- maxWait -> maxWaitMillis
- Validation no longer requires a validation query
– Uses Connection.isValid()
サーバーコネクタ
サーバーコネクタに関して、デフォルトのHTTPおよびAJPコネクタ実装は、JavaブロッキングIO実装（BIO）からJavaノンブロッキングIO実装（ NIO）。古いBIOは引き続き使用できますが、ノンブロッキングIOを使用するServlet 3.1およびWebSocket 1.0機能は、代わりにブロッキングIOにフォールバックし、予期しないアプリケーション動作を引き起こす可能性があります。
Webアプリケーションリソース
構成の一部であり、Webアプリケーションで使用可能なすべてのリソースを表すResources要素が改訂されました。現在、クラス、JARファイル、HTML、JSP、およびWebアプリケーションに寄与するその他のファイルが含まれています。これらのリソースのソースとしてディレクトリ、JARファイル、およびWARを使用する実装が提供されており、リソース実装を拡張して、データベースやバージョン管理されたリポジトリなどの他のフォームに格納されたファイルのサポートを提供できます。
リモートデバッグ
リモートデバッグを有効にするjpdaオプションを使用してTomcat 8を起動すると、Tomcat 8はデフォルトでlocalhost：8000でリッスンします。以前のバージョンは*：8000でリッスンしていました。必要に応じて、たとえばsetenv。[bat | sh]でJPDA_ADDRESS環境変数を設定することにより、このデフォルトをオーバーライドできます。
APIの変更
Tomcat 8の内部APIはTomcat 7と幅広く互換性がありますが、詳細レベルで多くの変更が加えられており、バイナリ互換性はありません。 Tomcatの内部と対話するカスタムコンポーネントの開発者は、関連するAPIのJavaDocを確認する必要があります。
特に注意すべきは：
コンテキストが使用される唯一の場所であるため、Manager、Loader、およびResourcesはコンテナからコンテキストに移動しました。
マッパーは特定のサービスのすべてのコネクタで同一であるため、マッパーはコネクタからサービスに移動しました。
先ほど言ったように、エイリアス、VirtualLoader、VirtualDirContext、JARリソース、外部リポジトリを、機能ごとに個別のフレームワークではなく、単一のフレームワークにマージする新しいリソース実装があります。
Tomcat 8の変更に関する詳細情報を提供するリンクを以下に示します
http://people.Apache.org/~markt/presentations/2013-09-Apache-Tomcat8.pdf
アップグレードのタイミングを自分で理解する方法は次のとおりです。これは、Tomcatの任意のバージョンで使用できます。現在または将来、Tomcat 7からTomcat 8へのアップグレードだけではありません。
ほとんどのTomcatの変更メジャーバージョンが変更された場合は、特定のバージョンが構築されるサーブレット、JSP、およびJDKの仕様。アプリケーションの新しい仕様が不要で、使用しているバージョンが「アーカイブ」されていない場合（この記事の執筆時点では、Tomcat 7はアーカイブされていません）、おそらくアップグレードする必要はありません。 http://Tomcat.Apache.org/whichversion.html は、選択方法を説明しています。
実際の状況では、選択は他の要因にも影響される可能性があります。たとえば、必要なバージョンが本番ディストリビューションのパッケージマネージャーによってサポートされているかどうかなどです。 または逆に、ディストリビューションに特定のバージョンのTomcatしか含まれていない場合、大幅な時間の節約になるためアップグレードできます。
新しい機能は、新しいバグの可能性も意味することに注意してください。新しいTomcatバージョンの仕様を使用していない場合、何かが壊れる可能性がありますか？バージョンのパフォーマンスが向上する可能性があるからといって、独自のデプロイメント環境でクラッシュしないというわけではありません。ここでの最良の答えは、余裕があれば、新しいバージョンが機能しない場合に備えて、両方のバージョンをロードバランサーの背後に展開することです。
とはいえ、ソフトウェアには常に改善があります。選択したメジャーバージョンのさまざまなバージョンのリリースノートを読んで、ご自分の状況に最適なバージョンを選択することをお勧めします。 https://Tomcat.Apache.org/Tomcat-8.0-doc/RELEASE-NOTES.txt は、たとえば8.0リリースを対象としています。
メジャーバージョンを選択したら、バグは時間の経過とともに修正されるため、通常は最新バージョンを使用します。
以下のTomcat 8の新しい主要機能を参照してください。これは、必要な場合に移行するかどうかを決定するのに役立ちます。
Tomcat 8.0リリースは、Java EE 7仕様に準拠しています。以下をサポートしています。
- Java Servlet 3.1をサポート
- Java Server Pages（JSP）2.3
- Java Unified Expression Language（EL）3.0
- Java WebSocket 1.0
Tomcat 8は、Apache Portable Runtimeを使用して、優れたスケーラビリティ、パフォーマンス、およびネイティブサーバーテクノロジーとのより良い統合を提供できます。
サーバーコネクタに関しては、デフォルトのHTTPおよびAJPコネクタ実装は、JavaブロッキングIO実装（BIO）からJavaノンブロッキングIO実装（NIO）
また、Tomcat 8を実行するにはJava 7以降が必要です。プロジェクトで少なくともJava 7を使用している場合のみ移行してください。