Wat is het doel van META-INF?

In Java zie je vaak een META-INF-map met enkele metabestanden. Wat is het doel van deze map en wat kan ik daar plaatsen?

Antwoord 1, autoriteit 100%

Over het algemeen moet u zelf niets in META-INF invoeren. In plaats daarvan moet u vertrouwen op wat u ook gebruikt om uw JAR in te pakken. Dit is een van de gebieden waar ik denk dat Ant echt uitblinkt: het specificeren van JAR-bestandsmanifestattributen. Het is heel gemakkelijk om iets te zeggen als:

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

Tenminste, ik denk dat dat makkelijk is… 🙂

Het punt is dat META-INF moet worden beschouwd als een interne Java meta-directory. Knoei er niet mee! Alle bestanden die u aan uw JAR wilt toevoegen, moeten in een andere submap of in de hoofdmap van de JAR zelf worden geplaatst.

Antwoord 2, autoriteit 90%

Van de officiële JAR-bestandsspecificatie(link gaat naar de Java 7-versie, maar de tekst is niet veranderd sinds ten minste v1.3):

De META-INF-directory

De volgende bestanden/mappen in de META-INF-map worden herkend en geïnterpreteerd door het Java 2-platform om toepassingen, extensies, klasseladers en services te configureren:

• MANIFEST.MF

Het manifestbestand dat wordt gebruikt om extensie- en pakketgerelateerde gegevens te definiëren.

• INDEX.LIST

Dit bestand wordt gegenereerd door de nieuwe optie “-i” van de jar-tool, die locatie-informatie bevat voor pakketten die zijn gedefinieerd in een toepassing of extensie. Het maakt deel uit van de JarIndex-implementatie en wordt gebruikt door klasseladers om het laadproces van hun klasse te versnellen.

• x.SF

Het handtekeningbestand voor het JAR-bestand. ‘x’ staat voor de naam van het basisbestand.

• x.DSA

Het handtekeningblokbestand dat is gekoppeld aan het handtekeningbestand met dezelfde basisbestandsnaam. Dit bestand slaat de digitale handtekening van het corresponderende handtekeningbestand op.

• services/

In deze map worden alle configuratiebestanden van de serviceprovider opgeslagen.

Antwoord 3, autoriteit 40%

Ik heb gemerkt dat sommige Java-bibliotheken META-INF zijn gaan gebruiken als een map waarin configuratiebestanden moeten worden opgenomen die samen met JAR’s in het CLASSPATH moeten worden verpakt en opgenomen. Met Spring kunt u bijvoorbeeld XML-bestanden importeren die zich in het klassenpad bevinden met:

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

In dit voorbeeld citeer ik rechtstreeks uit de Apache CXF-gebruikershandleiding . Bij een project waaraan ik werkte waarbij we via Spring meerdere configuratieniveaus moesten toestaan, hebben we deze conventie gevolgd en onze configuratiebestanden in META-INF geplaatst.

Als ik over deze beslissing nadenk, weet ik niet wat er precies mis zou zijn om de configuratiebestanden gewoon in een specifiek Java-pakket op te nemen, in plaats van in META-INF. Maar het lijkt een opkomende de facto standaard te zijn; ofwel dat, ofwel een opkomend anti-patroon 🙂

Antwoord 4, autoriteit 20%

De map META-INF is de thuisbasis voor het MANIFEST. MF-bestand. Dit bestand bevat metadata over de inhoud van de JAR. Er is bijvoorbeeld een item met de naam Main-Class dat de naam van de Java-klasse specificeert met de statische main() voor uitvoerbare JAR-bestanden.

Antwoord 5, autoriteit 14%

Je kunt daar ook statische bronnen plaatsen.

Bijvoorbeeld:

META-INF/resources/button.jpg 

en haal ze in web3.0-container via

http://localhost/myapp/button.jpg

> Lees meer

De /META-INF/MANIFEST.MF heeft een speciale betekenis:

1. Als u een jar uitvoert met java -jar myjar.jar org.myserver.MyMainClass, kunt u de definitie van de hoofdklasse naar de jar verplaatsen, zodat u de aanroep kunt verkleinen tot java -jar myjar.jar.
2. U kunt Metaformations voor pakketten definiëren als u java.lang.Package.getPackage("org.myserver").getImplementationTitle()gebruikt.
3. Je kunt verwijzen naar digitale certificaten die je graag gebruikt in Applet/Webstart-modus.

Antwoord 6, autoriteit 13%

META-INF in Maven

In Maven wordt de map META-INFbegrepen vanwege de Standaard directory-indeling, die volgens naamconventie uw projectbronnen in JAR’s verpakt: alle mappen of bestanden die zijn geplaatst in de ${basedir}/src/main/ resourceszijn in uw JAR verpakt met exact dezelfde structuur, beginnend bij de basis van de JAR. De map ${basedir}/src/main/resources/META-INFbevat meestal .properties-bestanden terwijl in de jar een gegenereerde MANIFEST.MF, pom.properties, de pom.xml, onder andere bestanden. Ook frameworks zoals Springgebruik classpath:/META-INF/resources/om webbronnen aan te bieden. Voor meer informatie zie Hoe voeg ik bronnen toe aan mijn Maven-project.

