Вопрос

Я отсеиваю все жестко закодированные значения в библиотеке Java и задаюсь вопросом, какая платформа будет лучшей (с точки зрения нулевой или близкой к нулю конфигурации) для обработки конфигурации во время выполнения?Я бы предпочел файлы конфигурации на основе XML, но это не обязательно.

Пожалуйста, отвечайте только в том случае, если у вас есть практический опыт работы с фреймворком.Я не ищу примеры, а опыт...

Это было полезно?

Решение

Если ваши жестко закодированные значения представляют собой простые пары ключ-значение, вам следует посмотреть java.util.Свойства.Это намного проще, чем xml, проще в использовании и невероятно тривиально в реализации.

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

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

Конечно, это имеет огромное преимущество: не требуется использовать какие-либо сторонние библиотеки.

Другие советы

Конфигурация Apache Commons прекрасно работает.Он поддерживает хранение конфигурации в широком диапазоне форматов на серверной стороне, включая свойства, XML, JNDI и т. д.Его легко использовать и расширять.Чтобы получить максимальную гибкость, используйте фабрика чтобы получить конфигурацию и просто использовать Интерфейс конфигурации после этого.

Две особенности конфигурации Commons, которые отличают ее от обычного файла свойств, заключаются в том, что она поддерживает автоматическое преобразование в общие типы (int, float, String arrays) и поддерживает подстановку свойств:

server.host=myHost
server.url=http://${server.host}/somePath

Вот различные варианты:

Возможно, вы захотите прочитать Сравнение конфигурации Commons с Jfig и JConfig и Настройка ваших приложений с помощью Jfig для получения отзывов от различных пользователей.

Лично я использовал jConfig, и это был хороший опыт.

Общая конфигурация

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

Если вы не делаете ничего сложного, я бы придерживался файлов свойств.

Если вы хотите сделать что-то продвинутое (и типобезопасное), возможно, вам стоит взглянуть на это: http://www.ibm.com/developerworks/java/library/j-configint/index.html

инструмент интеллектуального использования параметров (Вход, страница) позволяет экспортируйте практически любое (жестко закодированное) решение в качестве параметра в файл конфигурации на основе XML. Он был инициирован в начале 2012 года в ответ на очевидные недостатки существующих инструментов настройки в отношении общности и разделения задач.

InPUT, вероятно, более мощный, чем требуется в большинстве случаев использования, поскольку он позволяет независимая от языка программирования формулировка экспериментальных данных (вход-выход), с такими функциями, как определение сложный дескриптор для сопоставлений классов, или создание и проверка рандомизированной конфигурации на основе предопределенных диапазонов значений (для тестирования и исследований, напримерМоделирование Монте-Карло).Ты можешь определить параметры с помощью подпараметров, относительные ограничения на значения параметров (числовой параметр a > параметр b) и т. д..

Он все еще находится в стадии бета-тестирования, но довольно стабилен, я использую его для своих исследований, для конфигурация и документирование экспериментов, а также в учебных целях.Как только он станет доступен для других языков (адаптер C++ в канале), другие исследователи/практики смогут повторно использовать дескрипторы, выполняя свои реализации тех же алгоритмов на C++ (используя концепцию отображения кода).Сюда, результаты экспериментов можно проверить/программы можно легче переносить.Документация все еще находится в работе, но пара примеры доступны на странице.Вход Открытый исходный код программное обеспечение.

Для интересующихся, Концептуальный исследовательский документ.

Я склонен использовать java.util.Properties (или аналогичные классы на других языках и платформах) завернутый в класс конфигурации конкретного приложения большую часть времени, но меня очень интересуют альтернативы или вариации на этот счет.Тем более, что все может стать немного сложнее, если задействованы графические диалоговые окна конфигурации или несколько представлений данных конфигурации.

К сожалению, у меня нет опыта работы с конкретными библиотеками для Java (кроме тех, которые я написал сам), но буду признателен за любые указания.

Обновлять

ХОРОШО.Это было не совсем так, три — это Проект конфигурации Spring Java.

я написал об этом пару недель назад и пришел к выводу, что XML — одна из наиболее широко используемых нотаций.

Это лучшее?Я так не думаю, мне очень нравится JSON, но инструменты все еще не соответствуют XML, так что, думаю, нам придется подождать и посмотреть.

Можешь попробовать YamlBeans.Таким образом, вы пишете любые классы, в которых хотите хранить данные конфигурации, а затем можете автоматически записывать и читать их в YAML и обратно.

YAML — это формат данных, читаемый человеком.Он обладает большей выразительной силой, чем java.util.Properties.У вас могут быть списки, карты, привязки, типизированные данные и т. д.

Пожалуйста, взгляните на этот URL: http://issues.apache.org/jira/browse/CONFIGURATION-394

Платформа конфигурации, которую мы ищем, является чем-то поверх конфигурации Apache Commons и должна поддерживать проблемы параллелизма, проблемы JMX и большинство хранилищ (например, файл .properties, файлы .xml или PreferencesAPI).

Интересно то, что команда weblogic предоставляет в «Консоли администрирования», с помощью которой вы можете получать транзакционные (атомарные) обновления конфигураций, чтобы получать уведомления зарегистрированных слушателей.

Ребята из Apache настаивают, что этот проект, возможно, выходит за рамки Commons Configuration!

Я приложил простую структуру конфигурации, посмотрите, пожалуйста.

Я просто опубликовал немного код об использовании Spring ClassPathResource в качестве альтернативы IoC.ClassPathResource позволяет размещать файлы свойств в любом месте пути к классам (например, все в одном месте или как одноранговые элементы кода, который они настраивают.В моем примере используется только java.util.Properties, поэтому вы можете использовать стиль открытого текста «имя=значение» или его формат XML.

Файлы свойств очень просты: если вам нужно что-то более функциональное, вы можете отформатировать некоторые файлы конфигурации как классы Java.Их можно поместить в другой пакет/модуль и предварительно скомпилировать или загрузить во время выполнения с помощью такой библиотеки, как BeanShell.

Примечание:В самом простом случае (предварительно скомпилированном) вам не нужны дополнительные библиотеки.

Что касается предложений по использованию java.util.Properties - начиная с jdk 1.5, Preferences API (java.util.prefs), по-видимому, является предпочтительной альтернативой использованию Properties API.

Причины:повышенная масштабируемость, нейтральность серверной части и т. д.

Вы можете взглянуть на недавно анонсированные инструменты4j-конфигурация чья миссия состоит в том, чтобы позволить вам легко управлять конфигурацией во время выполнения.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top