Réponses:
De manière générale, vous ne devez rien mettre vous-même dans META-INF. Au lieu de cela, vous devez vous fier à tout ce que vous utilisez pour emballer votre JAR. C'est l'un des domaines où je pense que Ant excelle vraiment: la spécification des attributs de manifeste du fichier JAR. Il est très facile de dire quelque chose comme:
<jar ...>
<manifest>
<attribute name="Main-Class" value="MyApplication"/>
</manifest>
</jar>Du 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 avec votre JAR doivent être placés dans un autre sous-répertoire ou à la racine du JAR lui-même.
De la spécification officielle du fichier JAR (lien vers la version Java 7, mais le texte n'a pas changé depuis au moins la 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 les applications, extensions, chargeurs de classe et services:
MANIFEST.MFFichier manifeste utilisé pour définir les données relatives à l'extension et au package.
INDEX.LISTCe fichier est généré par la nouvelle
-ioption " " de l'outil jar, qui contient des informations d'emplacement pour les packages définis dans une application ou une extension. Il fait partie de l'implémentation JarIndex et est utilisé par les chargeurs de classe pour accélérer leur processus de chargement de classe.
x.SFFichier de signature du fichier JAR. 'x' représente le nom du fichier de base.
x.DSALe 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 devraient être empaquetés et inclus dans le CLASSPATH avec les JAR. Par exemple, Spring vous permet d'importer des fichiers XML qui se trouvent sur le chemin de classe en utilisant:
<import resource="classpath:/META-INF/cxf/cxf.xml" />
<import resource="classpath:/META-INF/cxf/cxf-extensions-*.xml" />Dans cet exemple, je cite tout droit sorti du 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 placé nos fichiers de configuration dans META-INF.
Quand je réfléchis à cette décision, je ne sais pas exactement ce qui serait mal avec simplement l'inclusion des 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 :-)
Le dossier META-INF héberge le 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 statique principal () pour les fichiers JAR exécutables.
Vous pouvez également y placer des ressources statiques.
Par exemple:
META-INF/resources/button.jpg et les obtenir dans le conteneur web3.0 via
http://localhost/myapp/button.jpgLe /META-INF/MANIFEST.MF a une signification particulière:
java -jar myjar.jar org.myserver.MyMainClassvous pouvez déplacer la définition de la classe principale dans le fichier jar afin de pouvoir réduire l'appel dans java -jar myjar.jar.java.lang.Package.getPackage("org.myserver").getImplementationTitle().Dans Maven, le dossier META-INF est compris en raison de la disposition de répertoire standard , qui, par convention de nom, regroupe les ressources de votre projet dans les fichiers JAR: tous les répertoires ou fichiers placés dans le répertoire $ {basedir} / src / main / resources sont intégrés dans votre fichier JAR avec exactement la même structure à partir de la base du JAR. Le dossier $ {basedir} / src / main / resources / META-INF contient généralement des fichiers .properties tandis que dans le bocal contient un MANIFEST.MF généré , pom.properties , le pom.xml , entre autres fichiers. Des frameworks comme Spring utilisent également Comment ajouter des ressources à mon projet Maven .classpath:/META-INF/resources/ des ressources Web. Pour plus d'informations, voir
Juste pour ajouter aux informations ici, dans le cas d'un fichier WAR, le fichier META-INF / MANIFEST.MF offre au développeur la possibilité d'initier une vérification du temps de déploiement par le conteneur qui garantit que le conteneur peut trouver toutes les classes de votre application dépend de. Cela garantit qu'au cas où vous auriez manqué un JAR, vous n'avez pas à attendre que votre application explose au moment de l'exécution pour se rendre compte qu'il est manquant.
J'ai pensé à cette question récemment. Il ne semble vraiment pas y avoir de restriction sur l'utilisation de META-INF. Il y a bien sûr certaines restrictions concernant la nécessité d'y mettre le manifeste, mais il ne semble pas y avoir d'interdiction d'y mettre d'autres choses.
pourquoi est-ce le cas?
Le cas cxf peut être légitime. Voici un autre endroit où ce non standard est recommandé pour contourner un bogue désagréable dans JBoss-ws qui empêche la validation côté serveur contre le schéma d'un wsdl.
http://community.jboss.org/message/570377#570377
Mais il ne semble vraiment pas y avoir de normes, pas de mille. Habituellement, ces choses sont définies très rigoureusement, 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 capture pour toute configuration nécessaire qui ne peut pas être facilement gérée d'une autre manière.
En plus des informations ici, le META-INF est un dossier spécial qui le ClassLoadertraite différemment des autres dossiers du pot. Les éléments imbriqués dans le dossier META-INF ne sont pas mélangés avec les éléments à l'extérieur de celui-ci.
Pensez-y comme une autre racine. Du point de vue de la Enumerator<URL> ClassLoader#getSystemResources(String path)méthode et al:
Lorsque le chemin d'accès donné commence par "META-INF", la méthode recherche les ressources imbriquées dans les dossiers META-INF de tous les fichiers JAR du chemin d'accès aux classes.
Lorsque le chemin donné ne commence pas par "META-INF", la méthode recherche les ressources dans tous les autres dossiers (en dehors de META-INF) de tous les fichiers JAR et répertoires du chemin de classe.
Si vous connaissez un autre nom de dossier que la getSystemResourcesméthode traite spécialement, veuillez en faire part.
Si vous utilisez JPA1, vous devrez peut-être y déposer un persistence.xmlfichier qui spécifie le nom d'une unité de persistance que vous voudrez peut-être utiliser. Une unité de persistance fournit un moyen pratique de spécifier un ensemble de fichiers de métadonnées, de classes et de fichiers JAR qui contiennent 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
Toutes les réponses sont correctes. Meta-inf a de nombreux objectifs. De plus, voici un exemple d'utilisation du conteneur tomcat.
Accédez à Tomcat Doc et cochez l' attribut " Implémentation standard> copyXML ".
La description est ci-dessous.
Affectez la valeur true si vous souhaitez qu'un descripteur XML de contexte intégré à l'application (situé dans /META-INF/context.xml) soit copié dans la xmlBase de l'hôte propriétaire lors du déploiement de l'application. Lors des démarrages suivants, le descripteur XML de contexte copié sera utilisé de préférence à tout descripteur XML de contexte incorporé à l'intérieur de l'application même si le descripteur incorporé à l'intérieur de l'application est plus récent. La valeur de l'indicateur par défaut est false. Notez que si l'attribut deployXML de l'hôte propriétaire est faux ou si l'attribut copyXML de l'hôte propriétaire est vrai, cet attribut 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 accès.
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 plus récente facultative, MANIFEST.MFvotre application se référera à la dépendance à partir de là (et ne plantera pas).
Source: Head First Jsp & Servlet