Antwoord 7, autoriteit 9%

Als aanvulling op de informatie hier, is de META-INF een speciale map die de ClassLoaderanders behandelt dan andere mappen in de jar.
Elementen die in de META-INF-map zijn genest, worden niet gemengd met de elementen daarbuiten.

Zie het als een andere wortel. Van de Enumerator<URL> ClassLoader#getSystemResources(String path)methode et al perspectief:

Als het opgegeven pad begint met “META-INF”, zoekt de methode naar bronnen die zijn genest in de META-INF-mappen van alle jars in het klassenpad.

Als het opgegeven pad niet begint met “META-INF”, zoekt de methode naar bronnen in alle andere mappen (buiten de META-INF) van alle jars en mappen in het klassenpad.

Als u een andere mapnaam kent die speciaal door de getSystemResources-methode wordt behandeld, kunt u er een opmerking over maken.

Antwoord 8, autoriteit 7%

Om toe te voegen aan de informatie hier, in het geval van een WAR-bestand, biedt het META-INF/MANIFEST.MF-bestand de ontwikkelaar de mogelijkheid om een implementatietijdcontrole door de container te starten die ervoor zorgt dat de container alle klassen waar uw toepassing van afhankelijk is. Dit zorgt ervoor dat als u een JAR hebt gemist, u niet hoeft te wachten tot uw toepassing tijdens runtime ontploft om te beseffen dat deze ontbreekt.

Antwoord 9, autoriteit 7%

Ik heb onlangs over dit probleem nagedacht. Er lijkt echt geen beperking te zijn op het gebruik van META-INF. Er zijn natuurlijk bepaalde beperkingen met betrekking tot de noodzaak om het manifest daar te plaatsen, maar er lijken geen verbodsbepalingen te zijn om andere dingen daar te plaatsen.

Waarom is dit het geval?

De cxf-zaak is mogelijk legitiem. Hier is nog een plaats waar deze niet-standaard wordt aanbevolen om een vervelende bug in JBoss-ws te omzeilen die validatie aan de serverzijde tegen het schema van een wsdl verhindert.

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

Maar er lijken echt geen normen te zijn, geen gij-zult-niet. Meestal zijn deze dingen zeer strikt gedefinieerd, maar om de een of andere reden lijkt het erop dat er hier geen normen zijn. Vreemd. Het lijkt erop dat META-INF een verzamelplaats is geworden voor elke benodigde configuratie die niet gemakkelijk op een andere manier kan worden afgehandeld.

Antwoord 10, autoriteit 4%

Als je JPA1 gebruikt, moet je misschien een persistence.xml-bestand daarin plaatsen dat de naam specificeert van een persistentie-eenheid die je misschien wilt gebruiken. Een persistentie-eenheid biedt een handige manier om een set metadatabestanden, klassen en jars te specificeren die alle klassen bevatten die in een groep moeten worden bewaard.

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

Bekijk hier meer:
http://www.datanucleus.org/products/datanucleus/jpa/emf. html

Antwoord 11

Alle antwoorden zijn correct. Meta-inf heeft vele doelen. Daarnaast is hier een voorbeeld over het gebruik van een Tomcat-container.

Ga naar
Tomcat Docen controleer
” Standaardimplementatie > copyXML” kenmerk.

Beschrijving staat hieronder.

Stel in op true als u wilt dat een context-XML-descriptor die is ingesloten in de toepassing (te vinden op /META-INF/context.xml) wordt gekopieerd naar de xmlBase van de eigenaar van de host wanneer de toepassing wordt geïmplementeerd. Bij volgende start zal de gekopieerde context XML-descriptor worden gebruikt in plaats van elke context XML-descriptor die in de toepassing is ingesloten, zelfs als de in de toepassing ingesloten descriptor recenter is. De waarde van de vlag is standaard onwaar. Merk op dat als het deployXML-kenmerk van de eigenaar van de Host false is of als het copyXML-kenmerk van de eigenaar van de Host waar is, dit attribuut geen effect heeft.

Antwoord 12

Je hebt een MANIFEST.MF-bestand in je META-INF-map. U kunt optionele of externe afhankelijkheden definiërenwaartoe u toegang moet hebben.

Voorbeeld:

Bedenk dat u uw app hebt geïmplementeerd en dat uw container (tijdens runtime) heeft ontdekt dat uw app een nieuwere versie van een bibliotheek vereist die zich niet in de lib-map bevindt, in dat geval als u de optionele nieuwere versie hebt gedefinieerd in MANIFEST.MFdan zal je app vanaf daar verwijzen naar afhankelijkheid (en niet crashen).

Source:Head First Jsp & Servlet