META-INF'in amacı nedir?

resmi JAR Dosya Belirtimi (bağlantı Java 7 sürümüne gider, ancak metin en az v1.3'ten bu yana değişmedi):

META-INF dizini

META-INF dizinindeki aşağıdaki dosyalar/dizinler uygulamaları, uzantıları, sınıf yükleyicileri ve hizmetleri yapılandırmak için Java 2 Platformu tarafından tanınır ve yorumlanır:

• MANIFEST.MF

Uzantı ve paket ile ilgili verileri tanımlamak için kullanılan bildirim dosyası.

• INDEX.LIST

Bu dosya, bir uygulamada veya uzantıda tanımlanan paketler için konum bilgisi içeren kavanoz aracının yeni "-i" seçeneği tarafından oluşturulur. JarIndex uygulamasının bir parçasıdır ve sınıf yükleyiciler tarafından sınıf yükleme işlemlerini hızlandırmak için kullanılır.

• x.SF

JAR dosyasının imza dosyası. 'x', temel dosya adı anlamına gelir.

• x.DSA

Aynı temel dosya adına sahip imza dosyasıyla ilişkilendirilmiş imza blok dosyası. Bu dosya karşılık gelen imza dosyasının dijital imzasını saklar.

• services/

Bu dizin tüm servis sağlayıcı yapılandırma dosyalarını saklar.

Bazı Java kütüphanelerinin META-INF'i, JAR'larla birlikte CLASSPATH'a paketlenmesi ve dahil edilmesi gereken konfigürasyon dosyalarını içerecek bir dizin olarak kullanmaya başladığını fark ettim. Örneğin, Spring aşağıdakileri kullanarak sınıf yolunda bulunan XML Dosyalarını içe aktarmanıza izin verir:

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

Bu örnekte, Apache CXF Kullanıcı Kılavuz üzerinden doğrudan alıntı yapıyorum. İlkbaharda çoklu konfigürasyon seviyelerine izin vermemiz gereken bir projede bu sözleşmeyi takip ettik ve konfigürasyon dosyalarımızı META-INF'e koyduk.

Bu kararı verdiğimde, yapılandırma dosyalarını META-INF yerine belirli bir Java paketine dahil etmenin tam olarak neyin yanlış olacağını bilmiyorum. Ancak ortaya çıkmakta olan fiili bir standart gibi görünüyor; O ya da yeni ortaya çıkan bir anti-patern :-)

META-INF klasörü MANIFEST.MF dosyasının evidir. Bu dosya, JAR'ın içeriği hakkındaki meta verileri içerir. Örneğin, çalıştırılabilir JAR dosyaları için statik ana () ile Java sınıfının adını belirten Main-Class adlı bir giriş var.

Ayrıca statik kaynakları oraya da yerleştirebilirsiniz.

Örnek olarak:

META-INF/resources/button.jpg 

ve onları web3.0-container’a yoluyla alın

http://localhost/myapp/button.jpg

> Daha fazla bilgi edinin

/META-INF/MANIFEST.MF'in özel bir anlamı vardır:

1. Java -jar myjar.jar org.myserver.MyMainClass kullanarak bir kavanoz çalıştırırsanız, ana sınıf tanımını kavanozun içine taşıyabilir, böylece aramayı Java -jar myjar.jar olarak küçültebilirsiniz.
2. Java.lang.Package.getPackage("org.myserver").getImplementationTitle() kullanıyorsanız, Metainformations paketlerini tanımlayabilirsiniz.
3. Applet/Webstart modunda kullanmak istediğiniz dijital sertifikalara başvurabilirsiniz.

Buraya sadece bilgi eklemek için, bir WAR dosyası olması durumunda, META-INF/MANIFEST.MF dosyası, geliştiriciye, kabın uygulamanızın tüm sınıfları bulmasını sağlayan kabı tarafından bir dağıtım zamanı kontrolü başlatma olanağı sağlar. bağlıdır. Bu, bir JAR'ı kaçırmanız durumunda uygulamanızın eksik olduğunu fark etmek için çalışma zamanında çalışmasını beklemeniz gerekmez.

Buradaki bilgilere ek olarak, META-INF ClassLoader öğesinin kavanozdaki diğer klasörlerden farklı şekilde işlediği özel bir klasördür. META-INF klasörünün içine yerleştirilmiş öğeler, dışındaki öğelerle karıştırılmaz.

Başka bir kök gibi düşün. Enumerator<URL> ClassLoader#getSystemResources(String path) yönteminden ve perspektifinden:

Verilen yol "META-INF" ile başladığında, yöntem sınıf yolundaki tüm kavanozların META-INF klasörlerinde bulunan kaynakları arar.

