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



13 12 (5)

Je voulais juste attirer l’attention de tous ceux qui pourraient être confrontés au problème du ballonnement après la mise à niveau. Le microcontrôleur JBoss-6 tente d'analyser les annotations spécifiques à Jboss en chargeant les classes de tous les JAR du chemin de classe au démarrage. Cela provoque le gonflement PermGen comme il commence à charger toutes les classes indésirables. Pour réduire la quantité de numérisation, le microcontrôleur fournit un autre descripteur au moyen de jboss-scanning.xml. Ajoutez ce 'jboss-scanning.xml' au WEB-INF dans 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>

Veuillez supposer que je n'ai pas besoin de m'inquiéter du temps et des coûts de développement: je m'intéresse aux avantages techniques généraux (amélioration des performances? API améliorées?) Et aux nouvelles fonctionnalités.

Je travaille actuellement sur des produits utilisant la version 4.2.x, et nous considérons un changement majeur pour les versions à venir et devant converger.

J'ai jeté un coup d'œil aux notes de publication de chaque version et à certains articles sur chaque version pour les versions 5.x, 6.x, 7.x et 8.x. Mais je serais ravi d'avoir des commentaires de première main de personnes qui ont fait le changement.

J'ai remarqué qu'il y avait des changements importants concernant la messagerie (passage de JBoss MQ à JBoss Messenging), et que JBoss 7.x semble changer un peu sa couche de configuration. Il se passe alors beaucoup plus de choses lors du passage à JBoss / WildFly 8.x.

S'il vous plaît, recommandez de bons articles indiquant les pièges si vous le pouvez. J'en ai trouvé quelques-unes pour les migrations vers JBoss 5.x, mais pas beaucoup pour les versions 6.x ou même 7.x, et quelqu'un d'autre évalue 8.x pour nous maintenant. N'hésitez pas à recommander des alternatives également si vous pensez qu'elles sont pertinentes, même si je préfère me concentrer uniquement sur JBoss.

Pour information, nous utilisons un mélange de systèmes basés sur des plug-ins compatibles JPF et OSGi (utilisant Eclipse Equinox), avec des clients développés dans Swing (certains étant déployés via WebStart).

Mise à jour: Bien que cette question ait déjà apporté d'excellentes réponses, je pense qu'elle mérite une mise à jour pour WildFly (et en fait, nos projets internes ont retardé le passage de 4.2.x à 7.x comme prévu initialement pour attendre WildFly). De nouvelles pensées et réponses sont les bienvenues.



Je ne peux parler que de l’expérience de 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é des fonctionnalités API est mieux documentée dans ces spécifications. JBoss 6 aura probablement une durée de vie très courte; Il n'est certifié que pour le profil Web Java EE 6 et les corrections de bogues sont ciblées pour la version 7 (dans sa 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 visons WildFly AS 8.1. En ce moment, nous ne pouvons pas migrer vers 8 car il n'y a pas de MQ Series JMS 2 RAR.

Quelques 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'y a plus de fichier XSL qui transforme server.xml. Vous pouvez donner un sens au fichier de configuration sans connaître les détails d'implémentation des classes. C'est difficile à apprécier si vous n'avez jamais configuré un JBoss 5.x.
  • Le modèle de chargement de la classe est sain et vous obtenez beaucoup de contrôle via jboss-deployment-structure.xml
  • La journalisation centralisée (Slf4j, JUL, JCL, Log4j, ...) est vraiment sympa.
  • La bibliothèque client EJB semble beaucoup plus nettoyée. Il ne reste que 10 JAR à partir de 20, dont la moitié sont même des bundles OSGi (notre client est une application Eclipse RCP).
  • Le mess des dépendances Maven du client EJB a disparu, au lieu de cela, vous obtenez maintenant un POM de nomenclature.
  • Vous obtenez un BOM POM pour les API du serveur.
  • Démarrage plus rapide et utilisation réduite de la mémoire. Nous déployons 80 EJB et la série MQ RAR en 6 secondes sans beaucoup de réglage. Notre jeu de données en direct est quelque part au-dessus de 200 Mo.
  • Le dossier de déploiements est vide par défaut
  • Le manque de qualité de XNIO fait peur. Dans la version 7.x, il est uniquement utilisé pour la communication à distance avec EJB et nous avons rencontré plusieurs bogues de type show stopper (blocages, double libre, fuites de handle de socket, ...). Dans 8.x, il est également utilisé pour les servlets au lieu de Tomcat. Il y a encore beaucoup de bugs de servlet très basiques corrigés dans le ressac.

Les changements que nous avons dû 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é vers l'API plate, certaines parties utilisent encore l'API Tree)
  • 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 reposant sur les détails de JNDI distant
  • la configuration du client EJB est différente
  • tous vos scripts pour l'installation, le déploiement, le démarrage, l'arrêt, ...
  • ExternalContext est parti, nous avons dû le remplacer par une approche différente
  • nous avons remplacé les MBeans dans les SAR par les EJB @StartUp
  • des hacks moche pour Cocoon

La série AS 7.x a beaucoup 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.


5 à 6 minutes n'est pas normal. J'utilise RAD et WAS tous les jours et j'obtiens des temps de démarrage décents. Quelle version de WAS utilisez-vous et combien de RAM avez-vous?

Si vous partagez plusieurs espaces de travail et projets pour un même profil WAS, envisagez de créer un nouveau profil WAS pour votre espace de travail.

Vous avez probablement essayé cela, mais voici une liste de vérification simple à essayer de première main. Assurez-vous que les paramètres de votre serveur dans RAD ont les options suivantes activées:

  • Optimiser le serveur pour le test et le développement
  • Exécuter le serveur avec des ressources sur l'espace de travail
  • Réduire les fichiers d'application copiés sur le serveur

Désélectionnez "Activer le client de test universel" si vous n'en avez pas besoin.

Dans la console d'administration, vous pouvez vérifier certains paramètres du serveur tels que

  • Exécuter en mode développement
  • Début parallèle
  • Commencer les composants au besoin

Vous pouvez également désinstaller l'application ivt installée par défaut lors de la création d'un nouveau profil WAS. Ensuite, les choses habituelles telles qu'un lecteur qui n'est pas trop fragmenté et une taille de fichier de page correctement définie.

Et une dernière chose que vous connaissez probablement déjà, republiez sur votre serveur au lieu de le redémarrer.





java java-ee jboss migration wildfly