Какова цель META-INF?

В Java вы часто видите папку META-INF, содержащую некоторые метафайлы. Какова цель этой папки и что я могу поместить туда?

Вообще говоря, вы не должны ничего помещать в META-INF самостоятельно. Вместо этого вы должны полагаться на все, что вы используете для упаковки вашего JAR. Это одна из областей, в которой Ant, на мой взгляд, действительно превосходит другие: указание атрибутов манифеста файла JAR. Это очень легко сказать что-то вроде:

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

По крайней мере, я думаю, что это легко ... :-)

Дело в том, что META-INF следует рассматривать как внутренний мета- каталог Java . Не связывайтесь с этим! Любые файлы, которые вы хотите включить в свой JAR, должны быть помещены в какой-то другой подкаталог или в корень самого JAR.

Из официальной спецификации файла JAR (ссылка ведет на версию Java 7, но текст не изменился, по крайней мере, начиная с версии 1.3):

Каталог МЕТА-ИНФ

Следующие файлы / каталоги в каталоге META-INF распознаются и интерпретируются платформой Java 2 для настройки приложений, расширений, загрузчиков классов и служб:

• MANIFEST.MF

Файл манифеста, который используется для определения данных расширения и пакета.

• INDEX.LIST

Этот файл создается новой -iопцией "" инструмента jar, которая содержит информацию о местоположении для пакетов, определенных в приложении или расширении. Он является частью реализации JarIndex и используется загрузчиками классов для ускорения процесса загрузки классов.

• x.SF

Файл подписи для файла JAR. «х» обозначает базовое имя файла.

• x.DSA

Файл блока подписи, связанный с файлом сигнатуры с тем же базовым именем файла. В этом файле хранится цифровая подпись соответствующего файла подписи.

• services/

В этом каталоге хранятся все файлы конфигурации поставщика услуг.

Я заметил, что некоторые библиотеки Java начали использовать META-INF в качестве каталога для включения файлов конфигурации, которые должны быть упакованы и включены в CLASSPATH вместе с JAR-файлами. Например, Spring позволяет импортировать XML-файлы, находящиеся в пути к классам, используя:

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

В этом примере я цитирую прямо из Руководства пользователя Apache CXF . В проекте, над которым я работал, в котором нам нужно было разрешить несколько уровней конфигурации через Spring, мы следовали этому соглашению и поместили наши файлы конфигурации в META-INF.

Когда я размышляю над этим решением, я не знаю, что именно было бы неправильно при простом включении файлов конфигурации в конкретный пакет Java, а не в META-INF. Но, похоже, это де-факто новый стандарт; или это, или появляющийся антипаттерн :-)

Папка META-INF является папкой для файла MANIFEST.MF . Этот файл содержит метаданные о содержимом JAR. Например, есть запись с именем Main-Class, которая задает имя класса Java со статическим main () для исполняемых файлов JAR.

Вы также можете разместить статические ресурсы там.

В примере:

META-INF/resources/button.jpg 

и получить их в web3.0-контейнере через

http://localhost/myapp/button.jpg

> Читать дальше

Файл /META-INF/MANIFEST.MF имеет особое значение:

1. Если вы используете jar с помощью, java -jar myjar.jar org.myserver.MyMainClassвы можете переместить определение основного класса в jar, чтобы вы могли уменьшить вызов в java -jar myjar.jar.
2. Вы можете определить метаинформацию для пакетов, если вы используете java.lang.Package.getPackage("org.myserver").getImplementationTitle().
3. Вы можете ссылаться на цифровые сертификаты, которые вы хотели бы использовать в режиме апплета / веб-запуска.

МЕТА-ИНФ в Maven

