Quel est le but de META-INF?

En Java, vous voyez souvent un dossier META-INF contenant certains fichiers méta. Quel est le but de ce dossier et que puis-je y mettre?

De manière générale, vous ne devez rien mettre dans META-INF vous-même. Au lieu de cela, vous devriez vous fier à tout ce que vous utilisez pour emballer votre JAR. C’est l’un des domaines dans lesquels je pense que Ant excelle vraiment: la spécification des atsortingbuts de manifeste de fichier JAR. Il est très facile de dire quelque chose comme:

     

Au moins, je pense que c’est facile … 🙂

Le fait est que META-INF doit être considéré comme un méta- répertoire Java interne. Ne plaisante pas avec ça! Tous les fichiers que vous souhaitez inclure dans votre JAR doivent être placés dans un autre sous-répertoire ou à la racine du JAR lui-même.

A partir de la spécification de fichier JAR officielle (le lien va à la version Java 7, mais le texte n’a pas changé depuis au moins v1.3):

Le répertoire META-INF

Les fichiers / répertoires suivants du répertoire META-INF sont reconnus et interprétés par la plate-forme Java 2 pour configurer des applications, des extensions, des chargeurs de classes et des services:

  • MANIFEST.MF

Le fichier manifeste utilisé pour définir les données relatives à l’extension et au package.

  • INDEX.LIST

Ce fichier est généré par la nouvelle option ” -i ” de l’outil jar, qui contient des informations de localisation pour les packages définis dans une application ou une extension. Il fait partie de l’implémentation de JarIndex et est utilisé par les chargeurs de classes pour accélérer leur processus de chargement de classes.

  • x.SF

Le fichier de signature du fichier JAR. ‘x’ représente le nom du fichier de base.

  • x.DSA

Le fichier de bloc de signature associé au fichier de signature avec le même nom de fichier de base. Ce fichier stocke la signature numérique du fichier de signature correspondant.

  • services/

Ce répertoire stocke tous les fichiers de configuration du fournisseur de services.

J’ai remarqué que certaines bibliothèques Java ont commencé à utiliser META-INF comme répertoire dans lequel inclure les fichiers de configuration qui doivent être empaquetés et inclus dans CLASSPATH avec les JAR. Par exemple, Spring vous permet d’importer des fichiers XML qui se trouvent sur le chemin de classe en utilisant:

   

Dans cet exemple, je cite directement le Guide de l’utilisateur Apache CXF . Sur un projet sur lequel j’ai travaillé dans lequel nous devions autoriser plusieurs niveaux de configuration via Spring, nous avons suivi cette convention et mis nos fichiers de configuration dans META-INF.

Lorsque je réfléchis à cette décision, je ne sais pas exactement ce qui ne va pas en incluant simplement les fichiers de configuration dans un package Java spécifique, plutôt que dans META-INF. Mais cela semble être une norme de facto émergente; soit ça, soit un anti-pattern émergent 🙂

Vous pouvez également y placer des ressources statiques.

Par exemple:

 META-INF/resources/button.jpg 

et les mettre dans le conteneur web3.0 via

 http://localhost/myapp/button.jpg 

> Lire plus

Le /META-INF/MANIFEST.MF a une signification particulière:

  1. Si vous exécutez un jar en utilisant java -jar myjar.jar org.myserver.MyMainClass vous pouvez déplacer la définition de la classe principale dans le java -jar myjar.jar org.myserver.MyMainClass jar afin de réduire l’appel à java -jar myjar.jar .
  2. Vous pouvez définir des métainformations pour les packages si vous utilisez java.lang.Package.getPackage("org.myserver").getImplementationTitle() .
  3. Vous pouvez référencer des certificates numériques que vous souhaitez utiliser en mode Applet / Webstart.

Le dossier META-INF est la base du fichier MANIFEST.MF . Ce fichier contient des métadonnées sur le contenu du JAR. Par exemple, il existe une entrée appelée Main-Class qui spécifie le nom de la classe Java avec le fichier static main () pour les fichiers JAR exécutables.

Pour append aux informations ici, dans le cas d’un fichier WAR, le fichier META-INF / MANIFEST.MF fournit au développeur une fonction permettant de lancer une vérification du temps de déploiement par le conteneur, ce qui garantit que le conteneur trouvera toutes les classes de votre application dépend de. Cela garantit que si vous avez manqué un JAR, vous n’avez pas à attendre que votre application explose à l’exécution pour vous rendre compte que cela manque.

