Какова цель META-INF?
Ответы 12
Из официальная спецификация файла JAR (ссылка идет на версию Java 7, но текст не изменился по крайней мере с v1.3):
The META-INF directory
The following files/directories in the META-INF directory are recognized and interpreted by the Java 2 Platform to configure applications, extensions, class loaders and services:
MANIFEST.MFThe manifest file that is used to define extension and package related data.
INDEX.LISTThis file is generated by the new "
-i" option of the jar tool, which contains location information for packages defined in an application or extension. It is part of the JarIndex implementation and used by class loaders to speed up their class loading process.
x.SFThe signature file for the JAR file. 'x' stands for the base file name.
x.DSAThe signature block file associated with the signature file with the same base file name. This file stores the digital signature of the corresponding signature file.
services/This directory stores all the service provider configuration files.
TLD также должны входить в META-INF.
@erickson, проработанный?
Дескрипторы библиотеки тегов @Pacerier для библиотек тегов JSP должны находиться в каталоге META-INF. Я забыл, что означал TLD еще в 2008 году.
Папка META-INF является домом для файла МАНИФЕСТ.MF. Этот файл содержит метаданные о содержимом JAR. Например, есть запись с именем Main-Class, которая определяет имя класса Java со статической функцией main () для исполняемых файлов JAR.
Вообще говоря, вы не должны ничего помещать в META-INF самостоятельно. Вместо этого вам следует полагаться на то, что вы используете для упаковки JAR. Я думаю, что это одна из областей, в которой Ant действительно выделяется: определение атрибутов манифеста файла JAR. Очень просто сказать что-то вроде:
<jar ...>
<manifest>
<attribute name = "Main-Class" value = "MyApplication"/>
</manifest>
</jar>
По крайней мере, я думаю, что это просто ... :-)
Дело в том, что META-INF следует рассматривать как внутренний каталог Java мета. Не связывайся с этим! Любые файлы, которые вы хотите включить в свой JAR, должны быть помещены в какой-либо другой подкаталог или в корень самого JAR.
А как насчет услуг? Дескрипторы библиотеки тегов? Помещать что-то в корень JAR - плохая идея. При отсутствии четкого соглашения ресурсы в корне слишком вероятно столкнутся.
Если вы используете JPA, вы должны поместить в эту папку файл persistence.xml, этого не происходит автоматически.
Это был бы хороший ответ, за исключением того, что в простом приложении Spring MVC META-INF - единственный каталог, в котором файлы конфигурации могут ссылаться как модульными тестами, так и контроллерами. Если бы другой каталог работал, это было бы здорово - это не так (по крайней мере, прямо). Для меня создание файла Jar только для тестирования файла войны похоже на создание машины, чтобы вы могли пройти на кухню. По крайней мере, мне. Но я потратил некоторое время на Ruby, и они, возможно, испортили меня в том, что касается файлов конфигурации (хотя я променяю небольшой ад XML на знание типов моих параметров). :)
Можете ли вы привести пример того, какие типы файлов должны содержать эту папку?
Это не отвечает на вопрос, что такое META-INF. Если бы у меня был ответ на этот вопрос, то, возможно, я мог бы решить, следует ли самому помещать что-то в эту папку «никогда».
Я заметил, что некоторые библиотеки 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. Но, похоже, это новый стандарт де-факто; либо это, либо возникающий антипаттерн :-)
Configuraton не принадлежит библиотеке. Я думаю, вы добились этого с помощью «возникающего антипаттерна». На самом деле довольно легко найти файлы конфигурации относительно библиотеки; им не нужно физически помещаться в один и тот же JAR, чтобы их можно было найти.
Я не согласен с утверждением, что конфигурация не принадлежит библиотеке. Я думаю, что конфигурация, особенно когда дело доходит до значений по умолчанию, прекрасно упакована в библиотеке. На самом деле я рад, что больше фреймворков решили работать именно так, вместо того, чтобы заставлять вас включать всевозможные внешние файлы конфигурации, как это было распространено не так давно.
Я также видел много файлов типа LICENSE.TXT, отображаемых в META_INF, что меня раздражало.
@Eelco, Код и данные должны смешивать нет. Включение внешних файлов конфигурации не обязательно означает беспорядок с удобством использования. Это зависит от того, как он устроен.
Утверждать @Pacerier - довольно произвольная вещь. Как правило, это во многом предпочтение.
Просто чтобы добавить к информации здесь, в случае файла WAR файл META-INF / MANIFEST.MF предоставляет разработчику возможность инициировать проверку времени развертывания контейнером, которая гарантирует, что контейнер может найти все классы вашего приложения. зависит от. Это гарантирует, что в случае, если вы пропустили JAR, вам не придется ждать, пока ваше приложение выйдет из строя во время выполнения, чтобы понять, что он отсутствует.
Если вы используете 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
Я недавно думал об этом. На самом деле, похоже, нет никаких ограничений на использование META-INF. Конечно, существуют определенные ограничения в отношении необходимости размещения манифеста, но, похоже, нет никаких запретов на размещение там других материалов.
Почему это так?
Случай cxf может быть законным. Вот еще одно место, где рекомендуется использовать этот нестандартный вариант, чтобы обойти неприятную ошибку в JBoss-ws, которая препятствует проверке на стороне сервера по схеме wsdl.
http://community.jboss.org/message/570377#570377
Но на самом деле, похоже, нет никаких стандартов, никаких запретов. Обычно эти вещи очень строго определены, но почему-то кажется, что здесь нет стандартов. Странный. Похоже, что META-INF стал универсальным местом для любой необходимой конфигурации, которую нелегко обработать каким-либо другим способом.
Вы также можете разместить там статические ресурсы.
Например:
META-INF/resources/button.jpg
и получить их в web3.0-контейнере через
http://localhost/myapp/button.jpg
/META-INF/MANIFEST.MF имеет особое значение:
- Если вы запускаете jar с использованием
java -jar myjar.jar org.myserver.MyMainClass, вы можете переместить определение основного класса в jar, чтобы вы могли сжать вызов вjava -jar myjar.jar. - Вы можете определять метаинформации для пакетов, если используете
java.lang.Package.getPackage("org.myserver").getImplementationTitle(). - Вы можете ссылаться на цифровые сертификаты, которые хотите использовать в режиме апплета / веб-запуска.
Таким образом, любые статические элементы в приложении должны быть помещены в этот каталог, например изображения или другие материалы.
META-INF в Maven
В Maven папка МЕТА-ИНФ понимается из-за Стандартный макет каталога, который по соглашению об именах упаковывает ресурсы вашего проекта в JAR: любые каталоги или файлы, помещенные в каталог $ {basedir} / src / main / resources, упаковываются в ваш JAR с точно такой же структурой, начиная с основания JAR. Папка $ {basedir} / src / main / resources / META-INF обычно содержит файлы .характеристики, в то время как в банке содержатся сгенерированные МАНИФЕСТ.MF, pom.properties, pom.xml среди других файлов. Также такие фреймворки, как Spring, используют classpath:/META-INF/resources/ для обслуживания веб-ресурсов. Для получения дополнительной информации см. Как мне добавить ресурсы в мой проект Maven.
Все ответы верны. Мета-инф имеет множество целей. Кроме того, вот пример использования контейнера tomcat.
Идти к Tomcat Doc и проверьте Атрибут "Стандартная реализация> copyXML".
Описание ниже.
Set to true if you want a context XML descriptor embedded inside the application (located at /META-INF/context.xml) to be copied to the owning Host's xmlBase when the application is deployed. On subsequent starts, the copied context XML descriptor will be used in preference to any context XML descriptor embedded inside the application even if the descriptor embedded inside the application is more recent. The flag's value defaults to false. Note if the deployXML attribute of the owning Host is false or if the copyXML attribute of the owning Host is true, this attribute will have no effect.
У вас есть файл MANIFEST.MF внутри вашей папки META-INF. Вы можете определить необязательные или внешние зависимости, к которому у вас должен быть доступ.
Пример:
Предположим, вы развернули свое приложение, и ваш контейнер (во время выполнения) обнаружил, что вашему приложению требуется более новая версия библиотеки, которая не находится внутри папки lib, в этом случае, если вы определили необязательную более новую версию в MANIFEST.MF, ваше приложение будет обратитесь к зависимости оттуда (и не произойдет сбой).
Source: Head First Jsp и сервлет
Непонятно, сколько из этого цитируется из источника, и это не выглядит дословно. Удалено странное форматирование. Не используйте форматирование кода для текста, не являющегося кодом. Используйте форматирование кавычек для текста, который цитируется.
В дополнение к информации здесь, META-INF - это специальная папка, которую ClassLoader обрабатывает иначе, чем другие папки в банке.
Элементы, вложенные в папку META-INF, не смешиваются с элементами вне ее.
Думайте об этом как о другом корне. С точки зрения метода Enumerator<URL> ClassLoader#getSystemResources(String path) и др.:
Когда указанный путь начинается с «META-INF», метод ищет ресурсы, вложенные в папки META-INF всех jar-файлов в пути к классам.
Если указанный путь не начинается с «META-INF», метод ищет ресурсы во всех других папках (за пределами META-INF) всех jar-файлов и каталогов в пути к классам.
Если вам известно о другом имени папки, которое метод getSystemResources обрабатывает особым образом, прокомментируйте его.