Изучаем Java EE 7 - [22]
InjectionPoint API. В листинге 2.16 атрибуты и возвращаемое значение, полученное посредством @Produces, не требуют никакой информации о том, куда они внедряются. Но в определенных случаях объектам нужна информация о точке их внедрения. Это может быть способ конфигурации или изменения поведения в зависимости от точки внедрения.
Например, рассмотрим создание автоматического журнала. В JDK для создания java.util.logging.Logger вам необходимо задать категорию класса, владеющего им. Скажем, если вам нужен автоматический журнал для BookService, следует написать:
>Logger log = Logger.getLogger(BookService.class.getName());
Как бы вы получили Logger, которому необходимо знать имя класса точки внедрения? В CDI есть InjectionPoint API, обеспечивающий доступ к метаданным, которые касаются точки внедрения (табл. 2.2). Таким образом, вам необходимо создать метод производителя данных, который использует InjectionPoint API для конфигурации правильного автоматического журнала. В листинге 2.18 показано, как метод createLogger получает имя класса точки внедрения.
| Метод | Описание |
|---|---|
| Type getType() | Получает требуемый тип точки внедрения |
| Set | Получает требуемые квалификаторы точки внедрения |
| Bean getBean() | Получает объект Bean, представляющий компонент, который определяет точку внедрения |
| Member getMember() | Получает объект Field в случае внедрения поля |
| Annotated getAnnotated() | Возвращает Annotated Field или AnnotatedParameter в зависимости от того, относится точка внедрения к полю или параметру метода/конструктора |
| boolean isDelegate() | Определяет, происходит ли в данной точке внедрения подключение делегата декоратора |
| boolean isTransient() | Определяет, является ли точка временным полем |
>public class LoggingProducer {
>··@Produces
>··private Logger createLogger(InjectionPoint injectionPoint) {
>····return Logger.getLogger(injectionPoint.getMember(). getDeclaringClass(). getName());
>··}
>}
Чтобы использовать произведенный автоматический журнал в любом компоненте, вы просто внедряете его и работаете с ним. Имя класса категории автоматического журнала потом будет задано автоматически:
>@Inject Logger log;
Утилизаторы
В предыдущих примерах (см. листинги 2.17 и 2.18) мы использовали производителей данных для создания типов данных или объектов POJO таким образом, чтобы они могли быть внедрены. Мы создали их, и, пока они использовались, нам не требовалось разрушать или закрывать их. Но некоторые методы производителей данных возвращают объекты, требующие явного разрушения, например интерфейс Java Database Connectivity (JDBC), сеанс JMS или менеджер сущности. Для создания CDI использует производителей данных, а для разрушения — утилизаторы. Метод утилизатора позволяет приложению выполнять настраиваемую очистку объекта, возвращенного методом производителя данных.
Листинг 2.19 показывает утилитный класс, который создает и закрывает интерфейс JDBC. Метод createConnection берет драйвер Derby JDBC, создает соединение с определенным URL, обрабатывает исключения и возвращает открытое соединение JDBC. Это сопровождается аннотацией @Disposes.
>public class JDBCConnectionProducer {
>··@Produces
>··private Connection createConnection() {
>····Connection conn = null;
>····try {
>······Class.forName("org.apache.derby.jdbc.EmbeddedDriver"). newInstance();
>······conn = DriverManager.getConnection("jdbc: derby: memory: chapter02DB",
>"APP", "APP");
>····} catch (InstantiationException | IllegalAccessException | ClassNotFoundException) {
>······e.printStackTrace();
>····}
>····return conn;
>··}
>··private void closeConnection(@Disposes Connection conn) throws SQLException {
>····conn.close();
>··}
>}
Уничтожение может осуществляться путем сопоставления метода утилизатора, определенного тем же классом, что и метод производителя данных. Каждый метод утилизатора, сопровождаемый аннотацией @Disposes, должен иметь строго один параметр такого же типа (тут java.sql.Connection) и квалификаторы (@Default), как соответствующий тип возврата метода производителя данных (с аннотацией @Produces). Метод утилизатора (closeConnection()) вызывается автоматически по окончании контекста клиента (в листинге 2.20 — контекст @ApplicationScoped), и параметр получает объект, порожденный методом производителя данных.
>@ApplicationScoped
>public class DerbyPingService {
>··@Inject
>··private Connection conn;
>··public void ping() throws SQLException {
>····conn.createStatement(). executeQuery("SELECT 1 FROM SYSIBM.SYSDUMMY1");
>··}
>}
Листинг 2.20 показывает, как компонент внедряет созданное соединение JDBC с аннотацией @Inject и использует его для проверки доступности базы данных Derby. Как видите, этот клиентский код не занимается всеми вспомогательными задачами по созданию и закрытию соединения JDBC либо обработке исключений. Производители данных и утилизаторы — хороший способ создания и закрытия ресурсов.
Области видимости
CDI имеет отношение не только к внедрению зависимостей, но и к контексту (буква С в аббревиатуре CDI означает контекст). Каждый объект, управляемый CDI, имеет строго определенные область видимости и жизненный цикл, которые связаны с конкретным контекстом. В Java область применения POJO достаточно проста: вы создаете экземпляр класса, используя ключевое слово new, и позволяете сборщику мусора избавиться от него, чтобы освободить некоторое количество памяти. При использовании CDI компонент связан с контекстом и остается в нем до тех пор, пока не будет разрушен контейнером. Удалить компонент из контекста вручную невозможно.
