Статьи

Настройка приложений Java EE или «Применение Bien на практике»

Февраль 26, 2019
В прошлом много говорилось о настройке приложения. Я не знаю, кто начал дебаты, но наиболее фундаментальное чтение (с учетом будущего Java EE 7 и более поздних версий) — это сообщение Антонио Гонсалвеса [Debate] — А как насчет конфигурации в Java EE 7 . Факт в том, что с ванильной Java EE мы все делаем настройку приложений день ото дня. Без какого-либо специального механизма на месте. Посмотрев последнее сообщение Адама от вчерашнего дня, я хотел бы поделиться небольшим дополнением к нему, которое, как мне кажется, может соответствовать большинству проектов.

Почему этот пост?

Основы, показанные Адамом, действительно умны. Ты просто

1
2
@Inject
int yourConfigVariable;

и вы сделали. Вам не нужно заботиться о свойствах или других классах конфигурации. Но, глядя на это, вы видите, что вам как-то нужно заполнить вашу конфигурацию откуда-то. И, оглядываясь назад на пост Антонио, вы видите, что у вас есть много вариантов сделать это. Наиболее удобным для нас является, вероятно, механизм свойств Java. Используя это в сочетании с кодом, представленным Адамом, у вас получится свойство Configuration.properties с бесконечным списком ключей из одного слова. Это не то, что я бы назвал ремонтопригодным. Так что, в основном, именно поэтому у поста есть заголовок: «Применение Bien на практике» ..oO (простите, Адам!) ? Вот мои подходы к проблеме.

Заполните вашу конфигурацию из файла свойств

Самая основная часть заключается в добавлении файла Configuration.properties в ваше приложение (пакет по умолчанию). Теперь мы немного изменим держатель конфигурации, чтобы сделать его типом Свойства. Теперь измените метод Адама fetchConfiguration (), чтобы загрузить его.

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
private Properties configData;
 
@PostConstruct
    public void fetchConfiguration() {
    String fileName = "Configuration.properties";
            configData =
                    loadPropertiesFromClasspath(fileName);
}
 
     /**
     * Load properties file from classpath with Java 7 🙂
     * @param fileName
     * @return properties
     */
  public static Properties loadPropertiesFromClasspath(String fileName) {
  try (InputStream in = Thread.currentThread().getContextClassLoader().getResourceAsStream(
                        fileName)) {
            if (in != null) {
                props = new Properties();
                props.load(in);
            }
        } catch (IOException ioe) {
            log.debug("Can't load properties.", ioe);
        }

Теперь вы должны соответствующим образом изменить методы @Producer. Я только показываю метод getString (), чтобы показать вам концепцию:

01
02
03
04
05
06
07
08
09
10
11
12
/**
     * Get a String property
     * @param point
     * @return String
     */
@Produces
public String getString(InjectionPoint point) {
        String propertyPath = point.getMember().getDeclaringClass().getName()+ ".";
        String propertyName = point.getMember().getName();
        String propertyValue = configData.getProperty(propertyPath+propertyName);
        return (propertyValue == null) ? "" : propertyValue;
    }

Для удобства я добавил имя декларируемого класса как propertyPath, чтобы в вашем файле свойств был порядок. Вы используете методы продюсера, как показал Адам:

1
2
3
4
5
package net.eisele.configuration;
public class HitsFlushTimer {
    @Inject
    private String hitsFlushRate;
 }

В этом случае вы получите доступ к свойству с ключом net.eisele.configuration.HitsFlushTimer.hitsFlushRate в файле Configuration.properties. Одно быстрое предупреждение. Если с вами случится так, что вам придется упаковывать отдельные модули ejb и war в ухо, вам, вероятно, понадобится аннотация javax.annotation.security.PermitAll в вашем синглтоне конфигурации.

Тогда вы получите много дубликатов

Это, вероятно, правда. Если вы снова и снова используете одну и ту же конфигурацию (например, httpProxy), это заставит вас иметь одинаковое значение для разных ключей в вашем файле свойств. Решение кажется прямым. Для этого нам нужен наш собственный классификатор. Поехали:

1
2
3
4
5
6
7
@Retention(RUNTIME)
@Target({FIELD, METHOD})
@Qualifier
public @interface AppProperty {
    @Nonbinding
    public String value();
}

Теперь у нас есть свой собственный классификатор для этого. Далее следует изменить @Producer соответственно:

1
2
3
4
5
6
@Produces @AppProperty("")
    public String getString(InjectionPoint point) {
    String property = point.getAnnotated().getAnnotation(AppProperty.class).value();
    String valueForFieldName = configData.getProperty(property);
    return (valueForFieldName == null) ? "" : valueForFieldName;
}

Вот и все. Теперь вы можете использовать что-то вроде этого где угодно:

1
2
3
@Inject
    @AppProperty("net.eisele.configuration.test2")
    String test2;

Я знаю, это не так элегантно, как аннотация @Inject Адама. Но: вам не нужно много гадать, чтобы увидеть, что происходит и откуда исходит ваша ценность. Я считаю это большим профессионалом в проектах с более чем одним разработчиком.

Да уж. Все еще не очень ремонтопригоден.

ОК. Я знаю. Вы все еще говорите о рефакторинге имен свойств. Правильно? Что осталось сделать? Вы можете подумать об использовании CKey Enum, который инкапсулирует все ваши ключи свойств, и использовать его вместо простого использования самих ключей. Но я бы предпочел просто использовать простые строковые ключи в моем коде. Счастливая настройка сейчас. Как вы настраиваете свои приложения? Дай мне знать! Рад получить комментарии ?

Справка: настройте приложения Java EE или «внедрите Bien» на практике от нашего партнера по JCG Маркуса Эйзела (Markus Eisele) в блоге « Разработка программного обеспечения для предприятий с использованием Java» .

Статьи по Теме :

35
Share: