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

Question

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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