Avantages (et astuces) d'une mise à niveau de JBoss 4.2.x vers JBoss 5.x, 6.x, 7.x et WildFly 8.x?

Question

Veuillez supposer que je n'ai pas besoin de vous soucier des temps et coûts de développement: je suis intéressé en général des avantages techniques (amélioration de la performance? l'amélioration des Api?) et de nouvelles fonctionnalités.

Je suis actuellement en train de travailler sur des produits à l'aide de 4.2.x, et nous considérons qu'un changement majeur pour les versions longtemps à l'avance et doivent converger.

J'ai eu un bref regard sur les notes de version de chaque version et quelques articles sur chaque version 5.x, 6.x, 7.x et 8.x. Mais je serais heureux d'avoir les premières impressions des personnes qui ont fait le commutateur.

J'ai remarqué il y a quelques changements importants entourant de messagerie (commutation de JBoss MQ pour JBoss messaging, toujours), et que pour JBoss 7.x il semble changer un peu juste sa couche de configuration. Ensuite, il y a beaucoup plus de choses lors de la commutation de JBoss/WildFly 8.x.

S'il vous plaît recommander de bons articles pointant vers les pièges, si vous le pouvez. J'ai trouvé un peu pour les migrations de JBoss 5.x, mais pas beaucoup pour les 6.x ou même 7.x, et quelqu'un d'autre est de l'évaluation 8.x pour nous maintenant. Hésitez pas à recommander des solutions de rechange ainsi si vous pensez qu'ils sont pertinents, bien que je préfère se concentrer uniquement sur JBoss.

Pour plus d'informations, nous utilisons un mélange de JPF - et OSGi-activé (à l'aide d'Eclipse Equinox) à base de plugins systèmes, avec des clients développé en Swing (certains déployées par WebStart).

Mise à jour: Si cette question a apporté quelques réponses grands déjà, je pense qu'il mérite une mise à jour pour WildFly (et en fait, nos projets internes retardé la décision de passer de 4.2.x-7.x comme prévu à l'origine pour attendre WildFly). De nouvelles pensées et les réponses sont les bienvenues.

Answer 1

J'ai mis à niveau à partir de JBoss 4 à 5 et de l'expérience les plus importantes sont les suivantes sont à noter:

• JBoss 5 (et 6 et 7) ne sont pas aussi indulgent que JBoss 4 avec des fichiers XML. Vous devez vous assurer que tous vos descripteur de déploiement XML fichiers sont valides. Vous avez peut-être à l'aide de Dtd dans certains fichiers - je recommande la mise à niveau de celles-ci schéma XML à la place.
• Certaines bibliothèques peuvent provoquer des incompatibilités. Cela peut être particulièrement vrai si vous accédez à des services web et/ou d'analyse XML
• Si vous précompiler vos pages Jsp dans JBoss 4, vous ne serez probablement pas en mesure de dans JBoss 6/7.
• JBoss 4 et 5 utilisent différentes message de la file d'attente des implémentations. Si vous avez des files d'attente de messages ou sujets définis, vous aurez besoin de les redéfinir.
• JBoss TreeCache n'est plus utilisé. Si vous utilisez ce pour la mise en cache, vous aurez besoin de changer pour utiliser le nouveau JBoss cache à la place.
• JBoss 5 sécurité est différent. Si votre télécommande clients ont besoin d'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-5 http://venugopaal.wordpress.com/2009/02/02/jboss405-to-jboss-5ga

Officiellement JBoss 6 n'est certifié que pour le Java EE Web Profil, de sorte que si vous utilisez "l'héritage" des fonctionnalités telles que les EJB 2.x, ils seront susceptibles de ne pas être pris en charge dans l'avenir. Selon le cycle de vie de votre application, cela peut ou peut ne pas être un problème. JBoss 6 prend actuellement en charge EJB2.1 entièrement, mais il n'est pas agréé à cet égard.

J'ai aussi constaté que JBoss 5 poignées de mémoire beaucoup mieux que JBoss 4. Avec JBoss 4, je vois beaucoup plus PermGen les erreurs que je fais avec JBoss 5.

Answer 2

Je ne peux parler que de la production d'expérience avec JBoss 5.1.0 et une enquête de la version 6.

JBoss 5 est de Java EE 5 et JBoss 6 et 7 sont Java EE 6. La disparité dans les fonctionnalités de l'API est le mieux documenté dans les specs. JBoss 6 est susceptible d'avoir une très courte durée de vie; c'est seulement certifié pour le Java EE 6 web profil et corrections de bugs sont destinées à la version 7 (dans sa 3ème version bêta au moment de la rédaction).

