AXOPEN

JBOSS 7 retours d’expérience

Deux versions dans le même serveurs

Jboss 7 version web repose sur deux versions distinctes:

  • Un version standalone
  • Une version HA (Haute Availability)La version Standalone est la version classique avec une seule instance de JBoss. C’est probablement la version la plus simple à utiliser, alors que la version HA est utilisée lors d’application nécessitant une forte montée en charge. (Plus complexe à configurer).
Partie StandaloneLa version standalone est configuré de la sorte. Toutes les configurations se retrouvent désormais dans le répertoire « configuration ». Plus de fichier -ds.xml ni mail-service.xml. Tout se retrouve maintenant dans le fichier standalone.xml.
La configuration se retrouve donc plus facile. Revers de la médaille, une erreur dns ce fichier et le serveur ne demarre plus. De même, il ne semble ps possible de faire recharger se fichier a chaud.

Déploiement et re-déploiement

Le mecanisme est different. Il suffit pour déployer son war/ear/jar de créer un fichier du même nom postfixé par .dodeploy.

Presque instantanément le serveur déploie l’application. Et cas d’erreur, un fichier .failed est créé. Pour relancer un déploiement créer un fichier .redeploy .

Ce mécanisme s’avère particulièrement efficace en production car facilement scriptable.

Performance

Là, il faut tirer un chapeau au équipes jboss car le serveur demarre presque instantanément. Le temps de démarrage d’une application reste par contre presque inchangé.

En cas de montée en charge, effectuée avec jMeter, le serveur reste très stable aussi bien en mémoire que en CPU.

Retours d’expériences

 

Problème de chargement de classe

Lors du développement (avec ECLIPSE), le serveur perd des classes, ou des fichiers de properties. Solution:

Arrêter le serveur et supprimer les fichiers /tmp/* et supprimer le war/ear/jar incriminé. Redémarrer le serveur à vide, puis redéployer votre application/

Pensez à redémarrer le serveur

De même, lors d’une grande journée de développement, le serveur à tendance à mal supporter un nombre conséquent de redéploiement d’application. Pensez à redémarrer le serveur est souvent une bonne idée.

Migration d’application

En fonction du niveau de maturité du projet,  il est plus ou moins simple de migrer une application. Si vous avez respecté les standards J2E, la migration se passe plutôt bien. (Hormis hibernate qui nécessite des modifications pour passer en version 4).

Authentification

Pour l’authentification JAAS, tout se situe dans le fichier de configuration mais ceci nécessitera un autre post plus tard dans la semaine. Ceci demande pas mal de modification si vous avez utilisé les classes WebAuthentication de jBoss qui n’existe plus.

Base de données

La configuration des datasources sous jBoss 7 n’est guère plus complexe que sous les anciennes versions de jBoss. Un article expliquera comment le faire.

Conclusion

Pour conclure rapidement sur le serveur jBoss 7. Les premières semaines d’exploitation sont plutôt très positifs. On peut le recommander sans problème pour des applications critiques. Plusieurs posts suivront pour expliquer plus en détails des  points précis.