SCBCD - Más interceptores

(Imagen: Claude Monet - Desayuno sobre la hierba)

Después de ver los interceptores de métodos de negocio, ahora veremos un poco de los interceptores del ciclo de vida. ¿Recuerdan los métodos del ciclo de vida? Pues dependen del tipo de Bean del que estemos hablando. Pueden ser PostConstruct, PreDestroy (para Stateful y Stateless SB), PostPassivate, PrePassivate (para Stateful SB), y son invocados por el contenedor antes después que suceda un determinado evento del ciclo de vida.

Pero este es un post de interceptores y no del siclo de vida, que eso ya lo vimos antes, Este tipo de interceptores, como sus primos de métodos de negocio, pueden ser definidos dentro de la misma clase del bean o en una clase interceptora aparte; y para identificar los métodos interceptores usamos las mismas anotaciones que para definir a los métodos del ciclo de vida en sí (@PostConstruct. @PreDestroy, @PostActivate, @PrePassivate ; y sus equivalentes en el descriptor de despliegue post-construct, pre-destroy, post-activate y pre-passivate).

En una misma clase inteceptora pueden convivir interceptores del ciclo de vida (lifecycle callback interceptor... mejor voy poniendo el nombre en inglés para el día del examen) e interceptores de métodos de negocio. Sin pelearse. Con la condición que un evento de ciclo de vida, sólamente puede tener un método interceptor ; pero un método interceptor puede interceptar múltiples eventos del ciclo de vida (por ej. PostConstruct y PostActivate)

Si definimos los interceptores del ciclo de vida en una clase interceptora, el método tiene esta forma:

void nombreDelMetodo (InvocationContext ic)

En cambio, si los definimos en la misma clase del bean sería:

void nombreDelMetodo ()

Y un método interceptor del ciclo de vida no puede ser ni final ni static, como en los de negocio. Pero ya mucha prosa, y mejor veamos un poco de código. Definiremos el Stateful SB ShoppingCartBean, y sus interceptores para los métodos @PostConstruct y @PreDestroy en la clase interceptora MyInterceptor (disculpando siempre la indentación, que blogger no me ayuda):

@Stateful
public class ShoppingCartBean implements ShoppingCart {
private float total;
private Vector productCodes;
public int someShoppingMethod() { ...}
@PreDestroy
void endShoppingCart(){ ... }
}

public class MyInterceptor{
@PostConstruct
public void someMethod (InvocationContext ctx){
...
ctx.proceed();
...
}
@PreDestroy
public void anotherMethod(InvocationContext ctx){
...
ctx.proceed();
...
}
}

Otra cosa pendiente (aunque son muchas cosas pendientes en interceptores...creo que da pa un par de posts) son los interceptores por defecto. Existe la posibilidad de aplicarle interceptores a todos componentes dentro de un ejb-jar; pero para esto no podemos hacer uso de nuestras amistosas y simples anotaciones; por lo que se tiene que recurrir al descriptor de despliegue para hacerlo. Estos interceptores se llaman interceptores por defecto, y son invocados antes que cualquier otro interceptor definido para el bean.

Pero, siempre está la posibilidad de arrepentirse. Si por ahí no quieres que a tu tu bean se le apliquen los interceptores por defector definidos en el descriptor de despliegue, pues se puede recurrir a la anotación @ExcludeDefaultInterceptors, o a su equivalente exclude-default-interceptors en el descriptor de despliegue.

Y como pensaba, se necesitará un post más para esto. Hasta mañana...!!