Je pense que vous seriez obtenir de meilleures réponses sur le forum de la communauté JBoss.

Answer 3

Nous avons mis à niveau à partir de JBoss as 5 de JBoss as 7, le toisant vers WildFly QUE 8.1. Maintenant on ne peut pas migrer vers 8 car il n'est pas MQ Series JMS 2 RAR.

Certaines différences:

• La configuration est tellement mieux et plus simple. Il n'est plus de l'écart de plus de 20 fichiers XML dans lequel vous configurez aspects dans des fichiers XML. Au lieu de cela, tout est un endroit central. Tous les ports sont configurés dans un endroit central, il n'est plus un fichier XSL qui transforme server.xml. Vous pouvez faire sens de ce fichier de configuration, sans en connaître les détails de mise en œuvre de classes. Il est difficile de l'apprécier si vous n'avez jamais configuré de JBoss 5.x.
• Le chargement des classes du modèle est sain d'esprit et que vous avez beaucoup de contrôle par le biais de jboss-deployment-structure.xml
• La journalisation centralisée (Slf4j, JUL, JCL, Log4j, ...) est vraiment sympa.
• L'EJB de la bibliothèque du client ressemble beaucoup plus à nettoyer. Il est à 10 Pots de 20, la moitié d'entre eux sont même des bundles OSGi (notre client est une application Eclipse RCP).
• Les EJB client maven dependency mess est parti, au lieu de cela, vous obtenez maintenant une NOMENCLATURE POM.
• Vous obtenez une NOMENCLATURE POM pour le serveur d'Api.
• Plus rapide et moins d'utilisation de la mémoire. Nous déployer 80 Ejb et MQ Series RAR en 6 secondes sans trop de tuning. En direct de notre jeu de données est quelque part au-dessus de 200 MO.
• Les déploiements dossier est vide par défaut
• Le (manque de) la qualité de XNIO est effrayant. Dans 7.x il n'est utilisé que pour les EJB remoting et nous avons frappé à plusieurs bugs bloquants (les blocages, double gratuit, socket handle de fuites, ...). En 8.x il est utilisé pour les servlets ainsi au lieu de Tomcat. Il y a encore beaucoup de très de base de servlet bogues corrigés dans le ressac.

Les changements que nous avons eu à faire de notre application:

• changement des noms JNDI de EE 6 normalisé des noms
• migrer de JBoss Cache Infinispan (partie de notre code a été migré vers le plat de l'API, certaines parties utilisent encore l'arbre de l'API)
• la sécurité est un peu moins souple (vous pouvez ne plus fixer authentifié et les appels non authentifiés)
• une horrible code qui comptaient sur les détails de distance JNDI
• la configuration de l'EJB client est différent
• vous tous les scripts pour l'installation, le déploiement, le démarrage, l'arrêt, ...
• ExternalContext est parti, nous avons dû le remplacer avec une approche différente
• nous avons remplacé les MBeans dans Sras avec @Démarrage de l'Ejb
• moches, les hacks pour Cocoon

Le 7.la série x est un beaucoup de bugs avec les corrections uniquement disponible dans le PAE de la série. Si vous voulez aller avec 7.x au lieu de 8.x nous vous recommandons vivement de vous acheter EAP 6.

Answer 4

Voici un fil intéressant sur les compromis et l'avenir de JBoss AS 7, mentionnant également des problèmes avec AS 5 et AS 6:

http://community.jboss.org/message/613171

Answer 5

Voulais juste de porter cette question à l'attention de quelqu'un qui pourrait l'être en face de PermGen ballonnement de problème après la mise à niveau vers la dernière. JBoss-6 Microcontainer tente d'analyser pour Jboss des annotations spécifiques par le chargement des classes de tous les Pots dans le chemin de classe au démarrage. Cela provoque la PermGen ballonnements car il commence à charger toutes les autres classes. Afin de réduire le montant de la numérisation, le Microcontainer fournit un autre descripteur de crochet, par le biais de jboss-scanning.xml. Ajouter cette "jboss-scanning.xml" pour le WEB-INF à l'intérieur de Guerres et de cul "jboss-scanning.xml" pour le META-INF à l'intérieur des Oreilles.

<scanning xmlns="urn:jboss:scanning:1.0">

    <!-- Purpose: Disable scanning for annotations in contained deployment. -->

</scanning>