我应该从 Tomcat 7 升级到 Tomcat8
Posted
技术标签:
【中文标题】我应该从 Tomcat 7 升级到 Tomcat8【英文标题】:Should I upgrade to Tomcat8 from Tomcat 7 【发布时间】:2015-07-14 22:47:18 【问题描述】:我的项目目前在 Tomcat 7 上运行。我应该升级到 Tomcat 8 吗?这样做有什么好处和坏处?就性能、内存利用率而言,tomcat 8 是否更好?
【问题讨论】:
【参考方案1】:由于您的项目已经在 tomcat 7 上运行,我建议您再保持现状一段时间。没有太多关于 tomcat 8 性能改进的数据。互联网上报告了一些问题,这对于任何新版本的产品都很常见。
Tomcat 8 在并发环境中具有更好的性能。
根据我对 tomcat 产品的经验,升级很可能不会带来任何显着的性能,除非您有一个资源密集型应用程序。升级前请阅读以下链接
http://events.linuxfoundation.org/sites/events/files/slides/2014-04-09-Migrating-to-Apache-Tomcat-8.pdf
重要变化
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,这可能会导致意外的应用程序行为。
网络应用资源
Resources 元素是配置的一部分,代表 Web 应用程序可用的所有资源,该元素已被修改。现在它包括类、JAR 文件、html、JSP 和任何其他有助于 Web 应用程序的文件。提供实现以使用目录、JAR 文件和 WAR 作为这些资源的来源,并且可以扩展资源实现以支持以其他形式存储的文件,例如在数据库或版本化存储库中。
远程调试
当使用 jpda 选项启动 Tomcat 8 以启用远程调试时,Tomcat 8 默认侦听 localhost:8000。早期版本在 *:8000 上收听。如果需要,可以通过设置 JPDA_ADDRESS 环境变量来覆盖此默认值,例如 setenv.[bat|sh]。
API 的变化
虽然 Tomcat 8 内部 API 与 Tomcat 7 大体兼容,但在细节层面发生了许多变化,并且它们不是二进制兼容的。与 Tomcat 内部交互的自定义组件的开发人员应查看相关 API 的 JavaDoc。
需要特别注意的是:
Manager、Loader 和 Resources 已从 Container 移至 Context,因为 Context 是唯一使用它们的地方。
映射器已从连接器移动到服务,因为映射器对于给定服务的所有连接器都是相同的。
正如我们所说,有一个新的 Resources 实现,它将 Aliases、VirtualLoader、VirtualDirContext、JAR 资源和外部存储库合并到一个框架中,而不是为每个功能单独一个框架。
下面给出了一些链接,这些链接提供了有关 tomcat 8 更改的更多信息
http://people.apache.org/~markt/presentations/2013-09-Apache-Tomcat8.pdf
https://tomcat.apache.org/tomcat-8.0-doc/changelog.html
【讨论】:
【参考方案2】:以下是您自己了解何时升级的方法。您可以将它与任何版本的 Tomcat 一起使用,现在或将来,它不仅包括从 Tomcat 7 升级到 Tomcat 8。
大多数对 Tomcat 的更改主要版本更改时是对特定版本所基于的 servlet、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 本身还有开发工具中的更多错误,例如 Eclipse 中的“服务模块而不发布”功能不适用于 Tomcat 8。【参考方案3】:请参阅下面的 tomcat 8 的新主要功能。这将有助于决定是否需要迁移。
Tomcat 8.0 版本符合 Java EE 7 规范。它支持:
支持 Java Servlet 3.1 Java 服务器页面 (JSP) 2.3 Java 统一表达式语言 (EL) 3.0 Java WebSocket 1.0Tomcat 8 可以使用 Apache Portable Runtime 提供卓越的可扩展性、性能以及与本机服务器技术的更好集成。
在服务器连接器方面,默认的 HTTP 和 AJP 连接器实现已从 Java 阻塞 IO 实现 (BIO) 切换到 Java 非阻塞 IO 实现 (NIO)
另外请注意,Tomcat 8 需要 Java 7 或更高版本才能运行,因此只有在您的项目中至少使用 Java 7 时才迁移。
【讨论】:
以上是关于我应该从 Tomcat 7 升级到 Tomcat8的主要内容,如果未能解决你的问题,请参考以下文章