Принятый формат для конфигурационных файлов в java
Собственно вопрос: В чем слабые стороны такого подхода по сравнению с XML конфигурацией? Что натолкнуло на поднятия темы? В одной компании, один из специалистов в авторитетной должности архитектора, намекнул что это считается плохим тоном. На вопрос Кем считается? ответ Java-сообществом. Что скажете?
Ну, какбы, код - это код, а конфигурация - это конфигурация (ака ресурсы). Вы же, например, не хардкодите логины с паролями внутрь кода
2 ответа 2
Самый главный недостаток в сравнении с xml - необходимость повторной компиляции при изменении конфигурации. А в остальном - вопрос личных предпочтений. Я люблю сочетание из аннотаций и xml.
Есть такой термин "hard code" (хардкод по нашему). Мало кто будет утверждать, что это не плохо (есть варианты, когда оно нужно, но это достаточно редкие случаи).
Вот объединение конфигурации и кода - это оно и есть.
Давай рассмотрим самое очевидное - необходимость перекомпиляции после внесения изменений в конфигурацию. Потянем за ниточку, поразматываем клубок:
- Вдруг оказалось, что для разных заказчиков нужна чуть разная конфигурация
- Понадобилось срочно подкрутить мелочь какую-то, а разработчик в отпуске
- Junior, которого попросили внести изменение из пункта 2 не знал, что где-то сбоку был захардкожен еще кусок конфигурации, который тоже надо было поменять, чтобы все не рухнуло. А там деплой с даунтаймами.
- Девелоперская ветка далеко уехала от продакшена. Прям совсем далеко. И вдруг потребовалось чуток изменить конфигурацию в боевой среде. "Ээээ. А что, у нас оно не в гите разве, а в старом SVN лежало?"
По поводу 1 пункта: для разных заказчиков и файлы разные, будь то xml либо java. Не так ли? По пункту 2: не поддерживается ли единый стиль в конфигурировании? Если все настроено в Java-классах, то и изменения будет Junior вносить в те самые Java-классы В 4 пункте не понятно, причем тут гит, svn С хардкодом и повторной компиляцией согласен, но доводы в 1-4 пунктах не очевидные, по мне
Немного поискав на хабре, я не смог найти именно того о чем хочу вам сейчас рассказать и продемонстрировать. Поэтому решил написать пост на данную тему. Речь пойдет о JavaConfig, а именно о том как сконфигурировать Spring MVC проект не используя *.xml конфигурации, например: (mvc-dispatcher-servlet.xml).
На тему Spring MVC есть неплохой материал тут и тут, но в этих примерах используются xml конфигурации. Я же хочу показать как создать структуру проекта Spring MVC используя JavaConfig.
Что же такое JavaConfig?
JavaConfig — это альтернатива привычной нам XML конфигурации, но используя не xml разметку, а синтаксис Java.
Мне нравится использовать JavaConfig, в первую очередь потому что это Java, мы видим java код, что есть удобно, во-вторых большинство ошибок в конфигурации можно отловить на момент написания конфигурации в этом вам поможет любимая IDE в моем случае это Intellij IDEA, но даже если IDE говорит что все круто, то у вас есть шанс отловить ошибку в конфигурировании на момент компиляции.
Преимущества:
1. Главное преимущество, на мой взгляд, это Java синтаксис;
2. Вы получаете все возможности IDE по отношению работы с кодом, автоматическая генирация кода, авто-подставка значений, подсказки и т.п.;
3. Больше гибкости за счет использования объектов и их методов;
4. Нет необходимости в полной сборке и деплоя проекта для того чтобы отловить неисправность в xml конфигурации. (но бывают исключения, например: NullPointerException).
JavaConfig существовала раньше как отдельный проект, но начиная со Spring Core 3.0 данный проект стал часть core проекта. Теперь для того чтобы иметь возможность писать конфигурацию используя JavaConfig достаточно использовать Spring Core 3+
Стандартная конфигурация с использованием XML
Для начало рассмотрим структуру и конфигурацию проекта Spring MVC с использованием XML конфигураций, а после уже переведем на JavaConfig.
Вот так выглядит структура проекта:
Начнем с добавления зависимостей в pom.xml:
Теперь создадим простую jsp страницу index.jsp:
И последнее, что не касается конфигурации это контроллер HelloController.java:
Теперь у нас есть все необходимое для того чтобы получить работающий Spring MVC проект, помимо конфигурации. Дальше мы рассмотрим именно её.
Обратите внимание что все детали Spring MVC проекта я не объясняю так как ране на хабра уже были посты по этому поводу.
Теперь рассмотрим как сконфигурировать проект используя XML файл. Начнем с mvc-dispatcher-servlet.xml именно этот файл будет конфигурировать наш проект, в основном тут мы описываем все наши beans.
Содержимое файла mvc-dispatcher-servlet.xml:
В данной конфигурации мы указываем, где искать все наши контроллеры, сервисы и другие компоненты с помощью тега: context:component-scan, а также инициализируем InternalResourceViewResolver, который отвечайте за показ View в нашем случае это jsp страницы.
Конфигурация на основе JavaConfig
Так как JavaConfig это простые java классы, создадим для них пакет config как показанно на рис. ниже, а также вот наша новая структура проекта уже без web.xml и mvc-dispatcher-servlet.xml.
Как видно из структуры проекта у нас появилось два класса в пакете config именно они и являются заменой xml конфигурации.
Начнем с WebConfig:
Аннотации:
Конфигурация
WebMvcConfigurerAdapter — унаследовавшись от этого класса мы получим возможность сконфигурировать ResourceLocations.
addResourceHandlers(ResourceHandlerRegistry registry) — переопределив данный метод мы сможем указать где будут лежать ресурсы нашего проекта, такие как css, image, js и другие.
InternalResourceViewResolver — аналогичная конфигурация с mvc-dispatcher-servlet.xml.
Теперь нужно зарегистрировать конфигурацию в Spring Context это нам позволит сделать наш класс AppInit:
Добавим необходимые зависимости и плагины
В pom.xml нужно добавить еще две зависимости:
А теперь нужно добавить maven-war-plugin с помощтю которого мы сможем отключить необходимость web.xml файла.
На этом все. Надеюсь данный материал был полезен.
p.s. Я не гуру, и буду рад правкам в коде.
Большинство наших приложений зависят от внешних сервисов, например серверов баз данных, SMS-шлюзов и систем наподобие PayPal. Эти сервисы могут существовать более чем в одной среде, то есть в средах разработки и эксплуатации. Если мы хотим подключиться к эксплуатационной среде, мы должны сначала пройти через среду разработки. Таким образом, во время создания приложений нам приходится переключаться между средами. Это связано с тем, что у каждой среды своя уникальная конфигурация со своими параметрами подключения и прочими значениями.
Проблема
Предположим, что мы разрабатываем платежный сервис, который подключается к внешнему платежному провайдеру. Значения коммерческого счета в эксплуатационной среде и среде разработки не совпадают. То есть при каждом переключении среды нам приходится изменять значения и компилировать код заново, а это неэффективно.
Решение
Лучшее решение этой проблемы — вывод данных конфигурации приложения во внешний источник. Нам не нужно будет каждый раз заново компилировать код при переключении среды. Мы сможем переопределить значения параметров конфигурации, затратив меньше усилий. Наше приложение Spring сможет считывать значения коммерческого счета из внешних источников, например переменных среды, аргументов командной строки и файлов свойств.
Вывод данных конфигурации во внешний источник
Источники свойств
Существуют различные способы вывода данных конфигурации приложения Spring во внешний источник. Для задания свойств приложения мы можем использовать переменные среды, файлы свойств (например, в формате YAML или с расширением *.properties) и аргументы командной строки. Мы также можем хранить файлы свойств в произвольных местах и сообщать приложению Spring, где их искать.
Файлы свойств
По умолчанию приложение Spring загружает свойства из файлов application.properties или application.yml из перечисленных ниже источников в порядке приоритета (то есть вышестоящий файл свойств переопределяет файлы из источников нижнего уровня) и добавляет их в среду:
подкаталог конфигурации текущего каталога;
пакет конфигураций в параметре classpath;
корневой каталог classpath.
По умолчанию имя файла конфигурации — application. При желании мы можем указать другое имя, используя ключ свойств среды spring.config.name . В примере ниже мы переопределили имя конфигурации Spring, заданное по умолчанию, на new_name .
Пользовательское место хранения
Мы можем задать внешний источник свойств приложения или файлов YAML с помощью свойства среды spring.config.location . Это свойство может указывать на любое пользовательское место хранения и таким образом переопределять местоположение по умолчанию. См. пример ниже:
Примечание. При указании расположения каталога необходимо убедиться, что после значения spring.config.location стоит символ / (например, spring.config.location=classpath:/config/ ) и что задано имя файла конфигурации по умолчанию. Также с помощью ключа свойств spring.config.additional-location можно указать дополнительные каталоги, поиск в которых будет проводиться перед поиском в местоположениях по умолчанию.
Spring Boot также поддерживает обобщенное указание местоположения с помощью подстановочных символов. Эта функция полезна в средах с несколькими источниками свойств конфигурации, таких как среды Kubernetes. Например, у вас есть конфигурации Redis и MySQL. Они могут храниться в разных местах, но при этом они обе должны быть указаны в файле application.properties , чтобы их видело приложение. Это может привести к тому, что два отдельных файла application.properties будут смонтированы в разных местах, например /config/redis/application.properties и /config/mysql/application.properties . В таком случае использование обобщенного указания каталога config/*/ позволит обрабатывать оба файла.
Форматы файлов
Файл свойств приложения может быть в формате YAML или иметь расширение .properties. Если эти два файла свойств будут храниться в одной и той же папке конфигурации, файл application.properties будет иметь приоритет над файлом application.yml . В следующем фрагменте кода показаны настройки коммерческого счета, определенные в файле свойств каждого типа.
application.properties
application.yml
Файлы форматов YAML и .properties
YAML — это легкочитаемый стандарт сериализации данных, часто применяемый в файлах конфигурации. Он является надмножеством формата JSON и очень удобен при составлении иерархической конфигурации. Файлы формата YAML предпочтительны, поскольку они более понятны и удобочитаемы, особенно по сравнению с файлами .properties. Помимо этого, у них есть другие очень полезные функции, например безопасность типов и т. д.
Для загрузки файла YAML приложению Spring требуется библиотека SnakeYAML в параметре classpath . В приведенном примере кода использованы стартеры Spring Boot, поэтому необходимости включать данную библиотеку в параметр classpath нет.
Множество профилей
YAML позволяет указать несколько профилей в одном файле конфигурации, тогда как при использовании файла .property нам может потребоваться файл конфигурации для каждого профиля. Рассмотрим следующий пример.
1. Файл YAML
application.yml
2. Файл .properties
В случае с файлом .properties , при определении двух профилей нужно создать отдельный файл конфигурации для каждого из них. К имени каждого файла конфигурации добавляется -.properties . В примере ниже показаны профили приложения для разработки и эксплуатации.
application-development.properties
application-production.properties
При наличии свойств, общих для профилей разработки и эксплуатации, нам может потребоваться файл application.properties, заданный по умолчанию.
application.properties
Образец данных конфигурации в приведенных выше фрагментах кода устанавливает профиль разработки в качестве активного профиля. Поэтому при запуске приложения значения свойств, определенные в этом профиле, будут иметь приоритет над эксплуатационным профилем. Но не стоит забывать, что настройки профиля можно также переопределить с помощью аргументов командной строки.
Вы можете узнать больше о профилях Spring в этой статье.
Читаемость
YAML поддерживает списки и карты в виде иерархических свойств, и по сравнению с файлом расширения .properties версия YAML более удобочитаемая. Допустим, мы хотим настроить параметры подключения для реальной и тестовой сред. Сначала зададим имена подключений в виде списка, а затем сопоставим их с соответствующими URL-адресами с помощью карты, как показано ниже. Рассмотрим, как реализация в YAML может упростить эту конфигурацию в сравнении с файлом .properties.
application.yml
application.properties
Тестовые примеры для проверки сопоставлений можно найти в тестовых пакетах с примером кода из данной статьи.
Аргументы командной строки
Когда мы вводим аргумент командной строки, приложение Spring преобразует его в свойство и добавляет в Spring Environment. С помощью этих аргументов можно сконфигурировать параметры приложения. К примеру, следующие аргументы командной строки переопределят порт сервера приложения, заданный любым другим источником свойств. При запуске приложения командой Maven или Java мы все равно получим тот же результат.
Команда Maven:
Команда JVM:
Также можно вводить несколько аргументов одновременно. Дополним приведенный выше пример еще одним свойством — портом сервера, как показано ниже.
Команда Maven (через пробел):
Команда JVM:
Переменные среды
Если у нас нет возможности изменять значения свойств через командную строку, на выручку приходят переменные среды. Приложение Spring может считывать свойства из них. При запуске оно ищет переменную среды под именем SPRING_APPLICATION_JSON , которая может содержать набор свойств JSON в одностроковом формате. Мы можем поэкспериментировать и переопределить адреса подключения, указанные в нашем файле свойств, как описано ниже.
Откроем терминал и выполним следующую команду. Она устанавливает переменные среды приложения, переопределяя настройки подключения.
После этого запустим наше приложение:
Результат
Проверив журнал, мы заметим, что адреса подключения в профиле разработки были переопределены, а значения в файле JSON, который мы передали через переменную среды, были в приоритете.
Передача свойств
Существуют различные способы передачи значений свойств в приложение из соответствующих источников. Мы можем использовать аннотацию @Value абстракции Spring Environment или привязать эти значения к структурированному объекту с аннотацией @ConfigurationProperties .
Этот метод актуален при наличии небольшого количества свойств, но он не рекомендуется, если свойств много. Представьте, если в коммерческом счете более двадцати свойств, нам придется указывать аннотацию @Value двадцать раз. Приведенный ниже фрагмент кода показывает, как можно использовать эту аннотацию для внедрения значения свойства в приложение.
Важно убедиться, что имя свойства @Value совпадает с именем, указанным в источниках свойств.
При наличии нескольких свойств мы можем сгруппировать их и сопоставить с классом POJO. Таким образом, мы получим структурированный и типобезопасный объект, который сможем внедрить в любое место в нашем приложении. Поэтому вместо использования аннотации @Value значения свойств можно получить с помощью метода чтения значения класса POJO.
Класс POJO должен иметь аннотации @ConfigurationProperties и @Component , как описано выше. Значение префикса, указанное в аннотации, должно совпадать с префиксом свойства, определенного в файле application.yml .
application.yml
Важно отметить, что аннотация @ConfigurationProperties также позволяет нам сопоставлять списки и карты, как показано ниже:
Порядок приоритета данных конфигурации
В приложении Spring Boot может быть несколько источников свойств. Поэтому важно знать, какой источник свойства имеет наивысший приоритет. Например, если конфигурация нашего приложения находится в файле application.yml и во время выполнения приложения мы решаем передать аргументы командной строки, тогда значения свойств в файле application.yml будут переопределены значениями аргументов командной строки.
В Spring Boot 2.2.x используется приведенный ниже порядок источников свойств. Источник свойств, расположенный выше в списке, имеет приоритет над источниками под ним.
Свойства глобальных настроек в папке $HOME/.config/spring-boot , когда средства разработки активны.
Аннотации @TestPropertySource в ваших тестах.
Атрибут свойств в ваших тестах. Он доступен в @SpringBootTest и тестовых аннотациях для проверки работы определенного фрагмента вашего приложения.
Аргументы командной строки.
Свойства из SPRING_APPLICATION_JSON (строковый JSON в переменной среды или системном свойстве).
Начальные параметры ServletConfig .
Начальные параметры ServletContext .
Атрибуты JNDI из java:comp/env .
Свойства Java System, то есть System.getProperties() .
Переменные среды ОС.
RandomValuePropertySource , свойства которого хранятся только в random.* .
Свойства приложения для конкретного профиля, за пределами упакованного файла .jar (application- .properties и варианты YAML).
Свойства приложения для конкретного профиля внутри файла .jar ( application- .properties и варианты YAML).
Свойства приложения за пределами упакованного файла .jar ( application.properties и варианты YAML).
Свойства приложения в файле .jar ( application.properties и варианты YAML).
Аннотации @PropertySource в классах @Configuration . Необходимо учесть, что такие источники свойств не добавляются в Environment, пока контекст приложения не будет обновлен. В этот момент уже поздно настраивать некоторые свойства, например logging.* и spring.main.*, которые считываются перед началом обновления.
Свойства по умолчанию (заданные настройкой SpringApplication.setDefaultProperties ).
Заключение
Рекомендуется выносить данные конфигурации во внешний источник. Если свойств много, мы можем сгруппировать их в простой класс Java и использовать аннотацию @ConfigurationProperties , чтобы структурировать конфигурацию и сделать ее типобезопасной. Однако самая большая проблема при использовании внешних источников свойств заключается в правильном выборе конфигурации для разворачиваемого приложения. Поэтому важно соблюдать осторожность при настройке приложения, в котором для разных сред используются разные источники свойств. Пример кода для этой статьи доступен на GitHub.
Когда мы обычно пишем программы, некоторые параметры часто меняются, и мы не предвидим это изменение. Например, мы разработали модуль, который управляет базой данных. При разработке мы подключаемся к локальной базе данных. IP, имя базы данных, имя таблицы и хост базы данных являются нашей локальной информацией. Чтобы сделать этот модуль для рабочих данных универсальным, Выше информация не может быть записана в программе. Обычно наш подход заключается в использовании файлов конфигурации.
Каждый язык имеет свои собственные поддерживаемые типы профилей. Например, Python поддерживает файлы .ini. Поскольку внутри него есть класс ConfigParser для поддержки чтения и записи файлов .ini, в соответствии с методами, предоставляемыми этим классом, программисты могут свободно манипулировать файлами .ini. В Java Java поддерживает чтение и запись файлов .properties. Класс Java.util.Properties, встроенный в JDK, облегчает нам манипулирование файлами .properties.
dbPort = localhost
databaseName = mydb
dbUserName = root
dbPassword = root
II. Класс Properties в JDK Класс Properties существует в Java.util, который наследуется от Hashtable и предоставляет несколько основных методов:
1. getProperty (String key) для поиска свойства в этом списке свойств с указанным ключом. То есть значение, соответствующее ключу, получается через параметр ключ.
2. load (InputStream inStream), чтобы прочитать список атрибутов (пары ключей и элементов) из входного потока. Получите все пары ключ-значение в указанном файле, загрузив его, например, файл test.properties выше. Для поиска по getProperty (Строковый ключ).
3. setProperty (String key, String value), вызывающий метод Hashtable. Он устанавливает пары ключ-значение, вызывая метод put базового класса.
4. сохранить (OutputStream out, String comments) в списке атрибутов (пары ключей и элементов) в этой таблице свойств, записанных в выходной поток, в формате, подходящем для загрузки в таблицу свойств с использованием метода load. В отличие от метода загрузки, этот метод записывает пары ключ-значение в указанный файл.
5. clear () чтобы очистить все загруженные пары ключ-значение. Этот метод предоставляется в базовом классе.
С помощью вышеуказанных методов мы можем работать с файлом .properties!
==============================================================================
Внутривенно Резюме Нетрудно видеть из приведенного выше примера, что манипулирование файлами конфигурации в Java очень простое. В модуле или системе, которые требуют много информации о конфигурации, нам нужно инкапсулировать специальный класс для общего пользования. Я полагаю, что в последнем вызове основной функции мы увидим использование этого класса. Недостаточно указывает, что я надеюсь, что каждый может дать нам больше советов.
Манипуляции с файлами свойств Java
Во-первых, файл свойств
Java-методы для манипулирования файлами свойств
Вот способ манипулировать файлом свойств
Описание: файлы свойств Java должны быть помещены под путь к классу, чтобы программа могла их прочитать. Соответствующий путь к классу - это фактически путь, на котором хранятся классы или библиотеки Java. В проекте Java свойства помещаются в файл класса. В веб-приложении проще всего поместить его в каталог веб-приложения WEB-INF \ classes или поместить в другие папки. В настоящее время при установке переменной окружения classpath необходимо указать путь к этой папке. Добавьте его в переменную classpath, чтобы его также можно было прочитать. Здесь вам необходимо глубоко понять путь к классам. Путь к классам не является системной переменной среды, преднамеренно установленной в системе. WEB-INF \ classes также не отличается от каталога файлов классов проекта Java.
Файл свойств в java - это файл конфигурации, в основном используемый для выражения информации о конфигурации, тип файла - * .properties, формат - текстовый файл, а содержимое файла - формат «ключ = значение».
Файл свойств используется в Java-программировании во многих местах, и операция очень удобна.
Карта свойств (карта свойств): это структура данных, в которой хранятся пары ключ / значение. Отображение атрибута часто используется для хранения информации о конфигурации.
У него есть три характеристики:
- Ключ и значение Fighting String
- Пары ключ / значение могут быть легко записаны или прочитаны из файла.
- Используйте вторичную таблицу для хранения значений по умолчанию
Класс Java, который реализует сопоставление свойств, называется Свойства (Java.util.Properties). Этот класс является более важным классом в Java. Он в основном используется для чтения файлов конфигурации Java. Различные языки имеют свои собственные файлы конфигурации поддержки Многие переменные в файле конфигурации часто меняются, это также для удобства пользователя, что позволяет пользователю изменять соответствующие параметры переменных без самой программы.
Этот класс является поточно-ориентированным: несколько потоков могут совместно использовать один объект Properties без внешней синхронизации.
Класс Properties наследуется от Hashtable следующим образом:
Метод строительства:
- Properties () создает пустой список свойств без значения по умолчанию.
- Properties(Properties defaults) Создайте пустой список атрибутов с указанными значениями по умолчанию.
Он предоставляет несколько основных методов:
1. getProperty (String key): используйте указанный ключ для поиска свойств в этом списке свойств. То есть через параметр ключа получить значение, соответствующее ключу.
2. load (InputStream inStream): чтение списка атрибутов (пары ключей и элементов) из входного потока. Получите все пары ключ-значение в файле, загрузив указанный файл (например, файл test.properties выше). Для поиска по getProperty (Строковый ключ).
3. setProperty (String key, String value): вызов метода put для Hashtable. Он устанавливает пару ключ-значение, вызывая метод put базового класса.
4. store (OutputStream out, String comments): записать список атрибутов (пары ключей и элементов) в этой таблице свойств в выходной поток в формате, подходящем для загрузки в таблицу свойств с использованием метода load. В отличие от метода загрузки, этот метод записывает пары ключ-значение в указанный файл.
5. clear (): Очистить все загруженные пары ключ-значение. Этот метод предоставляется в базовом классе.
Поскольку свойства наследуются от Hashtable, вы можете применять методы put и putAll к объектам Properties.Однако эти два метода не рекомендуются, поскольку они позволяют вызывающей стороне вставлять элемент, ключ или значение которого не является строкой.Вместо этого вы должны использовать метод setProperty.
Если вы вызываете метод store или save для «небезопасного» объекта Properties (то есть ключа или значения, содержащего не-String), вызов завершится неудачно.
Точно так же, если вы вызываете метод propertyNames или list для «небезопасного» объекта Properties (то есть ключа, который содержит не-String), вызов завершится неудачно.
Класс Properties предоставляет два механизма для значений по умолчанию:
Установите значение по умолчанию при попытке получить строковое значение. (Когда значение ключа не существует, оно будет использовано автоматически)
Если вам слишком сложно указывать значения по умолчанию для каждого вызова, вы можете поместить все значения по умолчанию во вторичную карту атрибутов и предоставить карту в конструкторе главной карты. И использовать его для построения таблицы поиска.
Properties defaultSettings=new properties();
Properties settings=new properties(defaultSettings);
Примечание. Сопоставление атрибутов - это простая таблица без иерархии. Но вы можете просто использовать метод именования пакетов в Java, чтобы просто замаскировать иерархию. Если вы хотите хранить сложную информацию о конфигурации, вы должны использовать класс Preferences.
Три, Java читать метод файла свойств
Виртуальная машина Java (JVM) имеет свой собственный файл конфигурации системы (system.properties), который мы можем получить следующим образом.
// Получить системные свойства JVM
public class ReadJVM
public static void main(String[] args)
Properties pps = System.getProperties();
Шесть способов чтения файлов свойств с помощью API J2SE
1. Используйте метод load () класса java.util.PropertiesПримеры:
InputStream in = new BufferedInputStream(new FileInputStream(name));Properties p = new Properties();p.load(in);
Подробный пример один:
* Создайте новый файл конфигурации (Test.properties), содержание которого можно ввести в следующую инструкцию.
* Примечание: файл конфигурации должен быть размещен в корневом каталоге проекта. (Здесь нет обработки исключений)
public class getProperties
public static void main(String[] args) throws FileNotFoundException, IOException
Properties pps = new Properties();
Перечисление enum1 = pps.propertyNames (); // Получить имя файла конфигурации
String strKey = (String) enum1.nextElement();
String strValue = pps.getProperty(strKey);
Подробный пример два:
// О часто используемых операциях в классе Properties
public class TestProperties
// Считать значение в соответствии с ключом
public static String GetValueByKey(String filePath, String key)
Properties pps = new Properties();
InputStream in = new BufferedInputStream (new FileInputStream(filePath));
String value = pps.getProperty(key);
>catch (IOException e)
// Прочитать всю информацию о свойствах
public static void GetAllProperties(String filePath) throws IOException
Properties pps = new Properties();
InputStream in = new BufferedInputStream(new FileInputStream(filePath));
Enumeration en = pps.propertyNames (); // Получить имя файла конфигурации
String strKey = (String) en.nextElement();
String strValue = pps.getProperty(strKey);
// Записать информацию о свойствах
public static void WriteProperties (String filePath, String pKey, String pValue) throws IOException
Properties pps = new Properties();
InputStream in = new FileInputStream(filePath);
// Чтение списка атрибутов из входного потока (пары ключей и элементов)
// Вызов метода put из Hashtable. Используйте метод getProperty для обеспечения параллелизма.
// Обязательное использование строк для ключей и значений атрибутов. Возвращаемое значение является результатом вызова метода Hashtable.
OutputStream out = new FileOutputStream(filePath);
// в формате, подходящем для загрузки в таблицу свойств с использованием метода load,
// Список атрибутов (пары ключей и элементов) в этой таблице свойств записывается в выходной поток
pps.store(out, "Update " + pKey + " name");
public static void main(String [] args) throws IOException
String value = GetValueByKey("Test.properties", "name");
2. Используйте метод getResourceAsStream () переменной класса
Пример:
InputStream in = JProperties.class.getResourceAsStream(name);
Properties p = new Properties();
p.load(in);
Подробный пример:
* Создайте новый файл конфигурации (Test.properties), содержание которого можно ввести в следующую инструкцию.
* Примечание: файл конфигурации должен находиться в текущем каталоге. (Иерархия каталогов также может начинаться с папки, расположенной ниже src, но она не должна включать src и не должна включать обратную косую черту в начале.)
public class getProperties
public static void main(String[] args) throws FileNotFoundException, IOException
Properties pps = new Properties();
Перечисление enum1 = pps.propertyNames (); // Получить имя файла конфигурации
String strKey = (String) enum1.nextElement();
String strValue = pps.getProperty(strKey);
3. Используйте метод getResourceAsStream () для java.lang.ClassLoader, полученный class.getClassLoader ()
Пример:
InputStream in = JProperties.class.getClassLoader().getResourceAsStream(name);
Properties p = new Properties();
p.load(in);
Подробный пример:
* Создайте новый файл конфигурации (Test.properties), содержание которого можно ввести в следующую инструкцию.
* Примечание: файл конфигурации должен находиться в каталоге src.
public class getProperties
public static void main(String[] args) throws FileNotFoundException, IOException
Properties pps = new Properties();
Перечисление enum1 = pps.propertyNames (); // Получить имя файла конфигурации
String strKey = (String) enum1.nextElement();
String strValue = pps.getProperty(strKey);
4. Используйте статический метод getSystemResourceAsStream () класса java.lang.ClassLoader.
Пример:
InputStream in = ClassLoader.getSystemResourceAsStream(name);
Properties p = new Properties();
p.load(in);
Подробный пример:
* Создайте новый файл конфигурации (Test.properties), содержание которого можно ввести в следующую инструкцию.
* Примечание: файл конфигурации должен находиться в каталоге src.
public class getProperties
public static void main(String[] args) throws FileNotFoundException, IOException
Properties pps = new Properties();
Перечисление enum1 = pps.propertyNames (); // Получить имя файла конфигурации
String strKey = (String) enum1.nextElement();
String strValue = pps.getProperty(strKey);
5. Используйте метод getBundle () класса java.util.ResourceBundle
Пример:
ResourceBundle rb = ResourceBundle.getBundle(name, Locale.getDefault());
Этот класс предоставляет ярлык для интернационализации программного обеспечения. С помощью этого класса вы можете создать написанную вами программу:
- Легко локализуйте или переводите на разные языки
- Обрабатывать несколько локалей одновременно
- Может быть легко изменено в будущем для поддержки большего количества локалей
Проще говоря, роль этого класса состоит в том, чтобы читать файлы свойств ресурса (свойства), а затем сопоставлять информацию о языке страны текущей системы (также может быть задана программой) в соответствии с информацией об имени (локализованной информацией) файла .properties, а затем получать Содержимое соответствующего файла свойств.
нота:
- Имя файла свойств стандартизировано: общее соглашение об именах: custom name_language code_country code.properties
- Если это значение по умолчанию, напишите прямо как: custom name.properties
такие как:
myres_en_US.properties
myres_zh_CN.properties
myres.properties
В китайской операционной системе, если существуют файлы myres_zh_CN.properties и myres.properties, сначала будут использоваться myres_zh_CN.properties, а если myres_zh_CN.properties не существует, будут использоваться значения по умолчанию myres.properties.
Файлы ресурсов, которые не предоставляют языки и регионы, являются файлами ресурсов системы по умолчанию.
Файлы ресурсов должны быть закодированы в соответствии с ISO-8859-1, поэтому для обработки не на западном языке они должны быть преобразованы в формат Java Unicode Escape. Метод преобразования осуществляется с помощью инструмента native2ascii, поставляемого с JDK.
Подробный пример:
* Интернационализированный тест привязки ресурса
* @author leizhimin 2009-7-29 21:17:42
public class TestResourceBundle
public static void main(String[] args)
Locale locale1 = new Locale("zh", "CN");
ResourceBundle resb1 = ResourceBundle.getBundle("myres", locale1);
ResourceBundle resb2 = ResourceBundle.getBundle("myres", Locale.getDefault());
Locale locale3 = new Locale("en", "US");
ResourceBundle resb3 = ResourceBundle.getBundle("myres", locale3);
// Если используется языковой стандарт по умолчанию, то в английской операционной системе будет выбран файл ресурсов myres_en_US.properties или myres.properties.
6. Используйте конструктор класса java.util.PropertyResourceBundle.
InputStream in = new BufferedInputStream(new FileInputStream(name));
ResourceBundle rb = new PropertyResourceBundle(in);
PropertyResourceBundle - это определенный подкласс ResourceBundle, который является ресурсом локали через управление статической строкой файла свойств.
В отличие от других типов пакетов ресурсов, вы не можете создавать подклассы для PropertyResourceBundle. Вместо этого предоставьте файл свойств, содержащий данные ресурса. ResourceBundle.getBundle автоматически найдет соответствующий файл свойств и создаст PropertyResourceBundle, который ссылается на файл
Конкретное использование выглядит следующим образом:
Создайте файл свойств: conf.properties, содержимое которого выглядит следующим образом:
BODWEBSERVICEIPADDRESS=D:\\work\\LCEclipse\\workspace\\bodportal\\webapps\\bod\\WEB-INF\\classes\\sysconfig\\policyconfig.xml
В программе получите его через PropertyResourceBundle:
private final static String PROPERTIES_NAME = "conf";
public static String getProperties(String configName) PropertyResourceBundle prbConfig =
(PropertyResourceBundle)PropertyResourceBundle.getBundle(PROPERTIES_NAME);
return prbConfig.getString(configName);
>
Объекты локали представляют конкретные географические, политические и культурные регионы. Операции, для выполнения которых требуется локаль, называются операциями, чувствительными к локали, и они используют локаль для адаптации информации для пользователей. Например, отображение числового значения является чувствительной к локали операцией, и числовое значение должно быть отформатировано в соответствии с обычаями / традициями страны, региона или культуры пользователя.
Используйте методы конструирования в этом классе для создания Locale:
Locale(String language)
Locale(String language, String country)
Locale(String language, String country, String variant)
После создания локали вы можете запросить информацию о себе. Используйте getCountry для получения кода страны ISO и getLanguage для получения кода языка ISO. Вы можете использовать getDisplayCountry, чтобы получить название страны, подходящее для отображения пользователю. Точно так же вы можете использовать getDisplayLanguage, чтобы получить название языка, подходящее для отображения пользователю. Интересно, что сам метод getDisplayXXX чувствителен к локали и имеет две версии: одна использует локаль по умолчанию в качестве параметра, а другая использует указанную локаль в качестве параметра.
Использование этого инструмента заключается в следующем:
Если вам это трудно, вы можете вставить в него китайский язык и нажать Enter, чтобы увидеть результат после транскодирования.
Если вы понимаете это, вы не будете удивлены интернационализацией веб-фреймворков, таких как Struts
Читайте также: