Использование внешнего файла.cfg вместо определения файлов свойств во время сборки
Наш проект использует Apache Camel с FuseESB, а мы также используем Spring. Прямо сейчас у нас есть несколько файлов свойств, которые мы определяем при создании проекта (с Maven).
Мы хотим переместить файлы свойств во внешний файл, который будет в каждой системе (dev/qa/prod), и использовать его в качестве файла свойств.
Я пытаюсь понять, как я собираюсь это сделать. Конечно, есть и другое, но это относится к вопросу, которому я верю. Я просматривал документацию Camel, но я все еще немного запутался, как это сделать.
Я смотрел на этот пост на вопрос, и мне показалось, что я хочу использовать этот тип конфигурации, но в моем Spring XML-файле.
Мне просто нужно общее руководство с этим, спасибо!
2 ответа
Для внешней конфигурации вы хотите посмотреть на свойства-заполнители OSGI cm;
Здесь есть некоторая информация об этом
Чтобы переопределить свойства по умолчанию, определенные в вашем блоке cm:property-placeholder, вы предоставляете внешний файл, который соответствует уникальному значению атрибута persistent-id, предоставленному вами с типом файла '.cfg'.
Если вы хотите развернуться в Караф, например; Затем этот конфиг будет сброшен в ${KARAF_HOME}/etc/yourPID.cfg
Эта возможность предоставляется как Spring DM, так и Blueprint.
Вы также можете посмотреть на настройку Fuse Fabric.
Вместо того, чтобы вручную редактировать файлы.cfg, каждый сервер (контейнер) в структуре настроен с указанным профилем. Например, myprofile-dev, myprofile-qa, myprofile-prod.
Это вставит свойства (например, foo = bar) из профиля фабрики прямо в заполнители свойств cm, и ваша конфигурация проекта будет в основном такой же, как описанная AlanFoster в его ответе.
Вот некоторая информация о профилях ткани.
Особенно, если вы используете много серверов и сред, профили фабрики могут быть хорошим способом управлять развертыванием и конфигурацией.
Обратите внимание, что я не совсем уверен, как это решает проблему "весна против чертежа". Я решил полностью отказаться от Spring и переместить все DI и bean-компоненты в проект, избегая конфликта Spring и Blueprint и оставляя конфигурацию свойств исключительно в проекте.
Я не уверен, хотите ли вы покончить с пружиной или нет - возможно, вы бы предпочли оставить ее, и в этом случае я могу предложить посмотреть раздел Bridging Spring и держатели Camel вниз к нижней части страницы по этой ссылке.: Верблюд: Использование свойства заполнителя (сам не пробовал, мммм).
Удачи!