Dois-je passer à Tomcat8 à partir de Tomcat 7
Mon projet fonctionne actuellement sur Tomcat 7. Dois-je opter pour une mise à niveau vers Tomcat 8? Quels sont les avantages et les inconvénients de faire cela? Tomcat 8 est-il meilleur en termes de performances, d'utilisation de la mémoire?
Étant donné que votre projet fonctionne déjà sur Tomcat 7, je recommanderais de maintenir le statu quo pendant encore un certain temps. Peu de données sont disponibles concernant l'amélioration des performances de Tomcat 8. Certains problèmes sont signalés sur Internet, ce qui est courant pour toute nouvelle version d'un produit.
Tomcat 8 offre de meilleures performances dans des environnements simultanés.
D'après mon expérience avec les produits Tomcat, la mise à niveau n'entraînerait probablement pas de performances significatives, sauf si vous avez une application très gourmande en ressources. Veuillez lire le lien ci-dessous avant la mise à niveau
Changements importants
Java 1.7 ==> La première modification importante est que Tomcat 8 nécessite maintenant Java 7 ou une version ultérieure pour fonctionner. Par conséquent, si vous migrez d'une version antérieure de Tomcat, vous devez mettre à niveau vers 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()
Connecteurs de serveur
En termes de connecteurs de serveur, l'implémentation par défaut des connecteurs HTTP et AJP est passée de l'implémentation Java bloquante IO (BIO) à l'implémentation Java non bloquante IO ( NIO). L'ancien BIO peut toujours être utilisé, mais les fonctionnalités de Servlet 3.1 et WebSocket 1.0 qui utilisent le blocage IO se replieront alors sur le blocage IO à la place, ce qui peut entraîner un comportement d'application inattendu.
Ressources d'application Web
L'élément Resources qui fait partie de la configuration et représente toutes les ressources disponibles pour l'application Web a été révisé. Désormais, il inclut des classes, des fichiers JAR, du HTML, des JSP et tout autre fichier contribuant à l'application Web. Des implémentations sont fournies pour utiliser des répertoires, des fichiers JAR et des fichiers WAR comme source de ces ressources et l'implémentation des ressources peut être étendue pour fournir une prise en charge des fichiers stockés sous d'autres formes telles que dans une base de données ou un référentiel versionné.
Débogage à distance
Lors du démarrage de Tomcat 8 avec l'option jpda pour activer le débogage à distance, Tomcat 8 écoute par défaut sur localhost: 8000. Les versions antérieures écoutaient *: 8000. Si nécessaire, cette valeur par défaut peut être remplacée en définissant la variable d'environnement JPDA_ADDRESS dans, par exemple, setenv. [Bat | sh].
Modifications de l'API
Bien que l'API interne de Tomcat 8 soit largement compatible avec Tomcat 7, de nombreux changements ont été apportés au niveau des détails et ils ne sont pas compatibles binaires. Les développeurs de composants personnalisés qui interagissent avec les composants internes de Tomcat doivent examiner le JavaDoc pour l'API appropriée.
À noter en particulier:
Le gestionnaire, le chargeur et les ressources sont passés du conteneur au contexte, car le contexte est le seul endroit où ils sont utilisés.
Le mappeur est passé du connecteur au service car le mappeur est identique pour tous les connecteurs d'un service donné.
Il y a une nouvelle implémentation de ressources, comme nous l'avons dit, qui fusionne les alias, VirtualLoader, VirtualDirContext, les ressources JAR et les référentiels externes dans un cadre unique plutôt que distinct pour chaque fonctionnalité.
Quelques liens qui fournissent plus d'informations sur les changements dans Tomcat 8 sont donnés ci-dessous
http://people.Apache.org/~markt/presentations/2013-09-Apache-Tomcat8.pdf
Voici comment comprendre vous-même le moment de la mise à niveau. Vous pouvez l'utiliser avec n'importe quelle version de Tomcat, maintenant ou dans le futur, cela ne couvre pas seulement la mise à niveau de Tomcat 7 vers Tomcat 8.
La plupart des modifications apportées à Tomcat lorsqu'une version majeure est modifiée sont des mises à niveau du spécifications de servlet, JSP et JDK sur lesquelles une version particulière est construite. Si vous n'avez pas besoin des spécifications les plus récentes pour votre application et que la version que vous utilisez n'est pas "archivée" (Tomcat 7 n'est pas archivé au moment de la rédaction de cet article), vous n'avez probablement pas besoin de mettre à niveau. http://Tomcat.Apache.org/whichversion.html explique comment faire une sélection.
Dans des situations réelles, votre choix peut également être influencé par d'autres facteurs, tels que la prise en charge de la version souhaitée par le gestionnaire de paquets dans votre distribution de production. Ou inversement , si votre distribution ne dispose que d'une version spécifique de Tomcat, vous pouvez effectuer une mise à niveau car elle fait gagner un temps considérable.
N'oubliez pas que les nouvelles fonctionnalités signifient également le potentiel de nouveaux bugs. Si vous n'utilisez pas les spécifications d'une nouvelle version de Tomcat, voulez-vous prendre le risque de quelque chose de cassé? Ce n'est pas parce qu'une version a le potentiel de performances supérieures qu'elle ne se bloquera pas dans votre environnement de déploiement unique. La meilleure réponse ici, si vous pouvez vous le permettre, est de déployer les deux versions derrière un équilibreur de charge au cas où la nouvelle ne fonctionnerait pas.
Cela dit, il y a toujours des améliorations dans les logiciels. Je suggère de lire les notes de publication pour les versions de différentes versions de la version principale que vous sélectionnez pour choisir la meilleure pour vos propres circonstances. https://Tomcat.Apache.org/Tomcat-8.0-doc/RELEASE-NOTES.txt couvre la version 8.0, par exemple.
Une fois que vous avez choisi une version majeure, vous souhaitez généralement utiliser la dernière version, car les bogues seront corrigés au fil du temps.
Voir ci-dessous les nouvelles fonctionnalités principales de Tomcat 8. Cela vous aidera à décider de migrer si vous en avez besoin.
La version Tomcat 8.0 est conforme à la spécification Java EE 7. Elle prend en charge:
- Il prend en charge Java Servlet 3.1
- Pages du serveur Java (JSP) 2.3
- Java Unified Expression Language (EL) 3.0
- Java WebSocket 1.0
Tomcat 8 peut utiliser Apache Portable Runtime pour fournir une évolutivité, des performances et une meilleure intégration supérieures avec les technologies de serveur natives.
En termes de connecteurs de serveur, l'implémentation des connecteurs HTTP et AJP par défaut est passée de Java blocking IO implementation (BIO) à Java non bloquant IO (NIO)
Veuillez également noter que Tomcat 8 nécessite Java 7 ou version ultérieure pour fonctionner, donc ne migrez que si vous utilisez au moins Java 7 dans votre projet).