В Maven папка META-INF понимается из-за стандартной структуры каталогов , которая по соглашению имен упаковывает ресурсы вашего проекта в JAR-файлы: любые каталоги или файлы, размещенные в каталоге $ {basedir} / src / main / resources , упаковываются в ваш JAR-файл. с точно такой же структурой, начиная с основания JAR. Папка $ {basedir} / src / main / resources / META-INF обычно содержит файлы .properties, в то время как в jar содержится сгенерированный файл MANIFEST.MF , pom.properties , pom.xml и другие файлы. Также фреймворки, такие как Spring, используют classpath:/META-INF/resources/для обслуживания веб-ресурсов. Для получения дополнительной информации см.Как добавить ресурсы в мой проект Maven .

Просто добавьте к информации здесь, в случае файла WAR, файл META-INF / MANIFEST.MF предоставляет разработчику возможность инициировать проверку времени развертывания контейнером, которая гарантирует, что контейнер может найти все классы вашего приложения. зависит от. Это гарантирует, что в случае, если вы пропустили JAR, вам не нужно ждать, пока ваше приложение сработает во время выполнения, чтобы понять, что оно отсутствует.

Я недавно думал об этой проблеме. Кажется, на самом деле нет никаких ограничений на использование META-INF. Конечно, существуют определенные ограничения относительно необходимости размещения там манифеста, но, похоже, нет никаких запретов на размещение других вещей там.

Почему это так?

Дело CXF может быть законным. Вот еще одно место, где этот нестандартный рекомендуется обойти неприятную ошибку в JBoss-ws, которая препятствует проверке на стороне сервера по схеме wsdl.

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

Но на самом деле, кажется, нет никаких стандартов, никаких проблем. Обычно эти вещи очень строго определены, но по некоторым причинам, кажется, здесь нет стандартов. Странный. Кажется, что META-INF стал популярным местом для любой необходимой конфигурации, которая не может быть легко обработана другим способом.

В дополнение к информации, META-INF - это специальная папка, которая ClassLoaderотличается от других папок в банке. Элементы, вложенные в папку META-INF, не смешиваются с элементами вне нее.

Думайте об этом как о другом корне. С Enumerator<URL> ClassLoader#getSystemResources(String path)точки зрения метода и других:

Когда данный путь начинается с «META-INF», метод выполняет поиск ресурсов, которые вложены в папки META-INF всех jar-файлов в пути класса.

Когда данный путь не начинается с «META-INF», метод ищет ресурсы во всех других папках (кроме META-INF) всех jar-файлов и каталогов в пути к классам.

Если вы знаете о другом имени папки, которое getSystemResourcesметод обрабатывает специально, прокомментируйте это.

Если вы используете 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

Все ответы верны. Мета-инфо имеет много целей. Кроме того, вот пример использования контейнера Tomcat.

Перейдите в Tomcat Doc и проверьте атрибут « Стандартная реализация> copyXML ».

Описание ниже.

Установите значение true, если вы хотите, чтобы контекстный XML-дескриптор, встроенный в приложение (расположенный в /META-INF/context.xml), был скопирован в xmlBase хоста-владельца при развертывании приложения. При последующих запусках скопированный контекстный XML-дескриптор будет использоваться предпочтительнее любого контекстного XML-дескриптора, встроенного в приложение, даже если дескриптор, встроенный в приложение, является более новым. Значением флага по умолчанию является false. Обратите внимание, что если атрибут deployXML владельца хоста имеет значение false или если атрибут copyXML хоста-владельца равен true, этот атрибут не будет действовать.

У вас есть файл MANIFEST.MF в папке META-INF. Вы можете определить дополнительные или внешние зависимости, к которым у вас должен быть доступ.

Пример:

Предположим, что вы развернули свое приложение, и ваш контейнер (во время выполнения) обнаружил, что вашему приложению требуется более новая версия библиотеки, которая не находится в папке lib, в этом случае, если вы определили дополнительную более новую версию, MANIFEST.MFтогда ваше приложение будет ссылаться к зависимости оттуда (и не будет сбой).

Source: Head First JSP & Servlet