Я нахожусь в процессе отсеивания всех жестко запрограммированных значений в библиотеке Java, и мне было интересно, какая структура будет лучшей (с точки зрения нулевой или близкой к нулю конфигурации) для обработки конфигурации во время выполнения? Я бы предпочел файлы конфигурации на основе XML, но это не важно.
Пожалуйста, отвечайте только в том случае, если у вас есть практический опыт работы с фреймворком. Я не ищу примеров, а опыта ...
Если ваши жестко запрограммированные значения представляют собой простые пары "ключ-значение", вам следует посмотреть java.util.Properties. Это намного проще, чем xml, проще в использовании и невероятно тривиально в реализации.
Если вы работаете с Java и данные, которые вы храните или извлекаете с диска, моделируются как пара значений ключа (что, похоже, так и есть в вашем случае), то я действительно не могу представить лучшего решения.
Я использовал файлы свойств для простой настройки небольших пакетов в более крупном проекте и в качестве более глобальной конфигурации для всего проекта, и у меня никогда не было проблем с этим.
Конечно, это имеет огромное преимущество, так как не требует использования каких-либо сторонних библиотек.
Конфигурация Apache Commons отлично работает. Он поддерживает хранение конфигурации в широком диапазоне форматов на сервере, включая свойства, XML, JNDI и т. Д. Его легко использовать и расширять. Чтобы получить максимальную гибкость, используйте factory для получения конфигурации и просто используйте Интерфейс конфигурации после этого.
Две особенности Commons Configuration, которые отличают его от обычного файла свойств, заключаются в том, что он поддерживает автоматическое преобразование в общие типы (int, float, String) и поддерживает подстановку свойств:
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
Инструмент интеллектуального использования параметров (InPUT, страница) позволяет экстернализовать практически любые (жестко запрограммированные ) решение в качестве параметра в файле конфигурации на основе XML. Он был инициирован в начале 2012 года как ответ на предполагаемые недостатки существующих инструментов конфигурации в отношении общности и разделения проблем.
InPUT, вероятно, более мощный, чем требуется для большинства случаев использования, поскольку он позволяет производить независимую от языка программирования формулировку экспериментальных данных (ввод-вывод) с такими функциями, как определение сложного дескриптора для класса сопоставления или рандомизированное создание и проверка конфигурации на основе предопределенных диапазонов значений (для тестирования и исследования, например, моделирования Монте-Карло). Вы можете определить параметры с помощью дополнительных параметров, относительные ограничения на значения параметров (числовой параметр a> параметр b) и т. Д.
Он все еще находится в стадии бета-тестирования, но довольно стабилен, я использую его для своих исследований, для настройки и документирования экспериментов, а также в учебных целях. Как только он станет доступен для других языков (адаптер C ++ в конвейере), другие исследователи / практики могут повторно использовать дескрипторы, выполняющие свои реализации тех же алгоритмов на C ++ (используя концепцию отображения кода). Таким образом можно будет проверить экспериментальные результаты / упростить перенос программ. Документация все еще находится в разработке, но пара примеров доступна на странице. InPUT - это программа с открытым исходным кодом.
Для заинтересованных: Концептуальный исследовательский документ.
Я обычно использую java.util.Properties (или аналогичные классы на других языках и фреймворках) большую часть времени заключен в класс конфигурации для конкретного приложения, но меня очень интересуют альтернативы или варианты этого. Тем более, что все может стать немного сложнее, если задействованы графические диалоговые окна конфигурации или несколько представлений данных конфигурации.
К сожалению, у меня нет опыта работы с конкретными библиотеками для Java (за исключением тех, которые я написал сам), но любые указатели будут признательны.
Обновить
В ПОРЯДКЕ. Это не совсем так, три - это Spring Java Configuration Project.
Я писал об этом пару недель назад и пришел к выводу что 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, поэтому вы можете использовать стиль открытого текста "name = value" или его формат XML.
Файлы свойств очень просты, если вам нужно что-то более функциональное, вы можете отформатировать некоторые из ваших файлов конфигурации как классы Java. Они могут быть помещены в другой пакет / модуль и могут быть предварительно скомпилированы или загружены во время выполнения с помощью такой библиотеки, как BeanShell.
Примечание: в простейшем случае (предварительно скомпилированный) вам не нужны дополнительные библиотеки.
Что касается предложений по использованию java.util.Properties - начиная с jdk 1.5, предпочтительной альтернативой использованию API свойств является Preferences API (java.util.prefs).
Причины: повышенная масштабируемость, нейтралитет серверной части и т. Д.
Вы можете взглянуть на недавно анонсированный tools4j-config, миссия которого позволяет вам легко обрабатывать конфигурацию во время выполнения.
