Энтони Гонсалвес - Изучаем Java EE 7

public class NumberProducer {

··@Produces @ThirteenDigits

··private String prefix13digits = "13-";

··@Produces @ThirteenDigits

··private int editorNumber = 84356;

··@Produces @Random

··public double random() {

····return Math.abs(new Random(). nextInt());

··}

}

Класс NumberProducer в листинге 2.16 имеет несколько атрибутов и методов (все с аннотацией javax.enterprise.inject.Produces). Это означает, что все произведенные типы и классы теперь могут внедряться с помощью @Inject с использованием квалификатора (@ThirteenDigits, @EightDigits или @Random).

Метод производителя данных (random() в листинге 2.16) — это метод, выступающий в качестве фабрики экземпляров компонентов. Он позволяет внедряться возвращаемому значению. Мы даже можем указать квалификатор (например, @Random), область видимости и EL-имя, как вы увидите позднее. Поле производителя данных (prefix13digits и editorNumber) — более простая альтернатива методу производителя данных, не имеющая бизнес-кода. Это только свойство, которое становится внедряемым.

В листинге 2.9 IsbnGenerator генерирует номер ISBN с формулой "13-84356-" + Math.abs(newRandom(). nextInt()). С помощью NumberProducer (см. листинг 2.16) мы можем использовать произведенные типы для изменения этой формулы. В листинге 2.17 IsbnGenerator теперь внедряет и строку, и целое число с аннотациями @Inject @ThirteenDigits, представляющими префикс ("13-") и идентификатор редактора (84356) номера ISBN. Случайный номер внедряется с помощью аннотаций @Inject @Random и возвращает число с двойной точностью.

@ThirteenDigits

public class IsbnGenerator implements NumberGenerator {

··@Inject @ThirteenDigits

··private String prefix;

··@Inject @ThirteenDigits

··private int editorNumber;

··@Inject @Random

··private double postfix;

··public String generateNumber() {

····returnprefix + editorNumber + postfix;

··}

}

В листинге 2.17 вы можете видеть строгую типизацию в действии. Благодаря тому же синтаксису (@Inject @ThirteenDigits) CDI знает, что ему нужно внедрить строку, целое число или реализацию NumberGenerator. Преимущество применения внедряемых типов (см. листинг 2.17) вместо фиксированной формулы (см. листинг 2.9) для генерации чисел состоит в том, что вы можете использовать все возможности CDI, такие как альтернативы (и при необходимости иметь альтернативный алгоритм генератора номеров ISBN).

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 получает имя класса точки внедрения.

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), и параметр получает объект, порожденный методом производителя данных.