разные файлы конфигурации для другого сервера - PullRequest
1 голос
/ 16 июля 2009

Привет. Как бы ты решил это?

У меня есть одно приложение, в котором у меня есть несколько файлов конфигурации, я создаю файл war и развертываю его на Tomcat.

Но в то же время мне нужно создать файл war и развернуть одно и то же приложение в другом контексте и / или на сервере с измененными файлами конфигурации.

Я могу создать свое собственное задание в муравье и заменить необходимые параметры, но может быть возможность перейти в maven, и в любом случае я не уверен в этом. Или я могу использовать что-то вроде конфигуратора заполнителя свойства Spring или jgroups

Ответы [ 4 ]

1 голос
/ 16 июля 2009

Spring может справиться с этим довольно различными способами. Подход, который я нашел наиболее полезным и гибким, заключается в установке в каждой среде системной переменной, которая задает имя среды, например test, dev, int, prod и т. д.

Затем Spring может использовать эту системную переменную для загрузки правильных файлов свойств. В зависимости от ваших потребностей эти файлы свойств могут быть связаны с приложением или загружены из внешнего источника. Вот пример подобного подхода здесь:

http://www.developer.com/java/ent/print.php/3811931

0 голосов
/ 20 декабря 2010

http://www.gifnoc.com/config может помочь, поскольку он хранит конфигурацию в центральном месте, и клиент использует ее для различных сред

0 голосов
/ 17 июля 2009

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

Project
\
 -Properties
 \
  -Local (your PC)
  -Dev (shared dev server)
  -Test (pre-production)
  -Prod (Production)

В каждую папку мы помещаем параллельные копии файлов свойств / конфигурации и помещаем различные конфигурации только в файл в соответствующей папке. Секрет заключался в том, чтобы контролировать путь к классам среды развертывания. Мы определили запись пути к классу PROPERTIES на каждом сервере. В Prod для него будет задано значение «$ ProjectDir / Properties / Prod», а в «Тесте» для этой же переменной будет установлено значение «$ ProjectDir / Properties / Test».

Таким образом, мы могли бы иметь предварительно настроенные строки соединения с базой данных для базы данных dev / test / prod и не должны извлекать / в файле свойств каждый раз, когда мы хотели построить для другой среды.

Это также означало, что мы можем развернуть точно такой же файл .war / .ear в Test и Prod без перекомпоновки. Любые свойства, которые не были объявлены в файле свойств, мы обрабатывали аналогичным образом, используя одно и то же имя JNDI в каждой среде, но используя значения, характерные для этой среды.

0 голосов
/ 17 июля 2009

Я бы развернул приложения Spring, упакованные как WAR, в Tomcat или WebLogic без каких-либо изменений. Он будет содержать как META-INF / context.xml для Tomcat, так и weblogic.xml для WebLogic. Не беспокойтесь, никаких изменений.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...