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

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

каталог META-INF

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

• MANIFEST.MF

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

• INDEX.LIST

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

• x.SF

файл подписи для файла JAR. "x" означает имя базового файла.

• x.DSA

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

• services/

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

Я заметил, что некоторые библиотеки Java начали использовать META-INF в качестве каталога для включения файлов конфигурации, которые должны быть упакованы и включены в путь к классам вместе с JARs. Например, 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/resources/button.jpg 

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

http://localhost/myapp/button.jpg

> подробнее

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

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

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

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

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

Почему это произошло?

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

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

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

Если вы используете JPA1, вам может потребоваться удалить persistence.xml файл, в котором указано имя единицы сохранения, которую вы можете использовать. Блок персистентности обеспечивает удобный способ указания набора файлов метаданных, классов и банок, содержащих все классы, которые должны сохраняться в группе.

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

// ...

EntityManagerFactory emf =
      Persistence.createEntityManagerFactory(persistenceUnitName);

подробнее здесь: http://www.datanucleus.org/products/datanucleus/jpa/emf.html

META-INF в Maven

в Maven META-INF папка понимается из-за Стандартный Макет Каталога который по имени конвенции пакет ресурсов проекта в JARs: любые каталоги или файлы, размещенные в ${basedir} / src/main / resources каталог упаковываются в банку с точно такой же структурой, начиная с основания банки. Папка ${basedir} / src/main/ресурсы / META-INF обычно содержит .свойства файлы, в то время как в баночке содержится сгенерированный манифест.MF, пом.свойства, the пом.в XML, среди других файлов. Также фреймворки, такие как Весна использовать classpath:/META-INF/resources/ для обслуживания веб-ресурсов. Дополнительные сведения см. В разделе как добавить ресурсы в мой проект Maven

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

думайте об этом как о другом корне. От Enumerator<URL> ClassLoader#getSystemResources(String path) метод и др. перспектива:

когда данный путь начинается с "META-INF", метод ищет ресурсы, которые вложены внутри папок META-INF всех jars в путь к классу.

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

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

все ответы верны. Meta-inf имеет много целей. Кроме того, вот пример использования контейнера tomcat.

перейти к Tomcat Doc и проверить "стандартная реализация > copyXML атрибут".

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

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

У вас есть манифест.MF-файл внутри вашей папки META-INF. Ты можешь!--3-->определить необязательные или внешние зависимости к которому у вас должен быть доступ.

пример:

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

Source: Первый JSP & Servlet