Comments 14
Что-то как-то слишком basic, а где про JNDI?
И я что-то не понял что это за инициализационные параметры, которые требуется менять во время работы?
Можно пример :-)
И я что-то не понял что это за инициализационные параметры, которые требуется менять во время работы?
Можно пример :-)
Про JNDI — добавлю развернутое описание после Commons Configuration :)
По поводу инициализационных — не понял откуда упоминание, что их требуется менять? Менять требуется именно настроечные параметры и разработчик должен явно указывать в комментариях/документации какие из параметров в файлах конфигурации менять на-лету можно (динамические параметры), а какие — нет (статические параметры).
К примеру динамические параметры — регулярное выражение обработчика SMS-сообщений, таймаут ожидания соединения, задержка после осуществления удаленного вызова и т.д. и т.п.
И статические параметры — IP и порт на которых будет слушать приложение, директория для сохранения кэша/дампов, параметры подключения к серверу БД, ttl сообщений и т.п.
Чаще всего — классификация параметра на статичность/динамичность это задача разработчика. Тут все ограничивается либо применяемыми технологиями (к примеру нельзя в рантайме безболезненно пересоздать серверный сокет на другом порту), либо сутью параметра, либо ленью разработчика (например когда изменение параметра приводит не просто к установке нового значения во внутренние компоненты, но и интеллектуальной переконфигурации их с выжиданиями и прочим. В этом случае разработчику бывает проще объявить параметр статическим).
По поводу инициализационных — не понял откуда упоминание, что их требуется менять? Менять требуется именно настроечные параметры и разработчик должен явно указывать в комментариях/документации какие из параметров в файлах конфигурации менять на-лету можно (динамические параметры), а какие — нет (статические параметры).
К примеру динамические параметры — регулярное выражение обработчика SMS-сообщений, таймаут ожидания соединения, задержка после осуществления удаленного вызова и т.д. и т.п.
И статические параметры — IP и порт на которых будет слушать приложение, директория для сохранения кэша/дампов, параметры подключения к серверу БД, ttl сообщений и т.п.
Чаще всего — классификация параметра на статичность/динамичность это задача разработчика. Тут все ограничивается либо применяемыми технологиями (к примеру нельзя в рантайме безболезненно пересоздать серверный сокет на другом порту), либо сутью параметра, либо ленью разработчика (например когда изменение параметра приводит не просто к установке нового значения во внутренние компоненты, но и интеллектуальной переконфигурации их с выжиданиями и прочим. В этом случае разработчику бывает проще объявить параметр статическим).
UFO just landed and posted this here
Кстати, я бы даже сказал, что как-раз конфигурирование посредством Preferences (а не Properties) и является тем самым «классическим вариантом конфигурирования» для J2SE-приложений.
К слову, в Linux user-root == "~/.java/.userPrefs", что особенно удобно для надежного хранения пользовательских настроек для каждого конкретного приложения (при условии, конечно, что "/home" — отдельный раздел, не форматирующийся даже при переустановке/смене Linux-дистрибутива).
К слову, в Linux user-root == "~/.java/.userPrefs", что особенно удобно для надежного хранения пользовательских настроек для каждого конкретного приложения (при условии, конечно, что "/home" — отдельный раздел, не форматирующийся даже при переустановке/смене Linux-дистрибутива).
Спасибо за наводку, позже добавлю в статью.
По правде говоря я этот способ подзабыл, поскольку занимаюсь в основном серверными приложениями, а там немного другая специфика. Так, например, если следовать рекомендациям ОС Debian, то файлы конфигурации приложений должны находиться в /etc/default, а не в хомяке пользователя.
Но для клиентских приложений вариант с Preferences будет конечно предпочтительнее.
По правде говоря я этот способ подзабыл, поскольку занимаюсь в основном серверными приложениями, а там немного другая специфика. Так, например, если следовать рекомендациям ОС Debian, то файлы конфигурации приложений должны находиться в /etc/default, а не в хомяке пользователя.
Но для клиентских приложений вариант с Preferences будет конечно предпочтительнее.
Почему вы не написали про System.getenv()?
Вы считаете, что хранение конфигурационных параметров приложения будет уместно держать в системных переменных? Даже если их, например, 300 штук?
System.getenv, на мой взгляд, больше подходит для хранения глобальных переменных — что-то вроде MY_APP_SERVER_HOME с последующим использованием в скриптах запуска.
System.getenv, на мой взгляд, больше подходит для хранения глобальных переменных — что-то вроде MY_APP_SERVER_HOME с последующим использованием в скриптах запуска.
Настройки, которые нужно менять на горячую, храним в базе, а системные в проперти файлах.
Проблема действительно есть. Вы только не забудьте про кластеры в своей статье «как надо». А то вот есть у меня десяток stateless серверов и надо их все перенаправить на новый кластер БД. Пока перенаправление включает в себя перезапуск приложений по очереди.
За что ценю Хабр, так это за аналитическое изложение материала. Спасибо, как раз пытался найти стандартные способы задания настроек!
Жаль что не упомянули OSGi. Эта «экосистема» имеет на сегодняшний день наиболее продуманные и удобные инструменты конфигурации по сравнению с Java SE и Java EE.
Назвать хотя-бы Configuration Admin Service и Fragments.
Назвать хотя-бы Configuration Admin Service и Fragments.
В конфигурировании приложений нередко встает задача в различном наборе значений свойств для разных окружений (PROD, TEST, UAT, DEV, ...). Так же бывыает удобно когда есть возможность поменять какое-либо свойство для конкретного пользователя или комьпютера\приложения в кластере. К сожалению, я пока еще не встретил ни одного более-менее удобного открытого конфигурационного туда для этой цели (но видел уже как минимум два тула, которые были написаны внутри разных компаний для этой цели). Тот же Commons Configuration как-то уж мало что может предложить. Если будете о нем писать, упомяните и этот аспект.
Sign up to leave a comment.
Конфигурирование J2SE и J2EE приложений: стандартные способы и их альтернативы