Метод производителя данных (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 и возвращает число с двойной точностью.
Листинг 2.17. IsbnGenerator, внедряющий произведенные типы
@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 получает имя класса точки внедрения.
Таблица 2.2.InjectionPoint API
Метод |
Описание |
Type getType() |
Получает требуемый тип точки внедрения |
Set getQualifiers() |
Получает требуемые квалификаторы точки внедрения |
Bean getBean() |
Получает объект Bean, представляющий компонент, который определяет точку внедрения |
Member getMember() |
Получает объект Field в случае внедрения поля |
Annotated getAnnotated() |
Возвращает Annotated Field или AnnotatedParameter в зависимости от того, относится точка внедрения к полю или параметру метода/конструктора |
boolean isDelegate() |
Определяет, происходит ли в данной точке внедрения подключение делегата декоратора |
boolean isTransient() |
Определяет, является ли точка временным полем |
Листинг 2.18. Производитель данных автоматического журнала
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 использует производителей данных, а для разрушения — утилизаторы. Метод утилизатора позволяет приложению выполнять настраиваемую очистку объекта, возвращенного методом производителя данных.
Читать дальше