Avantages (et conseils) d'une mise à niveau de JBoss 4.2.x vers JBoss 5.x, 6.x, 7.x et WildFly 8.x?
S'il vous plaît, supposez que je n'ai pas à m'inquiéter du temps et des coûts de développement: Je m'intéresse aux avantages techniques généraux (performances améliorées? API améliorées?) Et aux nouvelles fonctionnalités.
Je travaille actuellement sur des produits utilisant la version 4.2.x et nous envisageons un changement majeur pour les versions qui ont une longue perspective et qui doivent converger.
J'ai jeté un coup d'œil aux notes de publication de chaque version et à quelques articles sur chaque version pour 5.x, 6.x, 7.x et 8.x. Mais je serais heureux de recevoir des informations de première main des personnes qui ont effectué le changement.
J'ai remarqué des changements importants dans la messagerie (passage de JBoss MQ à JBoss Messenging) et que, pour JBoss 7.x, il semble modifier sensiblement sa couche de configuration. Il reste encore beaucoup à faire pour passer à JBoss/WildFly 8.x.
S'il vous plaît recommander de bons articles pointant aux pièges si vous le pouvez. J'en ai trouvé quelques-uns pour les migrations vers JBoss 5.x, mais pas autant pour 6.x ou même 7.x, et quelqu'un d'autre évalue actuellement 8.x pour nous. N'hésitez pas à recommander des alternatives si vous pensez qu'elles sont pertinentes, bien que je préfère me concentrer uniquement sur JBoss.
Pour information, nous utilisons une combinaison de systèmes à base de plug-in compatibles avec JPF et OSGi (avec Eclipse Equinox), avec des clients développés en Swing (certains déployés via WebStart).
Mise à jour: Bien que cette question apporte déjà d'excellentes réponses, je pense qu'elle mérite une mise à jour pour WildFly (et en fait, nos projets internes ont différé le passage de la version 4.2.x à la version 7.x initialement prévue pour attendre WildFly). . Les nouvelles idées et réponses sont les bienvenues.
Je suis passé de JBoss 4 à 5 et, d’expérience, voici les points les plus importants à noter:
- JBoss 5 (et 6 et 7) ne sont pas aussi tolérants que JBoss 4 avec des fichiers XML. Vous devez vous assurer que tous vos fichiers XML de descripteur de déploiement sont valides. Vous pouvez utiliser des DTD dans certains fichiers - je vous recommande de les mettre à niveau pour utiliser plutôt le schéma XML.
- Certaines bibliothèques peuvent provoquer des incompatibilités. Cela peut être particulièrement vrai si vous accédez à des services Web et/ou effectuez une analyse XML
- Si vous pré-compilez vos JSP dans JBoss 4, vous ne pourrez probablement pas le faire dans JBoss 6/7.
- JBoss 4 et 5 utilisent différentes implémentations de file d'attente de messages. Si des files de messages ou des sujets sont définis, vous devrez les redéfinir.
- JBoss TreeCache n'est plus utilisé. Si vous l'utilisez à des fins de mise en cache, vous devrez utiliser plutôt le nouveau cache JBoss.
- La sécurité de JBoss 5 est différente. Si vos clients distants nécessitent un accès sécurisé à JBoss, vous devrez les configurer différemment.
Quelques ressources utiles sont:
http://Java.dzone.com/articles/migrating-jboss-4-jboss-5http://venugopaal.wordpress.com/2009/02/02/jboss405- to-jboss-5ga
Officiellement, JBoss 6 n'est certifié que pour le profil Web Java EE. Par conséquent, si vous utilisez des fonctionnalités "héritées" telles que EJB 2.x, elles ne seront potentiellement plus prises en charge à l'avenir. En fonction du cycle de vie de votre application, cela peut être un problème ou non. JBoss 6 prend actuellement totalement en charge EJB2.1, mais il n’est pas certifié.
J'ai également constaté que JBoss 5 gère la mémoire beaucoup mieux que JBoss 4. Avec JBoss 4, je vois beaucoup plus d'erreurs PermGen que je ne le fais avec JBoss 5.
Je ne peux parler que de l'expérience de la production avec JBoss 5.1.0 et de quelques recherches sur la version 6.
JBoss 5 est Java EE 5 et JBoss 6 et 7 sont Java EE 6 . La disparité dans les fonctionnalités de l'API est mieux documentée dans ces spécifications. JBoss 6 aura probablement une durée de vie très courte; il est certifié uniquement pour le profil Web Java EE 6 et les corrections de bogues sont ciblées sur la version 7 (actuellement en 3ème version bêta au moment de la rédaction).
Je pense que vous obtiendrez de meilleures réponses sur le forum de la communauté JBoss.
Nous sommes passés de JBoss AS 5 à JBoss AS 7 et nous envisageons WildFly AS 8.1. Pour le moment, nous ne pouvons pas migrer vers 8, car il n’existe pas de MRS Series JMS 2 RAR.
Certaines des différences:
- La configuration est tellement meilleure et plus simple. Il n'est plus réparti sur 20 fichiers XML dans lesquels vous configurez des aspects dans des fichiers XML. Au lieu de cela, tout est un lieu central. Tous les ports sont configurés dans un emplacement central. Il n'existe plus de fichier XSL qui transforme le fichier server.xml. Vous pouvez donner un sens au fichier de configuration sans connaître les détails d'implémentation des classes. Il est difficile d’apprécier cela si vous n’avez jamais configuré JBoss 5.x.
- Le modèle de chargement de classe a l'air sain et vous obtenez beaucoup de contrôle via jboss-deployment-structure.xml
- La journalisation centralisée (Slf4j, JUL, JCL, Log4j,…) est vraiment agréable.
- La bibliothèque client EJB semble beaucoup plus propre. Il ne reste plus que 10 JAR sur 20, dont la moitié sont même des bundles OSGi (notre client est une application Eclipse RCP).
- Le désordre de dépendance maven du client EJB a disparu. Vous obtenez maintenant un POM de nomenclature.
- Vous obtenez un POM de nomenclature pour les API de serveur.
- Un démarrage plus rapide et une utilisation réduite de la mémoire. Nous déployons 80 EJB et le RAR MQ Series en 6 secondes sans trop de réglages. Notre ensemble de données en direct est quelque part au-dessus de 200 Mo.
- Le dossier de déploiement est vide par défaut
- La (manque de) qualité de XNIO est effrayante. Dans la version 7.x, il est uniquement utilisé pour la communication à distance avec les EJB et nous avons rencontré plusieurs bugs d'exposition (blocage, double libre, fuite de la poignée de connexion,…). Dans 8.x, il est également utilisé pour les servlets au lieu de Tomcat. Il y a encore beaucoup de bugs de base sur les servlets en cours de résolution.
Changements que nous devions faire notre application:
- changer les noms JNDI en noms normalisés EE 6
- migrer de JBoss Cache vers Infinispan (une partie de notre code a été migrée vers l'API plate, certaines parties utilisent encore l'API de l'arborescence)
- la sécurité est légèrement moins flexible (vous ne pouvez plus réparer les appels authentifiés et non authentifiés)
- un code horrible qui s'appuie sur les détails de JNDI distant
- la configuration du client EJB est différente
- tous vos scripts pour installer, déployer, démarrer, arrêter,…
- ExternalContext est parti, nous avons dû le remplacer par une approche différente
- nous avons remplacé les MBeans dans les SAR par des EJB @StartUp
- des trucs moches pour Cocoon
La série AS 7.x a un lot de bogues avec des correctifs uniquement disponibles dans la série EAP. Si vous voulez aller avec 7.x au lieu de 8.x, nous vous recommandons fortement d’acheter EAP 6.
Voici un fil de discussion intéressant sur les futurs et les compromis de JBoss AS 7, mentionnant également des problèmes avec AS 5 et AS 6:
Je voulais simplement attirer l'attention de quiconque sur ce problème qui pourrait être confronté à un problème de gonflement de PermGen après une mise à niveau au plus récent. JBoss-6 Microcontainer essaie de rechercher des annotations spécifiques à Jboss en chargeant les classes à partir de tous les JAR du chemin de classe au démarrage. Cela provoque un gonflement de PermGen car il commence à charger toutes les classes indésirables. Pour réduire la quantité d'analyse, le Microcontainer fournit un autre crochet de descripteur, au moyen de jboss-scanning.xml. Ajoutez ce 'jboss-scanning.xml' au fichier WEB-INF dans les fichiers WAR et ass 'jboss-scanning .xml 'au META-INF dans les EAR.
<scanning xmlns="urn:jboss:scanning:1.0">
<!-- Purpose: Disable scanning for annotations in contained deployment. -->
</scanning>