Java Reference
In-Depth Information
CDI interceptors require one additional step of declaring the interceptors in the
beans.xml
i le.
This is one of the rare cases in which you need to use XML coni guration; it's used to determine the
execution order of the interceptors.
Interceptor bindings can include other interceptor bindings that wrap multiple bindings together.
The CDI container is not started if the
beans.xml
i le is missing:
<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
<interceptors>
<class> com.devchronicles.interceptor.SecurityInterceptor</class>
<class> com.devchronicles.interceptor.SomeOtherInterceptor</class>
</interceptors>
</beans>
Although the declaration order of the binding annotations may imply a sense of execution order, in
reality it has no effect. The execution order of the interceptor depends on the declaration order in
the
beans.xml
i le.
Mixing CDI and EJB interceptors may create ambiguity in the ordering. As a rule, EJB interceptors
execute before CDI interceptors do.
Intercepting methods creates complexity, but creating multiple bindings and mixing
CDI and EBJ interceptors brings this complexity to the next level. Complex interceptor
structures may expose a complex application architecture for developers who are not familiar
with the code.
WHERE AND WHEN TO USE INTERCEPTORS
AOP is a popular programming paradigm that can help to implement and encapsulate cross‐cutting
concerns. In many cases, AOP can really shine. Logging, auditing, security, and other repeating
nonbusiness behavior are good candidates.
Interceptors in Java EE are powerful tools that allow you to implement AOP without the need for
a third‐party framework. With the introduction of CDI interceptors, Java EE has become more
complete and capable. Implementing an interceptor may require some XML coni guration, unlike
other patterns listed in this topic. However, the coni guration is only limited to provide ordering,
which other patterns such as decorators may also require.
Interceptors can address many cross‐cutting concerns. They provide a clean implementation while
encapsulating the common concern. However, interceptors can be troublesome if they change
business behavior. If this happens, the business logic is distributed between the class and the
interceptor. The business method becomes unreadable and misleading because it doesn't expose
the whole logic. Additionally, it unnecessarily complicates the architecture and application l ow.
Besides, debugging is almost impossible and complicated.
Readability and self‐documenting code is an important aim, and misuse of interceptors can cause
great harm if it consists of business logic. However, using interceptors for nonbusiness and repeating
behavior can simplify the business methods and help greatly.
