Java에서는 메타 파일이 포함 된 META-INF 폴더가 자주 표시됩니다. 이 폴더의 목적은 무엇이며 무엇을 넣을 수 있습니까?
일반적으로 META-INF에는 아무 것도 넣지 않아야합니다. 대신 JAR을 패키지화하는 데 사용하는 모든 것을 의지해야합니다. 이것은 JAR 파일 매니페스트 특성을 지정하는 것에서 Ant가 정말 뛰어나다 고 생각하는 영역 중 하나입니다. 다음과 같은 것을 말하기는 매우 쉽습니다.
<jar ...>
<manifest>
<attribute name="Main-Class" value="MyApplication"/>
</manifest>
</jar>
적어도, 나는 그것이 쉽다라고 생각한다. ..-)
요점은 META-INF가 내부 Java meta 디렉토리로 간주되어야한다는 것입니다. 그것을 망쳐 놓지 마십시오! JAR에 포함시키려는 파일은 다른 하위 디렉토리 나 JAR 자체의 루트에 있어야합니다.
공식 JAR 파일 사양 (링크는 Java 7 버전으로 이동하지만 텍스트는 적어도 v1.3 이후로 변경되지 않았습니다.) :
META-INF 디렉토리
META-INF 디렉토리 내의 다음의 파일/디렉토리는, Java 2 플랫폼에 의해 인식되어 해석되어 어플리케이션, 확장 기능, 클래스 로더 및 서비스를 구성합니다.
MANIFEST.MF
확장 및 패키지 관련 데이터를 정의하는 데 사용되는 매니페스트 파일입니다.
INDEX.LIST
이 파일은 jar 도구의 새로운 "
-i
"옵션에 의해 생성됩니다.이 옵션에는 응용 프로그램 또는 확장에 정의 된 패키지의 위치 정보가 들어 있습니다. 이것은 JarIndex 구현의 일부이며, 클래스 로딩 프로세스의 속도를 높이기 위해 클래스 로더가 사용합니다.
x.SF
JAR 파일의 서명 파일. 'x'는 기본 파일 이름입니다.
x.DSA
동일한 기본 파일 이름을 갖는 서명 파일과 연관된 서명 블록 파일. 이 파일은 해당 서명 파일의 디지털 서명을 저장합니다.
services/
이 디렉토리는 모든 서비스 제공자 구성 파일을 저장합니다.
필자는 일부 Java 라이브러리가 JAR과 함께 CLASSPATH에 패키지되고 포함되어야하는 구성 파일을 포함하는 디렉토리로 META-INF를 사용하기 시작했습니다. 예를 들어 Spring에서는 classpath에있는 XML 파일을 다음과 같이 import 할 수 있습니다 :
<import resource="classpath:/META-INF/cxf/cxf.xml" />
<import resource="classpath:/META-INF/cxf/cxf-extensions-*.xml" />
이 예제에서는 Apache CXF User Guide 를 직접 인용하고 있습니다. Spring을 통해 여러 레벨의 설정을 허용해야했던 프로젝트에서, 우리는이 규칙을 따르고 설정 파일을 META-INF에 저장했습니다.
이 결정에 대해 생각해 보면 META-INF가 아닌 특정 Java 패키지에 구성 파일을 포함시키는 것만으로 정확히 무엇이 잘못 될지 알 수 없습니다. 그러나 사실상 표준으로 떠오르고있는 것 같습니다. 그 중 하나 또는 신흥 안티 패턴 :-)
META-INF 폴더는 MANIFEST.MF 파일의 홈입니다. 이 파일에는 JAR 내용에 대한 메타 데이터가 들어 있습니다. 예를 들어, 실행 가능한 JAR 파일에 대한 정적 main ()이있는 Java 클래스의 이름을 지정하는 Main-Class라는 항목이 있습니다.
정적 리소스를 배치 할 수도 있습니다.
예 :
META-INF/resources/button.jpg
를 통해 web3.0- 컨테이너로 가져올 수 있습니다.
http://localhost/myapp/button.jpg
/META-INF/MANIFEST.MF는 특별한 의미가 있습니다.
Java -jar myjar.jar org.myserver.MyMainClass
를 사용하여 jar를 실행하면 주 클래스 정의를 jar로 옮겨 호출을 Java -jar myjar.jar
로 축소 할 수 있습니다.Java.lang.Package.getPackage("org.myserver").getImplementationTitle()
을 사용하면 패키지에 Metainformation을 정의 할 수 있습니다.여기에 정보를 추가하기 만하면, WAR 파일의 경우 META-INF/MANIFEST.MF 파일은 개발자가 컨테이너에 의한 배포 시간 확인을 시작할 수있는 기능을 제공하여 컨테이너가 모든 클래스를 찾을 수 있도록합니다 에 달려있다. 이렇게하면 JAR을 놓친 경우 런타임에 응용 프로그램이 손상 될 때까지 기다리지 않아도 실종되었음을 알 수 있습니다.
여기에 정보를 추가하면 META-INF는 ClassLoader
이 항아리의 다른 폴더와 다르게 취급하는 특수 폴더입니다. META-INF 폴더 안에 중첩 된 요소는 외부 요소와 섞이지 않습니다.
그것을 다른 루트와 같이 생각하십시오. Enumerator<URL> ClassLoader#getSystemResources(String path)
메쏘드 외의 관점에서 :
주어진 경로가 "META-INF"로 시작할 때, 메소드는 클래스 경로에있는 모든 jar의 META-INF 폴더 안에 중첩 된 자원을 찾습니다.
주어진 경로가 "META-INF"로 시작하지 않으면 메소드는 클래스 경로에있는 모든 jar와 디렉토리의 다른 모든 폴더 (META-INF 외부)의 자원을 검색합니다.
getSystemResources
메서드가 특별히 처리하는 다른 폴더 이름을 알고 있으면 그것에 대해 설명하십시오.
나는이 문제에 대해 최근에 생각 해왔다. 실제로 META-INF의 사용에는 어떤 제한도없는 것 같습니다. 물론 그곳에 명시를해야 할 필요성에 대한 엄격한 규정이 있지만 거기에 다른 물건을 넣는 것에 대한 어떤 금지도 나타나지 않습니다.
왜 이런 경우입니까?
Cxf 케이스는 합법적 일 수 있습니다. 이 비표준이 wsdl의 스키마에 대한 서버 측 유효성 검사를 방지하는 JBoss-ws의 불쾌한 버그를 해결하기 위해 권장되는 또 다른 장소가 있습니다.
http://community.jboss.org/message/570377#570377
그러나 어떤 표준도없는 것처럼 보이지 않습니다. 일반적으로 이러한 것들은 매우 엄격하게 정의되어 있지만, 어떤 이유로 여기에는 표준이없는 것으로 보입니다. 이상한. META-INF는 다른 어떤 방법으로도 쉽게 처리 할 수없는 필요한 구성을위한 포괄적 인 장소가 된 것 같습니다.
JPA1을 사용하고 있다면, 거기에 persistence.xml
파일을 드롭해야 할 수도 있습니다.이 파일에는 사용하려는 지속성 단위의 이름을 지정합니다. 영속성 단위는 그룹화 된 모든 클래스를 포함하는 메타 데이터 파일, 클래스 및 jar 세트를 지정하는 편리한 방법을 제공합니다.
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
// ...
EntityManagerFactory emf =
Persistence.createEntityManagerFactory(persistenceUnitName);
더 많은 것을보십시오 : http://www.datanucleus.org/products/datanucleus/jpa/emf.html
Maven에서 META-INF 폴더는 표준 디렉토리 레이아웃 이름 규칙에 따라 JAR 내의 프로젝트 리소스를 패키지합니다 : $ {basedir}/src/main/resources 디렉토리는 JAR 파일의 맨 처음부터 똑같은 구조로 JAR 파일에 패키지됩니다. 폴더에는 $ (basedir)/src/main/resources/META-INF 보통 . properties 파일이 들어 있습니다. 생성 된 MANIFEST.MF, pom.properties, pom.xml 등이 있습니다. 또한 Spring 와 같은 프레임 워크는 웹 리소스를 제공하기 위해 classpath:/META-INF/resources/
를 사용합니다. 자세한 내용은 Maven 프로젝트에 리소스를 추가하는 방법
모든 대답이 정확합니다. Meta-inf에는 많은 용도가 있습니다. 또한 다음은 Tomcat 컨테이너 사용에 대한 예제입니다.
Tomcat Doc 로 이동하여 " 표준 구현> copyXML "특성을 확인하십시오.
설명은 아래와 같습니다.
응용 프로그램이 배포 될 때 (/META-INF/context.xml에있는) 응용 프로그램 내에 포함 된 컨텍스트 XML 설명자가 소유 호스트의 xmlBase에 복사되도록하려면 true로 설정합니다. 후속 시작에서 복사 된 컨텍스트 XML 설명자가 응용 프로그램 내에 포함 된 설명자가 더 최근의 경우에도 응용 프로그램 내부에 포함 된 모든 컨텍스트 XML 설명 자보다 우선 사용됩니다. 플래그의 기본값은 false입니다. 소유 호스트의 deployXML 속성이 false이거나 소유 호스트의 copyXML 속성이 true 인 경우이 속성은 아무 효과가 없습니다.
META-INF 폴더 안에 MANIFEST.MF 파일이 있습니다. --- 액세스 할 수 있어야합니다 선택적 또는 외부 종속성을 정의 할 수 있습니다.
예 :
앱을 배포하고 런타임에 컨테이너가 lib 폴더에없는 라이브러리의 최신 버전을 필요로한다는 것을 알았습니다.이 경우 MANIFEST.MF
에 새 버전 (선택 사항)을 정의한 경우 앱은 거기에서 종속성을 참조하십시오 (충돌하지 않습니다).
Source:
헤드 퍼스트 Jsp & 서블릿