EJB interceptors provide a way to define code that can be executed before and after a method call. They are typically used for logging, testing,
auditing or security purposes.
Interceptor methods can be applied or bound at three levels:
- The default interceptor is called for each bean as part of the deployment and can only be applied through an XML file.
- The class-level interceptor is invoked for each method of the bean. The class-level interceptor can be applied both through an annotation and
through an XML file.
- The method-level interceptor is invoked for a specific method of the bean. The method-level interceptor can be applied both through an
annotation and through an XML file.
If you want to declare these methods in an XML file, you must declare them in a file named ejb-jar.xml
. Otherwise, they may not be
applied or used as intended.
What is the potential impact?
If EJB interceptors are not applied or used as intended, inconsistent application behavior in the app business logic or security might happen.
Below are some real-world examples of this issue.
Inconsistent Behavior
Interceptors declared outside of ejb-jar.xml
may not be applied consistently across all EJBs. This can lead to unpredictable
application behavior, making debugging and maintaining the code difficult.
Security Risks
Interceptors often handle sensitive operations such as security checks or transaction management. If an interceptor is not applied due to incorrect
declaration, these operations may not be performed, leading to potential security vulnerabilities.
For example, if an interceptor responsible for
user authentication is not applied, unauthorized users may gain access to sensitive information.
Performance Impact
Interceptors can also be used to improve application performance, for instance, by managing database transactions. If these interceptors are not
applied, it could lead to performance issues, such as longer response times or increased server load.
This could open the way for efficient Denial of Service attacks.