Jboss 7 version web repose sur deux versions distinctes:
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.
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.
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/
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.
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).
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.
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.
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.
Découvrez la planche #12 !
On vous a confié la responsabilité d'une application et vous vous demandez quelle est la meilleure manière de tester votre logiciel ? Vous vous dites qu'en 2025, tester une application devrait être plus facile qu'auparavant, qu'il doit exister des bonnes pratiques, et qu'elles sont sûrement appliquées dans toutes les entreprises… sauf la vôtre ? Il est donc temps de faire un point sur les bonnes pratiques de tests logiciels en 2025 !
Découvrez la planche #41 !