title: EAR (format de fichier)
text: # EAR (format de fichier)
  
  Un EAR (pour Enterprise Application ARchive) est un format de fichier utilisé par Java EE pour empaqueter (en) un ou plusieurs modules dans une seule archive, de façon à pouvoir déployer ces modules sur un serveur d'applications en une seule opération, et de façon cohérente.
  
  Dans ces archives, le répertoire META-INF contient les fichiers descripteurs de déploiement (en) au format XML, qui indiquent comment les modules doivent être déployés sur le serveur.
  
  ## Structure du fichier
  
  Un fichier EAR est un JAR standard, dont l'extension a été changée en .ear. Il contient un ou plusieurs répertoires contenant les modules de l'application, ainsi qu'un répertoire META-INF contenant les méta données, c'est-à-dire les fichiers descripteurs de déploiement.
  
  ## Les modules
  
  Différents éléments peuvent être contenus dans un fichier EAR, pour être déployés sur le serveur :
  
  * Une archive d'application web, avec une extension .war. C'est un élément consistant en un ou plusieurs composants de l'application web (répertoires et fichiers), et son descripteur de déploiement spécifique (contenu dans un répertoire WEB-INF).
  * Des classes Java, groupées dans des archives .jar.
  * Un module Enterprise JavaBean dans une archive .jar, qui contient dans son propre répertoire META-INF son descripteur de déploiement spécifique. Une fois déployés, ces beans sont visibles aux autres composants.
  * Éventuellement, un Resource Adapter (connecteur) dans un fichier .rar.
  
  ### Isolement des classes
  
  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.
  
  ### Le répertoire META-INF
  
  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.
  
  