Verilen yol "META-INF" ile başlamazsa, yöntem sınıf yolundaki tüm kavanozların ve dizinlerin diğer tüm klasörlerindeki (META-INF dışında) kaynakları arar.

getSystemResources yönteminin özel olarak ele aldığı başka bir klasör adı biliyorsanız, lütfen bu konuda yorum yapın.

Son zamanlarda bu konuda düşünüyorum. META-INF kullanımında herhangi bir kısıtlama olmadığı görülüyor. Tabii ki, tezahürü oraya koymanın gerekliliği hakkında kesin kısıtlamalar var, ancak oraya başka şeyler koymakla ilgili herhangi bir yasak görünmüyor.

Bu neden böyle?

Cxf davası okunaklı olabilir. İşte bu standart dışı standartın JBoss-ws’de bir wsdl şemasına karşı sunucu tarafından doğrulanmasını önleyen kötü bir hatayla karşılaşılması önerilen bir başka yer.

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

Ama gerçekten herhangi bir standart, görünmüyor gibi görünmüyor. Genellikle bu şeyler çok titizlikle tanımlanır, ancak bazı nedenlerden dolayı burada standart olmadığı görülmektedir. Garip. META-INF, başka bir şekilde kolayca idare edilemeyen ihtiyaç duyulan herhangi bir konfigürasyon için çekici bir yer haline gelmiş gibi görünüyor.

Maven'de META-INF

Maven'de META-INF klasörü Standart Dizin Düzeni nedeniyle ad konvansiyonel olarak JARs içinde proje kaynaklarınızı paketleyen bir isimdir. : $ {basedir}/src/main/resources dizinine yerleştirilen tüm dizinler veya dosyalar, JAR'ın tabanında başlayan aynı yapı ile JAR'ınıza paketlenir. Klasör $ {basedir}/src/main/resources/META-INF genellikle kavanozun içindeyken . Özellikleri dosyaları içerir. oluşturulan MANIFEST.MF , pom.properties , pom.xml , diğer dosyalar arasında. Ayrıca Spring gibi çerçeveler de web kaynaklarını sunmak için classpath:/META-INF/resources/ kullanın. Daha fazla bilgi için bkz. Maven Projeme kaynakları nasıl eklerim

JPA1 kullanıyorsanız, kullanmak isteyebileceğiniz bir kalıcılık biriminin adını belirten bir persistence.xml dosyası bırakmanız gerekebilir. Kalıcılık birimi, bir grup metadata dosyası, sınıfları ve bir gruplamaya devam etmek için tüm sınıfları içeren kavanozları belirlemenin uygun bir yolunu sağlar.

import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

// ...

EntityManagerFactory emf =
      Persistence.createEntityManagerFactory(persistenceUnitName);

Buradan daha fazlasını görün: http://www.datanucleus.org/products/datanucleus/jpa/emf.html

Tüm cevaplar doğru. Meta-inf'in birçok amacı var. Buna ek olarak, burada Tomcat kabını kullanma hakkında bir örnek.

Tomcat Doc adresine gidin ve " Standart Uygulama> copyXML " özelliğini kontrol edin.

Açıklama aşağıdadır.

Uygulamanın içine gömülü bir bağlam XML tanımlayıcısının (/META-INF/context.xml adresinde bulunur), uygulama dağıtıldığında sahip olan ana bilgisayarın xmlBase dosyasına kopyalanmasını istiyorsanız, true olarak ayarlayın. Daha sonraki başlangıçlarda, kopyalanan içerik XML tanımlayıcısı, uygulamanın içine gömülmüş tanımlayıcı daha yeni olsa bile, uygulamanın içine gömülü olan herhangi bir bağlam XML tanımlayıcısına tercih edilecektir. Bayrak değeri varsayılan olarak false olur. Sahip olan Host'un deployXML özniteliği yanlışsa veya sahip olan Host'un copyXML özniteliği true ise, bu özniteliğin hiçbir etkisi olmayacağını unutmayın.

META-INF klasörünüzün içinde MANIFEST.MF dosyanız var. Yapmanız gereken isteğe bağlı veya harici bağımlılıkları tanımlayabilirsiniz.

Örnek:

Uygulamanızı ve kapsayıcınızı (çalışma zamanında) kullandığınızı ve uygulamanızın lib klasörü içinde olmayan bir kütüphanenin daha yeni bir sürümünü gerektirdiğini, bu durumda isteğe bağlı yeni sürümü MANIFEST.MF o zaman uygulamanız oradan bağımlılık anlamına gelir (ve çökmeyecektir).

Source: Baş İlk Jsp ve Sunucu Uygulaması