1. Callbacks and Interceptors

2. Contents  Session Beans Life Cycle  Interceptors

3. Life cycle means that a session bean goes through a predefined set of state transitions.  Depending on the type of your bean (stateless, stateful, singleton), the life cycle will consist of different states.  Each time the container changes the life-cycle state, it can invoke methods that are annotated with callback annotations.

4. Interceptors allow you to add cross-cutting concerns to your beans.  When a client invokes a method on your session bean, the container is able to intercept the call and process business logic before the bean’s method is invoked.

5. 1. Session Beans Life Cycle  Stateless and Singleton  Stateful  Callbacks

6. 1.1.Stateless and Singleton Stateless and singleton beans have in common the fact that they don’t maintain conversational state with a dedicated client. Life cycle of stateless and singleton beans  1. The life cycle of a stateless or singleton session bean starts when a client requests a reference to the bean (using either dependency injection or JNDI lookup). The container creates a new session bean instance.

7.  2. If the newly created instance uses dependency injection through annotations (@Resource, @EJB, @PersistenceContext, etc.) or deployment descriptors, the container injects all the needed resources.  3. If the instance has a method annotated with @PostContruct, the container invokes it.

8.  4. The bean instance processes the call invoked by the client and stays in ready mode to process future calls. Stateless beans stay in ready mode until the container frees some space in the pool. Singletons stay in ready mode until the container is shut down.  5. The container does not need the instance any more. It invokes the method annotated with @PreDestroy, if any, and ends the life of the bean instance.

9. Stateless and singleton bean life cycle

10. 1.2.Stateful Stateful beans maintain conversational state with their client, and therefore have a slightly different life cycle. The container generates an instance and assigns it only to one client. Then, each request from that client is passed to the same instance.

11. The stateful bean life cycle  1. The life cycle of a stateful bean starts when a client requests a reference to the bean (either using dependency injection or JNDI lookup). The container creates a new session bean instance and stores it in memory.  2. If the newly created instance uses dependency injection through annotations (@Resource, @EJB, @PersistenceContext, etc.) or deployment descriptors, the container injects all the needed resources.

12.  3. If the instance has a method annotated with @PostContruct, the container invokes it.  4. The bean executes the requested call and stays in memory, waiting for subsequent client requests.  5. If the client remains idle for a period of time, the container invokes the method annotated with @PrePassivate, if any, and passivates the bean instance into a permanent storage.

13.  6. If the client invokes a passivated bean, the container activates it back to memory and invokes the method annotated with @PostActivate, if any.  7. If the client does not invoke a passivated bean instance for the session timeout period, it is destroyed by the container.  8. Alternatively to step 7, if the client calls a method annotated by @Remove, the container then invokes the method annotated with @PreDestroy, if any, and ends the life of the bean instance.

14. Stateful bean life cycle

15. 1.3.Callbacks The container lets you optionally provide your own business code when the state of the bean changes. The change from one state to another can be intercepted by the container to invoke methods annotated by one of the annotations.

17. A callback method is required to have the following signature: void (); The following rules apply to a callback method:  The method must not have any parameters and must return void.  The method must not throw a checked exception but can throw runtime exceptions. Throwing a runtime exception will roll back the transaction if one exists.

18.  The method can have public, private, protected, or package-level access, but must not be static or final.  A method may be annotated with multiple annotations. However, only one annotation of a given type may be present on a bean.  A callback method can access the beans’ environment entries.

21. 2.Interceptors  Around-Invoke Interceptors  Method Interceptors  Life-Cycle Interceptor

22. 2.1.Around-Invoke Interceptors Aspect-Oriented Programming (AOP)  AOP is a programming paradigm that separates cross-cutting concerns (concerns that cut across the application) from your business code.  Most applications have common code that is repeated across components. These could be technical concerns. These concerns can be applied automatically through AOP to your entire application or to a subset of it.

23. EJBs support AOP-like functionality by providing the ability to intercept method invocation through interceptors. Interceptors are automatically triggered by the container when an EJB method is invoked. A container intercepting a call and invoking interceptors

24. Interceptors fall into three types  Around-invoke interceptors  Business method interceptors  Life-cycle callback interceptors

25. 2.1.Around-Invoke Interceptors Adding a @javax.interceptor.AroundInvoke annotation in the bean itself. CustomerEJB Uses an Interceptor

26. Any client invocation to createCustomer() or findCustomerById() methods will be intercepted, and the logMethod() will be applied.

28. @AroundInvoke Object (InvocationContext ic) throws Exception  The following rules apply to an around-invoke method: The method can have public, private, protected, or package-level access, but must not be static or final. The method must have a javax.interceptor.InvocationContext parameter and must return Object, which is the result of the invoked target method (if the method returns void, it returns null). The method can throw a checked exception.

29. 2.2.Method Interceptors To isolate a cross-cutting concern into a separate class and tell the container to intercept the calls on several session beans. To specify an interceptor, you need to develop a separate class and instruct the container to apply it on a specific bean or bean’s method.

30. An Interceptor Class Logging a Method on Entering and Exiting

31. The LoggingInterceptor can now be wrapped transparently by any EJB interested in this interceptor. To do this, the bean needs to inform the container with a @javax.interceptor.Interceptors annotation.

32. If you want the calls to both methods to be intercepted, you can add the @Interceptors annotation either on both methods or on the bean itself.

33. If your bean has several methods, and you want to apply an interceptor to the entire bean except for a specific method, you can use the @javax.interceptor.ExcludeClassInterceptors annotation to exclude a call from being intercepted.

34. 2.3.Life-Cycle Interceptor With a callback annotation, you can inform the container to invoke a method at a certain life- cycle phase (@PostConstruct, @PrePassivate, @PostActivate, and @PreDestroy). Life-cycle interceptors allow you to isolate some code into a class and invoke it when a life-cycle event is triggered.

35. A Life-Cycle Interceptor Defining Two Methods

37. Reference Antonio Goncalves, Beginning Java EE 6 Platform with GlassFish 3, Chapter 8, Apress 2009