¿Cuál es el propósito de META-INF?

En Java, a menudo se ve una carpeta META-INF que contiene algunos metaarchivos. ¿Cuál es el propósito de esta carpeta y qué puedo poner allí?

En general, no debe poner nada en META-INF usted mismo. En cambio, debe confiar en lo que use para empacar su JAR. Esta es una de las áreas en las que creo que Ant realmente sobresale: especificar los atributos de manifiesto del archivo JAR. Es muy fácil decir algo como:

     

Al menos, creo que es fácil … 🙂

El punto es que META-INF debe considerarse un directorio meta interno de Java. ¡No te metas con eso! Todos los archivos que desee incluir en su JAR deben colocarse en algún otro subdirectorio o en la raíz del JAR.

De la especificación oficial del archivo JAR (el enlace va a la versión de Java 7, pero el texto no ha cambiado desde al menos v1.3):

El directorio META-INF

Los siguientes archivos / directorios en el directorio META-INF son reconocidos e interpretados por la plataforma Java 2 para configurar aplicaciones, extensiones, cargadores de clases y servicios:

  • MANIFEST.MF

El archivo de manifiesto que se utiliza para definir la extensión y los datos relacionados con el paquete.

  • INDEX.LIST

Este archivo se genera con la nueva opción ” -i ” de la herramienta jar, que contiene información de ubicación para paquetes definidos en una aplicación o extensión. Es parte de la implementación de JarIndex y es utilizada por los cargadores de clases para acelerar el proceso de carga de clases.

  • x.SF

El archivo de firma para el archivo JAR. ‘x’ representa el nombre del archivo base.

  • x.DSA

El archivo de bloque de firma asociado con el archivo de firma con el mismo nombre de archivo base. Este archivo almacena la firma digital del archivo de firma correspondiente.

  • services/

Este directorio almacena todos los archivos de configuración del proveedor de servicios.

Me he dado cuenta de que algunas bibliotecas de Java han comenzado a utilizar META-INF como un directorio en el que se incluyen los archivos de configuración que deben estar empaquetados e incluidos en CLASSPATH junto con los JAR. Por ejemplo, Spring le permite importar archivos XML que están en el classpath usando:

   

En este ejemplo, estoy citando directamente de la Guía del usuario de Apache CXF . En un proyecto en el que trabajé, en el que tuvimos que permitir múltiples niveles de configuración a través de Spring, seguimos esta convención y pusimos nuestros archivos de configuración en META-INF.

Cuando reflexiono sobre esta decisión, no sé exactamente cuál sería el error al simplemente incluir los archivos de configuración en un paquete específico de Java, en lugar de en META-INF. Pero parece ser un estándar de facto emergente; ya sea eso, o un anti-patrón emergente 🙂

También puede colocar recursos estáticos allí.

Por ejemplo:

 META-INF/resources/button.jpg 

y obtenerlos en web3.0-contenedor a través de

 http://localhost/myapp/button.jpg 

> Leer más

El /META-INF/MANIFEST.MF tiene un significado especial:

  1. Si ejecuta un jar usando java -jar myjar.jar org.myserver.MyMainClass , puede mover la definición de clase principal al jarrón para poder reducir la llamada a java -jar myjar.jar .
  2. Puede definir Metainformaciones en paquetes si usa java.lang.Package.getPackage("org.myserver").getImplementationTitle() .
  3. Puede hacer referencia a los certificados digitales que le gusta usar en el modo Applet / Webstart.

La carpeta META-INF es el inicio del archivo MANIFEST.MF . Este archivo contiene metadatos sobre el contenido del JAR. Por ejemplo, hay una entrada llamada Main-Class que especifica el nombre de la clase Java con static main () para archivos JAR ejecutables.

Para agregar aquí la información, en el caso de un archivo WAR, el archivo META-INF / MANIFEST.MF proporciona al desarrollador la posibilidad de iniciar una verificación de tiempo de implementación por parte del contenedor, lo que garantiza que el contenedor pueda encontrar todas las clases de su aplicación depende de. Esto garantiza que, en caso de que haya omitido un JAR, no tenga que esperar hasta que su aplicación explote en tiempo de ejecución para darse cuenta de que falta.

He estado pensando en este tema recientemente. Realmente no parece haber ninguna restricción en el uso de META-INF. Hay ciertas restricciones, por supuesto, sobre la necesidad de poner el manifiesto allí, pero no parece haber ninguna prohibición de poner allí otras cosas.

