Java - Установка атрибутов контекста (ServletContextListener)
Я прочитал файл свойств на этапе запуска веб-приложения (contextInitialized ()) и начал думать о том, как сделать эти настройки «видимыми» для сервлетов. Нужно ли мне перебирать ключи и добавлять все до единого в контекст, как это
Iterator i = settings.keySet().iterator();
while (i.hasNext()) {
key = (String) i.next();
value = (String) settings.get(key);
context.setAttribute(key, value);
}
или есть методы получше?
Спасибо!
/Адам
Ответы 5
Вы рассматривали возможность определения настроек в web.xml?
Кроме того, если это невозможно, по возможности используйте дженерики:
String key = null;
Iterator<String> i = settings.keySet().iterator();
while (i.hasNext())
context.setAttribute(key = i.next(), settings.get(key));
Хм. Ну, для одного я бы использовал дженерики, предполагая, что у вас 1.5+ (или это 1.4+, я забыл). Поскольку реализация ServletContextListener предназначена для каждого поставщика сервера, я думаю, что у вас все в порядке.
А как насчет использования контекста JNDI. JNDI - более распространенный способ передачи свойств в веб-приложение.
Любые свойства могут быть указаны в файле META-INF / context.xml для tomcat или любой настройки конкретного приложения.
почему бы не сохранить все содержимое в контексте вашего сервлета?
context.setAttribute("mySettings", settings);
Подпись setAttribute:
public void setAttribute(String name, Object object)
Это то, что я задумал, установив весь объект свойств в качестве атрибута контекста.
Если я не пойду по этому пути, есть ли какие-нибудь рекомендации, как назвать эти атрибуты, или вам кажется, что это «application.settings» или «myBlog.settings»? Как группировать ключи ты? Было бы хорошо:
application.module1.color=black
application.module1.font=arial
Мне кажется, что поддержка такого приложения, в котором ключи свойств распределены по всему коду, может стать обузой? Если другой разработчик переименует свойство в файле свойств, мы узнаем, только когда Бег приложение (если / когда / что ссылалось на старый ключ). Верно?
Мне нужно будет найти JNDI.
Я раздумывал над идеей:
В методе, инициализированном контекстом, я планировал создать только один глобальный объект для настроек. Очень похоже на предложенный инструментарий. Но вместо того, чтобы устанавливать атрибуты контекста для каждого ключа / атрибута / параметра, было бы ужасной идеей добавить объект-контейнер / оболочку настроек? Я думаю, этот класс будет отвечать за хранение (статических?) Классов настроек модуля. Таким образом, я могу получить такие типизированные ссылки
//ExampleServlet.java
Settings settings = (Settings)context.getAttribute("application.settings");
String color = settings.getModule1().getColor();
String font = settings.getModule1().getFont();
int blogs = settings.getModule2().getActiveBlogCount();
На протяжении всего кода мне нужно будет помнить только ключ атрибута один, который предназначен для всего контейнера настроек. Снижение риска опечаток, которые могут вызвать исключения из режима Rumtime! Это также упростит переименование атрибутов.
Что вы думаете?
/Адам
Я подумал, но решил сохранить конфигурацию в отдельном файле. Не знаю, но думаю, так удобнее.