EAR (format de fichier)

La plupart des serveurs d'application chargent les classes d'un EAR par un arbre de classloaders isolant les exécutions des applications entre elles, mais permettant le partage des classes entre les modules à l'intérieur de l'application elle-même. Ainsi, un code présent dans un JAR pourra être utilisé par toutes les webapps de l'application, mais pas par celles déployées depuis un autre EAR. Une des raisons les plus importantes expliquant cet isolement est de permettre la séparation complète entre applications qui utilisent des singletons statiques (par exemple ceux présents dans Log4J, souvent inclus dans les applications). Cette séparation évite que des configurations statiques se mélangent. Une autre raison pratique est de permettre l'utilisation de différentes versions d'une même bibliothèque dans des applications déployées sur le même serveur.

Ce répertoire contient au moins le fichier de description de déploiement application.xml, qui indique la méthode d'installation des modules sur le serveur. Il contient les balises XML suivantes :

• icon, qui indique l'emplacement pour les logos de l'application. Une différenciation est faite entre small-icon et large-icon.
• display-name, qui indique le nom de l'application
• description, qui indique une description sommaire de l'application
• Une balise module pour chaque module contenu dans l'archive
• en option, plusieurs balises security-role définissant les rôles pour la sécurité générale de l'application

Chaque balise module contient une balise ejb, web ou java qui indique quel type de module est présent, et qui le décrit. Les modules pour les applications webs contiennent en plus la balise context-root qui spécifie l'URL permettant aux utilisateurs d'y accéder.

En plus de ce descripteur de déploiement peuvent se trouver un ou plusieurs descripteurs d'exécution spécifiant des paramètres additionnels à utiliser lors de l'exécution de la JVM.