7.6.1. About Container Interceptors
Standard Java EE interceptors, as defined by the JSR 318, Enterprise JavaBeans 3.1
specification, are expected to run after the container has completed security context propagation, transaction management, and other container provided invocation processing. This is a problem if the user application needs to intercept a call before a certain container specific interceptor is run.
Releases prior to JBoss EAP 6.0 provided a way to plug server side interceptors into the invocation flow so you could run user application specific logic before the container completed invocation processing. JBoss EAP 6.1 now implements this feature. This implementation allows standard Java EE interceptors to be used as container interceptors, meaning they use the same XSD elements that are allowed in
ejb-jar.xml file for the 3.1 version of the ejb-jar deployment descriptor.
Positioning of the Container Interceptor in the Interceptor Chain
The container interceptors configured for an EJB are guaranteed to be run before the JBoss EAP 6.1 provided security interceptors, transaction management interceptors, and other server provided interceptors. This allows the user application specific container interceptors to process or configure any relevant context data before the invocation proceeds.
Differences Between the Container Interceptor and the Java EE Interceptor API
Although container interceptors are modeled to be similar to Java EE interceptors, there are some differences in the API semantics. For example, it is illegal for container interceptors to invoke the
javax.interceptor.InvocationContext.getTarget() method because these interceptors are invoked long before the EJB components are setup or instantiated.