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.