J’ai réfléchi à cette question récemment. Il ne semble pas y avoir de ressortingction à l’utilisation de META-INF. Bien sûr, il existe certaines ressortingctions quant à la nécessité de mettre le manifeste là-bas, mais il ne semble pas y avoir d’interdiction d’y placer d’autres éléments.

pourquoi est-ce le cas?

Le cas de cxf peut être légitime. Voici un autre endroit où ce non-standard est recommandé pour contourner un méchant bug dans JBoss-ws qui empêche la validation côté serveur par rapport au schéma d’un wsdl.

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

Mais il ne semble pas y avoir de normes, pas plus que rien. Habituellement, ces choses sont très rigoureusement définies, mais pour une raison quelconque, il semble qu’il n’y ait pas de normes ici. Impair. Il semble que META-INF soit devenu un lieu de prédilection pour toute configuration nécessaire qui ne peut pas être facilement manipulée autrement.

Si vous utilisez JPA1, vous devrez peut-être y déposer un fichier persistence.xml qui spécifie le nom d’une unité de persistance à utiliser. Une unité de persistance permet de spécifier un ensemble de fichiers de métadonnées, de classes et de fichiers JAR contenant toutes les classes à conserver dans un regroupement.

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

Voir plus ici: http://www.datanucleus.org/products/datanucleus/jpa/emf.html

META-INF dans Maven

Dans Maven, le dossier META-INF est compris grâce à la disposition standard des répertoires qui, par convention, nomme vos ressources de projet dans les JAR: tous les répertoires ou fichiers placés dans le répertoire $ {basedir} / src / main / resources exactement la même structure commençant à la base du JAR. Le dossier $ {basedir} / src / main / resources / META-INF contient généralement des fichiers .properties tandis que le fichier jar contient entre autres MANIFEST.MF , pom.properties , pom.xml généré. Les frameworks comme Spring utilisent également classpath:/META-INF/resources/ pour servir des ressources Web. Pour plus d’informations, voir Comment append des ressources à mon projet Maven?

Ajoutant à l’information ici, le META-INF est un dossier spécial que le ClassLoader traite différemment des autres dossiers dans le jar. Les éléments nesteds dans le dossier META-INF ne sont pas mélangés aux éléments extérieurs.

Pensez-y comme une autre racine. Dans la perspective Enumerator ClassLoader#getSystemResources(Ssortingng path) et autres:

Lorsque le chemin donné commence par “META-INF”, la méthode recherche les ressources nestedes dans les dossiers META-INF de tous les fichiers JAR du chemin de classes.

Lorsque le chemin donné ne commence pas par “META-INF”, la méthode recherche des ressources dans tous les autres dossiers (hors META-INF) de tous les jars et répertoires du chemin de classe.

Si vous connaissez un autre nom de dossier que la méthode getSystemResources traite spécialement, veuillez le commenter.

Toutes les réponses sont correctes. Meta-inf a plusieurs objectives. En outre, voici un exemple d’utilisation du conteneur tomcat.

Accédez à Tomcat Doc et cochez l’atsortingbut ” Standard Implementation> copyXML “.

La description est ci-dessous.

Définissez la valeur sur true si vous souhaitez qu’un descripteur XML de contexte incorporé dans l’application (situé dans /META-INF/context.xml) soit copié dans xmlBase de l’hôte propriétaire lorsque l’application est déployée. Lors des démarrages suivants, le descripteur XML de contexte copié sera utilisé de préférence à tout descripteur de contexte XML incorporé dans l’application, même si le descripteur incorporé dans l’application est plus récent. La valeur de l’indicateur est par défaut false. Notez que si l’atsortingbut deployXML de l’hôte propriétaire est false ou si l’atsortingbut copyXML de l’hôte propriétaire est true, cet atsortingbut n’aura aucun effet.

Vous avez un fichier MANIFEST.MF dans votre dossier META-INF. Vous pouvez définir des dépendances facultatives ou externes auxquelles vous devez avoir access.

Exemple:

Considérez que vous avez déployé votre application et que votre conteneur (au moment de l’exécution) a découvert que votre application nécessite une version plus récente d’une bibliothèque qui ne se trouve pas dans le dossier lib, dans ce cas si vous avez défini la version app fera référence à la dépendance à partir de là (et ne plantera pas).

Source: Head First Jsp & Servlet