Citind cartea despre care v-am vorbit într-un articol anterior, am descoperit niște clase despre care nu mai auzisem până acum: interceptorii.
Prezentarea lor începe cu o scurtă introducere despre AOP, noțiune nouă pentru mine. După cum am înțeles, AOP înseamnă să “decorezi” logică refolosibilă, în general, cu diferite funcționalități, fără aduce modificări asupra logicii menționate. De exemplu, AOP ar putea fi transformarea ușoară a unui Session Bean într-un web service sau într-un RESTful service.
În Java EE “aspectele” sunt numite interceptori. Un interceptor este o clasă cu o metodă adnotată și are controlul complet asupra execuției unei metode. Un interceptor este “atașat” unei clase cu ajutorul adnotării @Interceptors({interceptori}). Între acolade este o listă de clase de interceptori.
Iata un exemplu scurt de interceptor:
1: public class InterceptorDeTest {
2:
3: @AroundInvoke
4: public Object interceptM(InvocationContext ic) {
5:
6: //fă ceva
7: return ic.proceed();
8: }
9: }
Și o clasă care are atașat un interceptor:
1: @Stateless
2: @Interceptors({InterceptorDeTest.class})
3: public class ClasaDeTest{
4: public String helloWorld() {
5: return "HelloWorld!";
6: }
7: }
În momentul în care este apelată metoda helloWorld firul execuției va trece mai întâi prin interceptor. Acesta execută prelucrările sale și apelează metoda proceed() care are ca efect trecerea la executarea codului următorului interceptor din listă, dacă există, sau a metodei interceptate (în cazul nostru, metoda helloWorld()).
Interceptorii pot fi folosiți pentru diferite inițializări sau validări înainte sau după execuția unei metode. În cartea lui Adam Bien e și un exemplu cu interceptori în care se pot redenumi firele de execuție a unei aplicații în funcție de metoda pe care o execută, pentru o mai bună observare într-un profiler sau într-un dump, scăpând astfel de numele random și lipsite de înțeles date firelor de execuție.
PS: Un articol general despre utilizarea interceptorilor și cel cu redenumirea thread-urilor.
) o 
