What are EJB interceptors used for?

Question

I'm building a Java EE 6 web application where users have to login through a managed bean that is session-scoped. What are EJB interceptors and how can they help me in my program. I have been reading about them, but the materials I read seem a little absurd in explanation. Anyone to put it in the lay terms for me. Thanks in advance

Answer 1

Interceptors are objects that are able to interpose themselves on method calls or the life cycle events of EJB's or any CDI beans.

Common usages:

• Profiling : you can measure how much time an EJB method takes. So, you could find possibly bottlenecks.
• Auditing : Logs who and when someone uses an EJB method.
• Logs : Write to a file if a method fails/succeeds (or throws an exception), also lets you know the parameters and the return value of the method invocation.
• Custom Framework : You could create a custom framework based on your own business rules.
• Life Cycle : For example, if some EJBs require some special resources you could add them in the @PostConstruct and close the resource at @PreDestroy time.
• Custom Injection Annotations: Create your own annotations and do some lookups to JNDI to inject resources before using the EJB's method.

Interceptors are the best friends of EJB's :

• Share life cycle: created, destroyed, passivated, and activated along with their bean instances
• Same Java call stack
• Same JNDI ENC context as the EJBs they intercept
• AroundInvoke method invocations occur within the same transaction and security context as the method on which they are interposing.

So, here are the interceptors. For your purpose (login page) as Leonardo said a Filter will be better, but keep the interceptors in your toolbox.

Answer 2

IMO, I don't think interceptors will help you much in this case, because it's used to wrap EJB methods, and probably most of these methods will have to be available only when the user is already logged in the system. It sounds like an unnecessary overhead to check for every EJB method if it's being requested by an authorized user or not. A Filter is usually what you really want when you are trying to restrict the app usage because it works on the request level and you can just check if a user is logged in if there's some Session object there.

Interceptors are certainly useful for horizontal features such as profiling and auditing.

Answer 3

I dont especially know interceptors in Java EE 6 but I know those from Struts 2 framework and it looks to be the same in fact.

The point is that transverse tasks should not be in your classes (logging, identification, security, ...).. so it has been decided to be put inside interceptors.

When the request arrives, before arriving to (and after leaving) your action, I would say, it is intercepted by some other classes that can verify, change or do anything you think is appropriate..

This is a good way of programming so POO is more respected. Your business classes are no more contaminated with pieces of codes that should not be there and more, with pieces of codes that should be accessible from all of the application