Вы можете аннотировать свой ConfigSource как одноэлементный компонент сеанса и пометить его для активной инициализации во время последовательности запуска приложения. Также вам необходимо определить статическую переменную-член, содержащую ваши значения конфигурации.
С помощью этой настройки вы можете лениво загружать значения ваших свойств из внедренного источника JPA, а также из любого другого CDI или EJB.
См. следующий пример кода
@Startup
@Singleton
public class MyConfigSource implements ConfigSource {
public static final String NAME = "MyConfigSource";
public static Map<String, String> properties = null; // note to use static here!
@PersistenceContext(unitName = ".....")
private EntityManager manager;
@PostConstruct
void init() {
// load your data from teh JPA source or EJB
....
}
@Override
public int getOrdinal() {
return 890;
}
@Override
public String getValue(String key) {
if (properties != null) {
return properties.get(key);
} else {
return null;
}
}
@Override
public String getName() {
return NAME;
}
@Override
public Map<String, String> getProperties() {
return properties;
}
}
ConfigSource — это POJO, потому что, если компонент CDI ожидает, что конфигурация будет внедрена в него при запуске на основе ConfigSource, который имеет зависимости от CDI, вы можете столкнуться с проблемами зацикливания при запуске.
По этой причине пример CongigSoruce создается дважды — один раз в начале из Config-API, а затем из реализации CDI на @PostConstruct. С помощью статической переменной «свойства» мы перегружаем значения из уже созданного ConfigSource. Конечно, вы также можете разделить код на два класса, если хотите.
person
Ralph
schedule
07.06.2019