Qual è lo scopo di META-INF?

In Java, si vede spesso una cartella META-INF contenente alcuni meta file. Qual è lo scopo di questa cartella e cosa posso inserire?

In generale, non dovresti inserire nulla nel META-INF. Invece, dovresti fare affidamento su qualsiasi cosa tu usi per impacchettare il tuo JAR. Questa è una delle aree in cui penso che Ant eccelle davvero: specificando gli attributi manifest del file JAR. È molto facile dire qualcosa del tipo:

     

Almeno, penso che sia facile … 🙂

Il punto è che META-INF dovrebbe essere considerato una meta directory interna di Java. Non scherzare! Tutti i file che vuoi includere con il tuo JAR dovrebbero essere collocati in qualche altra sottodirectory o nella radice del JAR stesso.

Dalla specifica file JAR ufficiale (il collegamento va alla versione Java 7, ma il testo non è cambiato almeno dalla v1.3):

La directory META-INF

I seguenti file / directory nella directory META-INF sono riconosciuti e interpretati dalla piattaforma Java 2 per configurare applicazioni, estensioni, caricatori di classi e servizi:

  • MANIFEST.MF

Il file manifest utilizzato per definire l’estensione e i dati relativi ai pacchetti.

  • INDEX.LIST

Questo file è generato dalla nuova opzione ” -i ” dello strumento jar, che contiene informazioni sulla posizione per i pacchetti definiti in un’applicazione o un’estensione. Fa parte dell’implementazione JarIndex e viene utilizzata dai caricatori di classi per accelerare il processo di caricamento della class.

  • x.SF

Il file di firma per il file JAR. ‘x’ sta per il nome del file di base.

  • x.DSA

Il file del blocco della firma associato al file della firma con lo stesso nome del file di base. Questo file memorizza la firma digitale del file di firma corrispondente.

  • services/

Questa directory memorizza tutti i file di configurazione del service provider.

Ho notato che alcune librerie Java hanno iniziato a utilizzare META-INF come directory in cui includere i file di configurazione che dovrebbero essere pacchettizzati e inclusi nel CLASSPATH insieme ai JAR. Ad esempio, Spring consente di importare file XML presenti nel classpath utilizzando:

   

In questo esempio, sto citando direttamente dalla Guida dell’utente di Apache CXF . Su un progetto a cui ho lavorato in cui dovevamo consentire più livelli di configurazione tramite Spring, abbiamo seguito questa convenzione e inserito i file di configurazione in META-INF.

Quando rifletto su questa decisione, non so esattamente cosa sarebbe sbagliato semplicemente includendo i file di configurazione in uno specifico pacchetto Java, piuttosto che in META-INF. Ma sembra essere uno standard di fatto emergente; o quello, o un anti-pattern emergente 🙂

Puoi anche inserire risorse statiche lì.

Per esempio:

 META-INF/resources/button.jpg 

e portali in web3.0-container via

 http://localhost/myapp/button.jpg 

> Leggi di più

/META-INF/MANIFEST.MF ha un significato speciale:

  1. Se si esegue un jar utilizzando java -jar myjar.jar org.myserver.MyMainClass è ansible spostare la definizione della class principale nel jar in modo da poter ridurre la chiamata in java -jar myjar.jar .
  2. È ansible definire le metainformazioni sui pacchetti se si utilizza java.lang.Package.getPackage("org.myserver").getImplementationTitle() .
  3. È ansible fare riferimento ai certificati digitali che si desidera utilizzare in modalità Applet / Webstart.

La cartella META-INF è la casa per il file MANIFEST.MF . Questo file contiene metadati sul contenuto del JAR. Ad esempio, esiste una voce denominata Main-Class che specifica il nome della class Java con la statica main () per i file JAR eseguibili.

Solo per aggiungere informazioni qui, nel caso di un file WAR, il file META-INF / MANIFEST.MF fornisce allo sviluppatore una funzionalità per avviare un controllo del tempo di distribuzione da parte del contenitore che garantisce che il contenitore possa trovare tutte le classi dell’applicazione dipende da. Questo assicura che nel caso in cui tu abbia perso un JAR, non devi aspettare fino a quando la tua applicazione non esplode in runtime per rendersi conto che manca.

Ho pensato a questo problema di recente. Sembra che non ci siano restrizioni sull’uso di META-INF. Ci sono certe restrizioni, ovviamente, sulla necessità di mettere il manifesto lì, ma non sembrano esserci proibizioni sul mettere altre cose lì.

Perché è così?

Il caso cxf potrebbe essere legittimo. Ecco un altro punto in cui questo non standard è consigliato per aggirare un bug insidioso in JBoss-ws che impedisce la convalida sul lato server rispetto allo schema di un wsdl.

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

Ma in realtà non sembrano esserci standard, nessuno-no. Di solito queste cose sono definite molto rigorosamente, ma per qualche ragione, sembra che non ci siano standard qui. Dispari. Sembra che il META-INF sia diventato un luogo catchall per qualsiasi configurazione necessaria che non possa essere facilmente gestita in altro modo.

Se utilizzi JPA1, potresti dover inserire un file persistence.xml che specifica il nome di un’unità di persistenza che potresti voler utilizzare. Un’unità di persistenza fornisce un modo conveniente per specificare un insieme di file di metadati e classi e jar che contengono tutte le classi da mantenere in un raggruppamento.

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

Vedi di più qui: http://www.datanucleus.org/products/datanucleus/jpa/emf.html

META-INF in Maven

In Maven la cartella META-INF è compresa grazie al layout di directory standard che per convenzione di nome raggruppa le risorse del progetto all’interno di JAR: qualsiasi directory o file inseriti nella directory $ {basedir} / src / main / resources sono impacchettati nel JAR con la stessa identica struttura che inizia alla base del JAR. La cartella $ {basedir} / src / main / resources / META-INF di solito contiene i file .properties mentre nel jar contiene un MANIFEST.MF generato, pom.properties , il pom.xml , tra gli altri file. Anche framework come Spring classpath:/META-INF/resources/ per servire le risorse web. Per maggiori informazioni vedi Come posso aggiungere risorse al mio Progetto Maven

Aggiungendo alle informazioni qui, il META-INF è una cartella speciale che ClassLoader tratta in modo diverso dalle altre cartelle nel jar. Gli elementi nidificati all’interno della cartella META-INF non sono mescolati con gli elementi al di fuori di essa.

Pensalo come un’altra radice. Dal metodo Enumerator ClassLoader#getSystemResources(String path) et al perspective:

Quando il percorso specificato inizia con “META-INF”, il metodo ricerca le risorse che sono nidificate all’interno delle cartelle META-INF di tutti i vasi nel percorso della class.

Quando il percorso specificato non inizia con “META-INF”, il metodo cerca le risorse in tutte le altre cartelle (al di fuori del META-INF) di tutti i jar e le directory nel percorso della class.

Se si conosce un altro nome di cartella che il metodo getSystemResources tratta specificamente, si prega di commentarlo.

Tutte le risposte sono corrette Meta-inf ha molti scopi. Inoltre, ecco un esempio sull’utilizzo del contenitore Tomcat.

Vai a Doc Tomcat e controlla l’attributo ” Implementazione standard> copyXML “.

La descrizione è di seguito

Impostare su true se si desidera che un descrittore XML del contesto sia incorporato nell’applicazione (che si trova in /META-INF/context.xml) per essere copiato nell’XmlBase dell’host proprietario all’atto della distribuzione dell’applicazione. Negli avvii successivi, il descrittore XML del contesto copiato verrà utilizzato preferibilmente a qualsiasi descrittore XML del contesto incorporato nell’applicazione, anche se il descrittore incorporato nell’applicazione è più recente. Il valore del flag è impostato su false. Nota se l’attributo deployXML dell’host proprietario è falso o se l’attributo copyXML dell’host proprietario è true, questo attributo non avrà alcun effetto.

Hai un file MANIFEST.MF nella tua cartella META-INF. È ansible definire dipendenze opzionali o esterne alle quali è necessario avere accesso.

Esempio:

Considera che hai distribuito la tua app e il tuo contenitore (in fase di esecuzione) ha scoperto che la tua app richiede una versione più recente di una libreria che non si trova nella cartella lib, in tal caso se hai definito la versione più recente opzionale in MANIFEST.MF allora il tuo l’app si riferirà alla dipendenza da lì (e non si bloccherà).

Source: Head First Jsp & Servlet