Estendendo o container JavaEE com Interceptors

LegoÉ inegável que a não-tão-nova versão 5 da especificação JavaEE veio numa hora mais do que necessária. Todo mundo parecia — e com razão — evitá-la ao máximo, pois seu uso demandava muito tempo e caixas de calmante.

Hoje, criar e manter uma aplicação com EJBs é relativamente simples. E, por este motivo, a adoção da tecnologia passou a ser mais expressiva, mesmo em projetos menores.

Alguns aspectos da especificação, entretanto, ainda deixam a desejar. Um exemplo seria a parte de injeção de dependências, que é limitada apenas a componentes gerenciados pelo container. O que isso quer dizer? Isso quer dizer que, para você poder tirar proveito do esquema de injeção de dependências, todos os seus componentes precisam ser EJBs.

Mas, nesta versão, os EJBs não são POJOs? Sim, mas ter de expor classes simples como EJBs — só para ganhar essa “injetabilidade” de presente — não parece correto. E, da mesma forma, espalhar instanciações de objetos pelos vários componentes da aplicação definitivamente também não parece.

Por isso, mostrarei a seguir um exemplo de como melhorar a parte de injeção de dependências para que possamos injetar POJOs declarativamente em objetos gerenciados. Como o Spring é (de longe) o framework mais conhecido, eu o usarei para me ajudar nesta tarefa.

O exemplo

Para demonstrar o efeito desejado, veja o trecho de código a seguir:

  1.  
  2. public interface Calculator {
  3.     int mult(int a, int b);
  4. }
  5. public class CalculatorImpl implements Calculator {
  6.     public int mult(int a, int b) {
  7.         return a*b;
  8.     }
  9. }
  10.  
  11. @Remote
  12. public interface MultiplicationRuler {
  13.     int[] rulerFor(int number, int from, int to);
  14. }
  15.  
  16. @Stateless
  17. public class MultiplicationRulerBean implements MultiplicationRuler {
  18.  
  19.     @InjectBean
  20.     private Calculator calculator;
  21.  
  22.     public int[] rulerFor(int number, int from, int to) {
  23.         int total = to-from+1;
  24.         int[] ruler = new int[total];
  25.  
  26.         for (int i = 0; i < total; i++) {
  27.             ruler[i] = calculator.mult(number, from++);
  28.         }
  29.         return ruler;
  30.     }
  31. }
  32.  

O objetivo aqui é implementar um componente POJO que multiplica dois números. Este componente é usado por um segundo — este sim um EJB — que fornece um método que funciona mais ou menos igual aquelas réguas de tabuada; o método recebe o número desejado e dois outros números que representam os limites da tabuada. Por exemplo, a chamada abaixo retorna os resultados da tabuada de 10, começando no número 1 e indo até o 15:

  1.  
  2. MultiplicationRulerBean ruler = new MultiplicationRulerBean();
  3. ruler.rulerFor(10,1,15);
  4.  

Note, na classe MultiplicationRulerBean, que o atributo Calculator está anotado com @InjectBean. Esta anotação serve para indicar que este campo representa uma dependência, e que esta dependência deve ser resolvida injetando-se uma instância de Calculator no campo anotado.

Usando o Spring para obter dependências

Segue um exemplo de arquivo de contexto appcontext-services.xml:

  1.  
  2. <?xml version="1.0" encoding="UTF-8"?>
  3. <beans>
  4.     <bean id="calculatorBean" class="CalculatorImpl" />
  5. </beans>
  6.  

Como nossa única dependência externa é uma instância de Calculator, então o arquivo se resume a apenas uma entrada <bean>. Agora, precisamos criar uma classe que será usada para obter os objetos declarados no arquivo mostrado:

  1.  
  2. public class SpringBeanContext {
  3.  
  4.     private static final SpringBeanContext instance;
  5.     static {
  6.         instance = new SpringBeanContext();
  7.     }
  8.  
  9.     private ApplicationContext context;
  10.  
  11.     private SpringBeanContext() {
  12.         context = new ClassPathXmlApplicationContext("META-INF/spring/appcontext-*.xml");
  13.     }
  14.  
  15.     public Object getBean(Class<?> clazz) {
  16.         Map<?,?> beans = context.getBeansOfType(clazz);
  17.         if (beans != null && beans.size() > 0) {
  18.             return beans.values().iterator().next();
  19.         }
  20.         throw new NoSuchBeanDefinitionException("There’s no bean of type " + clazz);
  21.     }
  22.  
  23.     public static SpringBeanContext getInstance() {
  24.         return instance; // retorna o singleton
  25.     }
  26. }
  27.  

Como apenas precisamos de um objeto da classe SpringBeanContext, esta foi programada como sendo um Singleton. Podemos ver que, quando o Singleton é instanciado, os arquivos de contexto — que seguem a convenção appcontext-[modulo].xml — são instanciados pelo Spring. Então, para que possamos recuperar objetos desse contexto, temos o método getBean().

Definindo a anotação @InjectBean

Agora, precisamos criar uma anotação que utilizaremos para indicar as dependências de nossos EJBs:

  1.  
  2. @Retention(RetentionPolicy.RUNTIME)
  3. public @interface InjectBean {}
  4.  

