EAR ( Enterprise Application Archive ) es un formato de archivo utilizado por Jakarta EE para empaquetar uno o más módulos en un único archivo , de modo que la implementación de los distintos módulos en un servidor de aplicaciones se realice de manera simultánea y coherente. También contiene archivos XML denominados descriptores de implementación , que describen cómo implementar los módulos.
Se pueden utilizar Ant , Maven o Gradle para crear archivos EAR.
Un archivo EAR es un archivo JAR estándar (y por lo tanto un archivo Zip ) con una extensión .ear, con una o más entradas que representan los módulos de la aplicación y un directorio de metadatos llamado META-INFque contiene uno o más descriptores de implementación.
META-INFdirectorio con descriptores de implementación específicos del módulo JAR.WEB-INF/web.xml:El descriptor de implementación para el módulo web.classes/:Contiene clases Java compiladas.lib/:Contiene archivos JAR de la biblioteca utilizados por el módulo web.Los desarrolladores pueden incorporar varios artefactos dentro de un archivo EAR para su implementación por parte de servidores de aplicaciones:
META-INFdirectorio descriptores que describen las clases persistentes implementadas. Los beans de entidad implementados se vuelven visibles para otros componentes y, si se exportan de forma remota, para los clientes remotos. Los beans de mensaje y los beans de sesión están disponibles para el acceso remoto.La mayoría de los servidores de aplicaciones cargan clases desde un archivo EAR implementado como un árbol aislado de cargadores de clases Java , aislando la aplicación de otras aplicaciones, pero compartiendo clases entre módulos implementados. Por ejemplo, un archivo WAR implementado podría crear instancias de clases definidas en un archivo JAR que también se incluyó en el archivo EAR que lo contiene, pero no necesariamente las de los archivos JAR en otros archivos EAR. Una razón clave para este comportamiento es permitir una separación completa entre aplicaciones que usan singletons estáticos (por ejemplo, Log4J), que de lo contrario confundirían la configuración entre aplicaciones separadas. Esto también permite que se implementen diferentes versiones de aplicaciones y bibliotecas en paralelo.
Los servidores de aplicaciones JBoss anteriores a la versión 5 se caracterizaban por no aislar los componentes implementados. Una aplicación web implementada en un archivo EAR tendría acceso a clases en otros archivos EAR y WAR. Esta es una política un tanto controvertida. El diseño del cargador de clases unificado reduce la sobrecarga de comunicaciones entre aplicaciones en ejecución, ya que los datos de clase se pueden compartir por referencia o copias simples. También permite a los desarrolladores evitar tener que comprender los problemas que puede crear un árbol de cargadores de clases. Sin embargo, evita que se implementen diferentes versiones de bibliotecas dependientes en aplicaciones separadas. JBoss 4.0.2 cambió a un cargador de clases jerárquico, pero en la versión 4.0.3 volvió a un cargador de clases unificado por razones de compatibilidad con versiones anteriores. Ahora hay una opción de configuración para cambiar este comportamiento. JBoss 5.x, 6.x y 7.x ya no utilizan la carga de clases unificada.
El META-INFdirectorio contiene al menos el application.xmldescriptor de implementación, conocido como Descriptor de implementación de Java EE . Contiene las siguientes entidades XML:
icon, que especifica las ubicaciones de las imágenes que representan la aplicación. Se realiza una subdivisión para small-icony large-icon.display-name, que identifica la aplicacióndescriptionmoduleelemento para cada módulo en el archivosecurity-roleelementos para los roles de seguridad globales en la aplicaciónCada moduleelemento contiene un elemento ejb, webo javaque describe los módulos individuales dentro de la aplicación. Los módulos web también proporcionan un context-rootque identifica el módulo web por su URL.
Además del descriptor de implementación de Jakarta EE, puede haber cero o más descriptores de implementación en tiempo de ejecución . Estos se utilizan para configurar parámetros de Jakarta EE específicos de la implementación.