изменить файл config.properties в файле jar / war во время выполнения и выполнить горячее развертывание изменений? - PullRequest
Новая
       20

изменить файл config.properties в файле jar / war во время выполнения и выполнить горячее развертывание изменений?

2 голосов
/ 24 июля 2009

изменить файл config.properties в файле jar / war во время выполнения и выполнить горячее развертывание изменений? Мое требование заключается в следующем: у нас есть файл «config.properties» в файле jar / war, я должен открыть файл через веб-страницу, и после того, как пользователь внес в него необходимые изменения, я должен обновить конфигурацию. Свойства "в файле JAR / War и разверните его. мы можем достичь этого подвига? если да, можете ли вы указать мне соответствующие сайты / документы, чтобы я мог начать с этого.

Ответы [ 3 ]

4 голосов
/ 24 июля 2009

Я настоятельно рекомендую вашему архитектору переосмыслить это решение. То, что вы описываете, должно быть сделано с помощью JNDI или аналогичного метода, а не с помощью перезагрузки свойств.

Развертывания следует рассматривать как статические - от любого данного веб-контейнера, допускающего магический трюк, не следует зависеть, и он сломается однажды (скорее всего, в самое неудобное время).

1 голос
/ 14 сентября 2010

Даже если я согласен с комментариями, объясненными ранее, я мог бы предложить одно решение:

Расширение конфигурации Apache Commons дает вам возможность сделать что-то вроде: 

config.setReloadingStrategy(new FileChangedReloadingStrategy());

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

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

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

У вас есть пара проблем на макушке:

  1. , гарантирующих, что ничто не удерживает static ссылки на java.util.Properties, который ранее загружал вашу *Файл 1007 *.

  2. большинство движков сервлетов распакует вашу войну в рабочий каталог, поэтому загружаемый вами файл свойств не будет тем, что на войне,будет распакованным. Это означает, что ваши изменения будут перезаписаны при перезапуске движка сервлета , потому что это, как правило, одна из точек распаковки войны.

Хотя эти проблемы не являются непреодолимыми, я всегда находил, что гораздо проще реализовать такого рода поведение, сохраняя свойства в JNDI (как предлагает Торбьерн) или в базе данных (в то время какосторожно относитесь к статическим ссылкам, которые я упомянул в пункте 1).

Решение JNDI / базы данных имеет приятный побочный эффект, заключающийся в упрощении развертывания в нескольких средах, поскольку каждая из них обычно имеет свой собственный реестр / базу данных.

...