que - meta-inf java

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

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

META-INF en Maven

En Maven, la carpeta META-INF se entiende debido al diseño de directorio estándar que por convención de nombre empaqueta los recursos de su proyecto dentro de los archivos JAR: todos los directorios o archivos ubicados dentro del directorio $ {basedir} / src / main / resources están empaquetados en su JAR con exactamente la misma estructura que comienza en la base del JAR. La carpeta $ {basedir} / src / main / resources / META-INF usualmente contiene archivos .properties mientras que en el jar contiene un MANIFEST.MF generado, pom.properties , el pom.xml , entre otros archivos. También los marcos como Spring usan classpath:/META-INF/resources/ para servir los recursos web. Para más información, vea 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 a otras carpetas en el frasco. Los elementos anidados dentro de la carpeta META-INF no se mezclan con los elementos que están fuera de ella.

Piensa en ello como otra raíz. Desde el método Enumerator<URL> ClassLoader#getSystemResources(String path) y otra perspectiva:

Cuando la ruta dada comienza con "META-INF", el método busca recursos que están anidados dentro de las carpetas META-INF de todos los archivos jar en la ruta de clase.

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

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

De la especificación de archivo JAR oficial (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
La plataforma Java 2 reconoce e interpreta los siguientes archivos / directorios en el directorio META-INF para configurar aplicaciones, extensiones, cargadores de clases y servicios:
MANIFEST.MF

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

Este archivo es generado por 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. Forma parte de la implementación de JarIndex y la utilizan los cargadores de clases para acelerar su 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.

En general, no debes poner nada en META-INF por ti mismo. En su lugar, debe confiar en lo que use para empaquetar su JAR. Esta es una de las áreas en las que creo que Ant realmente sobresale: especificar atributos de manifiesto de archivos JAR. Es muy fácil decir algo como:

<jar ...> <manifest> <attribute name="Main-Class" value="MyApplication"/> </manifest> </jar>

Al menos, creo que eso es fácil ... :-)

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

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 otras cosas allí.

¿Por qué es este el caso?

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

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

Pero en realidad no parece haber ningún estándar, no hay nada que no debas hacer. Por lo general, estas cosas se definen de manera muy rigurosa, pero por alguna razón, parece que aquí no hay normas. Impar. Parece que META-INF se ha convertido en un punto de encuentro para cualquier configuración necesaria que no pueda manejarse fácilmente de otra manera.

La carpeta META-INF es el hogar 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 la estática main () para archivos JAR ejecutables.

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

<import resource="classpath:/META-INF/cxf/cxf.xml" /> <import resource="classpath:/META-INF/cxf/cxf-extensions-*.xml" />

En este ejemplo, cito 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é qué sería exactamente incorrecto con la simple inclusión de los archivos de configuración en un paquete Java específico, en lugar de en META-INF. Pero parece ser un estándar de facto emergente; ya sea eso, o un anti-patrón emergente :-)

Si está utilizando JPA1, es posible que deba colocar un archivo persistence.xml allí 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, clases y archivos jar que contienen todas las clases que se conservarán en una agrupación.

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

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

Solo para agregar a la información aquí, 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 el contenedor que garantiza que el contenedor pueda encontrar todas las clases que su aplicación depende de. Esto garantiza que, en caso de que se haya perdido un JAR, no tenga que esperar hasta que su aplicación funcione en tiempo de ejecución para darse cuenta de que falta.

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

Por ejemplo:

META-INF/resources/button.jpg

y conseguirlos en web3.0-container via

http://localhost/myapp/button.jpg

> Leer más

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

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

Tiene un archivo MANIFEST.MF dentro de su 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 La aplicación se referirá a la dependencia desde allí (y no se bloqueará).

Source: Head First Jsp & Servlet

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

Vaya a Tomcat Doc y verifique 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 a la base xmlB del Host propietario cuando se implementa la aplicación. En los inicios posteriores, 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 predeterminado de la bandera es falso. Tenga en cuenta que si el atributo deployXML del Host propietario es falso o si el atributo copyXML del Host propietario es verdadero, este atributo no tendrá efecto.