CDI Interceptors

В спецификации CDI предусмотрен механизм «перехватчиков», который позволяет реализовывать в прикладном коде приёмы аспектно-ориентированного программирования. Иначе говоря, разработчику становится доступна сквозная функциональность (cross cutting concerns), то есть прежде, чем обратиться к некоторому методу CDI-бина, у программиста появляется возможность выполнить предобработку, сам бизнес-метод и постобработку.

Для этих целей и существует механизм CDI Interceptors, причём применяется он не только для спецификации CDI, но и активно используется в технологии Enterprise JavaBeans.

Для связи бизнес-метода с кодом аспектно-ориентированного программирования необходимо создать кастомную аннотацию, которая дополнительно помечается аннотацией @InterceptorBinding:

@InterceptorBinding
@Target( { METHOD, TYPE } )
@Retention( RUNTIME )
public @interface Audited {
}

Запуск работы Interceptors включает создание класса AuditedInterceptor, над которым следует разместить две аннотаци: @Interceptor (из коробки CDI) и только что созданную пользовательскую аннотацию @Audited.

Ключевым методом соответствующего класса перехватчика является метод, помеченный аннотацией @AroundInvoke. Для наглядности переменные calledBefore и calledAfter определяют места для пред- и постобработки, поэтому в приведённом ниже примере они выставляются в истинное значение до и после выполнения метода proceed().

Вызов этого метода у объекта InvocationContext позволяет выполнять код бизнес-метода. Без данной конструкции передача управления в метод бина не будет осуществляться, что в определённых случаях позволяет менять привычный порядок выполнения приложения (например, фильтр проверки ролей пользователя).

@Audited
@Interceptor
public class AuditedInterceptor {
    public static boolean calledBefore = false;
    public static boolean calledAfter = false;

    @AroundInvoke
    public Object auditMethod(InvocationContext ctx) throws Exception {
        calledBefore = true;
        Object result = ctx.proceed();
        calledAfter = true;
        return result;
    }
}

Теперь осталось пометить бизнес-метод самого CDI-бина аннотацией @Audited, которую мы уже неоднократно упоминали:

public class SuperService {
    @Audited
    public String deliverService(String uid) {
        return uid;
    }
}

Если аннотация помечается над классом бина, то механизм перехватчиков задействуется для всех его методов.

Кроме того, чтобы интерцептор заработал в приложении, для спецификации CDI важно определить его в конфигурационном файле beans.xml:

<beans xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
      http://java.sun.com/xml/ns/javaee/beans_1_2.xsd">
    <interceptors>
        <class>ru.otus.interceptor.AuditedInterceptor</class>
    </interceptors>
</beans>

Осталось рассмотреть преимущества и недостатки CDI Interceptors

Начнём с плюсов: - использование CDI Interceptors является стандартной фичей спецификации Java EE; - CDI-библиотеки могут применяться в приложениях Java SE; - CDI Interceptors могут использоваться, когда есть серьёзные ограничения на сторонние библиотеки в рамках приложений Java EE.

А теперь минусы: - возникает жёсткая связка между классом бизнес-логики и классом интерцептора; - трудно определить, какие классы подвергаются интерцепции в проекте; - нет гибкого механизма применения CDI Interceptors к некоторой группе методов, т. е. нужно над каждым вешать соответствующую аннотацию.

Пожалуй, на этом всё. Узнать больше можно на курсах OTUS по Java EE.

Возникли сложности при использовании CDI Interceptors? Задавайте вопросы в комментариях!