A anotação @InjectBean não possui parâmetros e é visível em Runtime, servirá para indicar os atributos que representam dependências. O Interceptor, que definiremos a seguir, irá procurar por essa anotação nos EJBs interceptados. Então, para cada campo anotado com essa anotação, o Interceptor irá obter o objeto correspondente do contexto do Spring e injetá-lo.

O Interceptor

Finalmente chegamos à classe que é responsável por fazer o serviço sujo: :P

  1.  
  2. public class SpringBeanInterceptor {
  3.  
  4.     @PostConstruct
  5.     public void injectSpringBean(InvocationContext context) throws Exception {
  6.         Object target = context.getTarget();
  7.         for (Field field : getAnnotatedFields(target.getClass())) {
  8.             injectBean(target, field);
  9.         }
  10.         context.proceed();
  11.     }
  12.  
  13.     protected List<Field> getAnnotatedFields(Class<?> clazz) {
  14.         List<Field> fields = new LinkedList<Field>();
  15.         for (Field field: clazz.getDeclaredFields()) {
  16.             if (field.getAnnotation(InjectBean.class) != null) {
  17.                 fields.add(field);
  18.             }
  19.         }
  20.         return fields;
  21.     }
  22.  
  23.     protected void injectBean(Object target, Field field) throws Exception {
  24.         Object bean = null;
  25.         bean = SpringBeanContext.getInstance().getBean(field.getType());
  26.         if (!field.isAccessible()) {
  27.             field.setAccessible(true);
  28.         }
  29.         field.set(target, bean);
  30.     }
  31. }
  32.  

Nada de outro mundo, huh? Perceba que usamos a anotação @PostConstruct, o que indica que o método anotado deve ser executado para um EJB após sua criação pelo container. Todo método interceptador deve retornar void e esperar um parâmetro do tipo InvocationContext. Neste método, utilizamos um pouco de reflexão para injetar o objeto fornecido pelo Spring. Por fim, para que outros possíveis Interceptors (e o próprio método sendo interceptado) possam ser invocados, chamamos InvocationContext.proceed().

Para finalizar o exemplo, nos resta associar este Interceptor com o EJB da aplicação. Uma forma simples de fazer isso seria através do uso da anotação @Interceptors nas classes e métodos desejados. Por exemplo:

  1.  
  2. @Stateless
  3. @Interceptors(SpringBeanInterceptor.class)
  4. public class MultiplicationRulerBean implements MultiplicationRuler {
  5.  
  6.     @InjectBean
  7.     private Calculator calculator;
  8.  
  9.     // …
  10. }
  11.  

Claro que, para este pequeno exemplo, esta abordagem poderia ser utilizada sem nenhum problema. O que acaba sendo chato é que, quando precisamos interceptar um número maior de classes e/ou métodos, esta solução acaba sendo trabalhosa.

Para resolver este problema, podemos fazer a configuração via XML, o que nos permite associar um Interceptor a vários EJBs através do uso de curingas. Para isso, basta modificar o arquivo ejb-jar.xml:

  1.  
  2. <?xml version="1.0" encoding="UTF-8"?>
  3. <ejb-jar>
  4.    <interceptors>
  5.       <interceptor>
  6.          <description>Spring-aware interceptor</description>
  7.          <interceptor-class>br.org.ourjug.service.interceptor.SpringBeanInterceptor</interceptor-class>
  8.       </interceptor>
  9.    </interceptors>
  10.  
  11.    <assembly-descriptor>
  12.       <interceptor-binding>
  13.          <ejb-name>*</ejb-name>
  14.          <interceptor-class>br.org.ourjug.service.interceptor.SpringBeanInterceptor</interceptor-class>
  15.       </interceptor-binding>
  16.    </assembly-descriptor>
  17. </ejb-jar>
  18.  

Neste caso, estamos associando o Interceptor a todos os EJBs, nos livrando de ter que configurar manualmente a associação do Interceptor com possíveis novos EJBs que o sistema venha a ter.

Conclusão

Venho observando que frameworks como o Spring e a especificação JavaEE estão trilhando caminhos diretamente opostos; enquando os primeiros estão crescendo descontroladamente e ficando cada vez mais complexos, o segundo está tirando a gordura e ficando mais simples de usar. Claro que cada desenvolvedor tem seus motivos para escolher um ou outro, mas eu particularmente já não vejo tanta vantagem em se adotar o Spring ao EJB. Por outro lado, penso ser mais interessante a junção dessas tecnologias de modo que cada uma contribua com o seu melhor.

Como vimos, a especificação JavaEE 5 — que foi projetada para ser estensível e fácil de usar — conta com componentes denominados Interceptors, que nos fornecem um recurso à la AOP, nos permitindo executar código em pontos bem definidos durante a execução da aplicação.

Eu nem preciso dizer que os Interceptors podem ser usados para outras coisas além da mostrada aqui. Apenas para citar um exemplo, o framework Seam usa Interceptors para implementar o que eles chamam de Bijeção — que permite que um componente qualquer possa receber/ejetar dependências de/para um contexto.

Os conceitos apresentados aqui podem ser adaptados para uso com outros frameworks de injeção de dependências, como Guice e PicoContainer.

Foto por: oskay

Tags: , , , , , , , , ,
1 de outubro de 2007 | programação