¿Por qué es este el caso?

El caso cxf puede ser legítimo. Aquí hay otro lugar donde se recomienda esta norma no estándar para evitar un error desagradable en JBoss-ws que impide la validación del lado del servidor frente al esquema de un wsdl.

http://community.jboss.org/message/570377#570377

Pero realmente no parece haber ningún estándar, cualquiera que quieras. Usualmente estas cosas están definidas muy rigurosamente, pero por alguna razón, parece que no hay estándares aquí. Impar. Parece que META-INF se ha convertido en un lugar de paso para cualquier configuración necesaria que no pueda manejarse fácilmente de otra manera.

Si está utilizando JPA1, es posible que tenga que soltar un archivo persistence.xml que especifique el nombre de una unidad de persistencia que desee utilizar. Una unidad de persistencia proporciona una forma conveniente de especificar un conjunto de archivos de metadatos, y clases, y jar que contienen todas las clases para persistir en una agrupación.

 import javax.persistence.EntityManagerFactory; import javax.persistence.Persistence; // ... EntityManagerFactory emf = Persistence.createEntityManagerFactory(persistenceUnitName); 

Ver más aquí: http://www.datanucleus.org/products/datanucleus/jpa/emf.html

META-INF en Maven

En Maven se entiende la carpeta META-INF debido a la distribución de directorio estándar que por convención de nombre empaqueta sus recursos de proyecto dentro de JAR: cualquier directorio o archivo colocado dentro del directorio $ {basedir} / src / main / resources se empaqueta en su JAR con la misma estructura exacta comenzando en la base del JAR. La carpeta $ {basedir} / src / main / resources / META-INF generalmente contiene archivos .properties mientras que en el contenedor contiene MANIFEST.MF generado, pom.properties , pom.xml , entre otros archivos. También marcos como Spring usan classpath:/META-INF/resources/ para servir recursos web. Para obtener más información, consulte ¿Cómo agrego recursos a mi proyecto Maven?

Agregando a la información aquí, el META-INF es una carpeta especial que el ClassLoader trata de manera diferente de otras carpetas en el jar. Los elementos nesteds dentro de la carpeta META-INF no se mezclan con los elementos externos.

Piense en ello como otra raíz. Desde el punto de vista del método Enumerator ClassLoader#getSystemResources(String path) et al:

Cuando la ruta determinada comienza con “META-INF”, el método busca recursos que están nesteds dentro de las carpetas META-INF de todos los archivos jar de la ruta de la clase.

Cuando la ruta determinada no comienza con “META-INF”, el método busca recursos en todas las demás carpetas (fuera de META-INF) de todos los archivos jar y directorios en la ruta de la clase.

Si conoce otro nombre de carpeta que el método getSystemResources trata especialmente, por favor getSystemResources .

Todas las respuestas son correctas. Meta-inf tiene muchos propósitos. Además, aquí hay un ejemplo sobre el uso de contenedor Tomcat.

Vaya a Tomcat Doc y marque el atributo ” Implementación estándar> copyXML “.

La descripción está abajo.

Establézcalo en verdadero si desea que un descriptor XML de contexto incrustado dentro de la aplicación (ubicado en /META-INF/context.xml) se copie al xmlBase del Host propietario cuando se implementa la aplicación. En los inicios siguientes, el descriptor XML de contexto copiado se utilizará con preferencia a cualquier descriptor XML de contexto incrustado dentro de la aplicación, incluso si el descriptor incrustado dentro de la aplicación es más reciente. El valor de la bandera es por defecto falso. Tenga en cuenta si el atributo deployXML del host propietario es falso o si el atributo copyXML del host propietario es verdadero, este atributo no tendrá efecto.

Tienes el archivo MANIFEST.MF dentro de tu carpeta META-INF. Puede definir dependencias opcionales o externas a las que debe tener acceso.

Ejemplo:

Considere que ha implementado su aplicación y su contenedor (en tiempo de ejecución) descubrió que su aplicación requiere una versión más nueva de una biblioteca que no está dentro de la carpeta lib, en ese caso si ha definido la versión más nueva opcional en MANIFEST.MF entonces su la aplicación se referirá a la dependencia desde allí (y no se bloqueará).

Source: Head First Jsp & Servlet