@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 получает имя класса точки внедрения.
| Метод | Описание |
|---|---|
| Type getType() | Получает требуемый тип точки внедрения |
| Set<Annotation> getQualifiers() | Получает требуемые квалификаторы точки внедрения |
| 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.