Как дифференцироваться между тестом и производственными свойствами в приложении?
Я решил проблему.
Это конфликт файлов JAR.
Похоже, у меня есть два JAR-файла на моем пути сборки, которые содержат один и тот же пакет и классы.
smack.jar и android_maps_lib-1.0.2
Удаление этого пакета из одного из файлов JAR решило проблему.
5 ответов
Чего вы хотите избежать, так это наличия файла конфигурации внутри EAR, проблема в том, что вы нужны разные EAR для разных сред, а также изменение файла конфигурации требует перестройки.
Скорее разверните один и тот же EAR на каждом сервере, но сконфигурируйте каждый сервер с другим ресурсом URL. Теперь добавьте ресурс URL JNDI ко всем серверам, которые вы развертываете в этой точке, в файл конфигурации для этого ресурса. Если у вас есть доступ только для чтения SVN к вашему репо, создайте файлы конфигурации в репозитории svn, или любое репо, к которому вы можете получить доступ через URL-адрес. Самое замечательное здесь то, что вся ваша конфигурация централизована и, следовательно, управлять ими легко.
Я сделал (настроив с помощью spring), так это убедился, что ресурс URL JNDI необязателен. Итак, если он есть, приложение будет его использовать, если нет - нет. Приложение запускается независимо от того, есть оно или нет. Таким образом, даже при отсутствии доступного ресурса JNDI приложение все равно будет работать (например, среда разработки).
Вы развертываете EAR? Затем поместите необходимые свойства в JNDI.
В предыдущем проекте J2EE мы делали именно это. В процессе сборки (сценарий муравья) были собраны правильные файлы конфигурации, добавлены их в определенный jar-файл, который затем был помещен в файл EAR для производственных сред, тестирования, обучения, контроля качества и т. Д.
Имя файла EAR file содержал имя целевой среды, поэтому было практически невозможно развернуть файл в неправильной среде. Если мы построим для цели 156p2 (фабрика 156, производственная среда 2), это будет частью имени файла EAR-файла, и ant будет включать config_156p2.xml. Если цель была неправильной, имя EAR-файла было бы неправильным, и в качестве последнего средства защиты обнаружил бы тот, кто его развернул.
Файл сборки должен был содержать следующее: одна цель ant для запуска сборки для каждой среды, которая установит свойство, сообщающее ant, какой файл конфигурации включать.
Единственное различие между файлами EAR тогда будет в файлах конфигурации. Все остальное было идентично. Конечно, есть вероятность, что кто-то мог записать неправильное значение в файл конфигурации для определенной среды. Однако на практике этого не происходило в течение нескольких лет, даже с некоторыми довольно молодыми разработчиками и примерно пятнадцатью целевыми средами (разные тестовые, QA, обучающие и производственные серверы в разных странах).
Я не могу сказать, лучший ли это способ, однако, что мы делаем, так это включаем клиентскую и серверную jar-файлы, в которых размещаются соответствующие свойства. Затем мы включаем эти банки в файл EAR. Поэтому в процессе сборки мы включаем соответствующие jar-файлы (QA, TEST, PROD) для среды, в которой мы выполняем развертывание.
Обратной стороной является то, что мы должны управлять тремя наборами jar-файлов среды, и команда сборки должна быть осторожна чтобы не развернуть неправильный. Фактически, однажды случилось так, что у нас была развернута банка PROD в нашей среде контроля качества, и данные контроля качества были запущены в производство… да, это отстой, и это было большим беспорядком, который нужно было очистить.
Я буду смотреть это обсуждение, потому что я часто задаюсь вопросом, как мы можем сделать этот процесс лучше / безопаснее. Отличный пост +1
У нас есть 3 папки для этой цели в наших проектах, каждая из которых содержит файлы конфигурации (имена файлов в папках одинаковы):
- personal: содержит пути для тестирования базы данных, сервера и т. Д.
- test: содержит пути к серверам, которыми поделился с моими коллегами
- production: содержит ... ну, как вы уже догадались
Когда я создаю свой проект, я добавляю подходящий профиль в сборку проекта Intellij Idea в желаемом модуле, в основном это означает, что я добавляю другую папку в структуру проекта, но поскольку имена файлов совпадают, то меняются только свойства профиля.