Le weblogue de SeB

Ce n’est pas nouveau, Geronimo est certifié Java EE 5 depuis la version 2.0. Et il y a un peu moins d’un mois, la version 2.1 est sortie.

Cette nouvelle version apporte son lot d’améliorations, corrections et de nouvelles fonctionnalités dont :

• Custom Server Assemblies : pour simplifier la construction d’un serveur sur-mesure
• Flexible Administration Console : une console d’administration du serveur
• GShell : un environnement d’exécution de ligne de commande supportant Groovy
• WADI Clustering : permet de monter aussi bien des clusters de Jetty ou Tomcat
• Monitoring support : accessible via la console d’administration, il permet de superviser l’état de l’ensemble des serveurs

Pour plus d’informations, vous pouvez consulter l’annonce officielle de publication de Geronimo 2.1.

Comme toujours, ce serveur d’applications open source est disponible en libre téléchargement sur la page du projet.

Sans revenir sur les détails du modèle de conception appelé singleton, ce dernier permet de n’avoir qu’une seule instance de classe. Parfois, dans un contexte d’application d’entreprise possédant plusieurs applications web, il est nécessaire d’avoir une seule instance de classe pour l’ensemble de ces applications. Or cela n’est pas toujours aussi trivial.

En effet, selon la stratégie de gestion des classloaders employée par les serveurs d’applications, les applications web au sein de la même application d’entreprise peuvent avoir un classloader différent^[1]. Dans ce cas, chaque application web aura sa propre instance de classe (géré par le singleton).

En général, un classloader est également défini pour l’application d’entreprise. Ainsi, si le singleton appartient à ce classloader, il pourra être partagé avec toutes les applications web. Afin d’obtenir ce résultat, il faut seulement modifier la façon de générer le fichier EAR.

Par exemple, si le singleton est défini dans une bibliothèque externe appelée util.jar. Au lieu de placer ce JAR dans le répertoire WEB-INF/lib de chaque application web, il faut placer ce fichier à la racine de l’EAR. Ensuite, pour chaque application web, il faut ajouter dans la variable Class-Path du fichier META-INF/MANIFEST.MF la référence à la bibliothèque externe^[2].

Voici un exemple plus concret de l’arborescence de l’EAR :

META-INF/application.xml
 util.jar
 mywebapp1.war
   META-INF/MANIFEST.MF:
     Manifest-Version: 1.0
     Class-Path: util.jar
   WEB-INF/web.xml
 mywebapp2.war
   META-INF/MANIFEST.MF:
     Manifest-Version: 1.0
     Class-Path: util.jar
   WEB-INF/web.xml

Cette solution est très fortement inspirée de l’article de Nicolas Martignole sur la gestion des ressources JARs dans un projet J2EE. Et pour une utilisation plus avancée, vous pouvez consulter l’article officiel : Packaging Utility Classes or Library JAR Files in a Portable J2EE Application.

Notez que cette solution permet en même temps de réduire la taille de l’EAR. Avec ces éléments, vous serez capable de mieux gérer vos ressources JAR dans vos applications livrées sous forme d’EAR.

Notes

[1] C’est le cas par exemple avec le serveur d’applications JOnAS.

[2] Cette référence correspond au chemin relatif à partir de la racine de l’EAR.

Comme souligné dans un précédent billet, intitulé Struts - JSF - Même combat??, beaucoup de personnes se demandent quel framework utiliser pour écrire leur application web : Struts ou JSF ? Avant de pouvoir répondre à cette question, il faut comprendre comment chacun se positionne par rapport à l’autre.

Lire le reste de cet article »

Il y a quelques temps, il a été proposé de rendre Struts 2.x compatible avec JSF.

La semaine dernière l’équipe de développement de Struts a publié une annonce sur son nouveau sous projet…

Lire le reste de cet article »

Voici une interview de Craig McClanahan par Janice J. Heiss sur l’évolution des applications Web au travers de Struts, JSF et Java Studio Creator.

Lire le reste de cet article »

Le Commons Validator utilisé dans Struts est un outil extrêment utile. Non seulement il permet de générer automatiquement les contrôles JavaScript côté client et les contrôles Java côté serveur, mais il permet surtout de factoriser (et réutiliser) ces contrôles.

J’ai écrit il y a quelque temps un nouveau type de contrôle que je publie ici librement sous la licence GPL.

Lire le reste de cet article »

Geronimo arrive…

Lire le reste de cet article »

Martin Fowler a écrit un article très intéressant sur le pattern IoC où il présente les 2 grandes tendances des conteneurs légers :

• Le localisateur de service (le standard J2EE)
• L’injection de dépendance (l’alternative OpenSource)

Arnaud Bely vient de publier la IoCFowler.pdf" hreflang="fr">traduction française.

Il est très difficile de dire quel est le meilleur framework Web en Java. Surtout que ce choix dépend énormément de l’environnement technique de l’application et des affinités des architectes et/ou des développeurs. Matt Raible nous présente sa vision sur 5 frameworks existants en prenant en compte l’aspect technique et stratégique :

• Struts
• Spring
• Tapestry
• WebWork
• JavaServer Faces^[1]

Cette présentation est également illustrée par une démonstration implémentée avec ces différents frameworks.

Il y a un fil de discussion sur TSS à propos de cette présentation où la communauté donne également son opinion sur les frameworks Web.

On peut retenir en résumé que :

• Trapesty et Spring sont de très bons frameworks, mais ils sont très peu supportés. Il est donc difficile de se lancer dans l’aventure.
• JSF est le standard J2EE. Et même s’il n’est pas encore arrivé à maturité; avec le support des grosses sociétés du monde J2EE et des éditeurs, il risque bien de rependre une place importante sur le marché des frameworks Web.
• Struts reste le framework de référence. Très utilisé, il éprouvé depuis un certain temps, même s’il faut fournir un travail plus important qu’avec ses concurrents.

Notes

[1] A voir aussi

Ecrire une application web avec un certain nombre de fonctionnalités représente une tâche assez complexe.

Cependant il existe des outils pour faciliter le développement d’applications web. MVC2 est un modèle de conception qui consiste à séparer le Modèle, de la Vue et du Contrôleur. Cela permet entre autre de rendre indépendantes la couche logicielle de présentation et la couche contenant le coeur du métier.

Struts est un framework qui permet d’implémenter un tel modèle de conception au sein d’applications web J2EE.

Lire le reste de cet article »