Можно ли разместить файлы конфигурации в JAR?

Question

У нас есть дебаты в моем офисе вокруг того, что может и не может идти в файле JAR. Было высказано предположение, что в бедной форме есть что-то, что не является файлом .class, попадающим в JAR. В настоящее время у нас есть некоторые конфигурации XML для Ibatis/etc, некоторые файлы свойств .. обычный. Однако есть попытка извлечь все такие файлы из JAR и поместить их в локальную файловую систему каждой машины развертывания. Звучит ли это разумно?

Answer 1

Это не кажется мне разумным. Я считаю, что конфигурация какого-либо приложения должна быть в файле jar. Такие вещи, как ORM-сопоставления, пружинная конфигурация, пользовательское пространство имен XSD, другие XSD и т. Д., Должны быть в большинстве случаев в банке. Это важная часть артефакта развертывания.

Факт, что это не файл class, не означает, что его следует вынимать из банки только потому, что его теоретически можно модифицировать, не создавая новую банку. Можете ли вы представить себе модификацию * .hbm.xml в процессе производства? для меня это звучит очень страшно.

Я думаю, что некоторые конфигурации, такие как spring xml, в большинстве случаев предназначены для лучшей организации вашего приложения и зависимостей, но не для их изменения во время исполнения на производстве.

Answer 2

Если вы вносите изменения в файл конфигурации внутри JAR (даже без изменения какой-либо строки кода Java), весь JAR необходимо перестроить и перераспределить. Звучит ли это разумно?

Answer 3

Вы хотите или ожидать, что они будут изменены без новой версии кода? Затем вам нужно извлечь их.

Если ответ на вопрос не у вас не должен извлекать их, так как это позволит поддерживать возиться с ними, не пройдя процесс освобождения. (Конечно, это также возможно, если они находятся в ЕАО, но чуть менее заманчивы.)

Update: Но поскольку вы упомянули несколько машин развертывания, есть третий вариант: выделить их и поместить их в общедоступных областях на сетевом диске. Редактируемые вручную файлы конфигурации, которые реплицируются на нескольких машинах (но должны быть идентичными), печально известны тем, что они не синхронизируются.

Answer 4

это плохая форма, чтобы иметь что-нибудь, что не является .class файла перейти в JAR

Это нонсенс. На самом деле очень форма для размещения ресурсов, таких как значки и другие файлы данных, которые пользователь использовал в коде JAR вместе с кодом. Это то, что делают методы getResource() и getResourceAsStream() для Class и ClassLoader, что делает его гораздо более надежным, чем использование путей ресурсов вручную.

Однако файлы конфигурации, возможно, другое дело. Если они предназначены для изменения во время или после развертывания, то наличие их внутри JAR-файла является довольно неудобным, и предпочтение отдается им в отдельном каталоге.

Answer 5

Инструменты ORM (такие как Hibernate или IBatis) на самом деле не должны изменяться после развертывания приложения. Итак, нет, я бы сказал, что это не имеет смысла для таких файлов.

В зависимости от ваших требований файлы конфигурации приложения могут быть размещены за пределами Jar/War, чтобы их можно было изменить без необходимости пересоздать банку. Имейте в виду, что изменение параметров приложения в производстве - это imho, плохая практика. Изменения должны быть проверены сначала в некоторых предварительных условиях.

Answer 6

Это совершенно нормально, чтобы поместить файлы без класса в файле JAR, особенно ресурсов, что потребности приложений (изображения, локализованные строки и т.д.) Зная это, вы должны решить, какой сценарий подходит вашей ситуации:

• Если конфигурация исправлена ​​и будет изменяться только при развертывании нового JAR-файла, поместите его в JAR.
• Если конфигурация должна быть изменена вручную или приложением, сохраните ее в файловой системе.

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