Habilitando o modo de debug

Existem duas maneiras de se habilitar o modo de debug no Glassfish: através do painel de administração ou durante a inicialização do domínio.

Para habilitar o modo de debug por padrão, através do painel de administração, basta marcar o campo Debug na tela JVM Settings e clicar em Save:

Habilitando o modo de Debug

Basta reiniciar o domínio para ver que o servidor abre a porta 9009, através da qual podemos conectar um debugger:

asadmin start-domain domain1

Eis um resumo da saída ecoada pelo Glassfish:

Starting Domain domain1, please wait.
Log redirected to .../server.log.
Redirecting output to .../server.log
Listening for transport dt_socket at address: 9009
Application server is listening at address 9009 for debugger to attach using transport dt_socket
...

A outra forma de se habilitar o modo de debug é fornecer o parâmetro --debug ao iniciar o domínio. Por exemplo:

asadmin start-domain --debug domain1

Conectando o debugger da IDE ao servidor

Agora, basta usar os recursos de debugging presentes na sua IDE Java para debugar o código. Por exemplo, se você usa o NetBeans 5.5, basta acessar o menu Run – Attach Debugger… e o configurar da seguinte forma:

Anexando o debugger do NetBeans

O procedimento é semelhante em outras IDEs Java.

Pronto! Feito isso, é só colocar os breakpoints e disparar a execução do código problemático.

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:

public interface Calculator {
    int mult(int a, int b);
}
 
public class CalculatorImpl implements Calculator {
    public int mult(int a, int b) {
        return a*b;
    }
}
 
@Remote
public interface MultiplicationRuler {
    int[] rulerFor(int number, int from, int to);
}
 
@Stateless
public class MultiplicationRulerBean implements MultiplicationRuler {
 
    @InjectBean
    private Calculator calculator;
 
    public int[] rulerFor(int number, int from, int to) {
        int total = to-from+1;
        int[] ruler = new int[total];
 
        for (int i = 0; i < total; i++) {
            ruler[i] = calculator.mult(number, from++);
        }
        return ruler;
    }
}

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:

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

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

Usando o Spring para obter dependências

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

<?xml version="1.0" encoding="UTF-8"?>
<beans>
    <bean id="calculatorBean" class="CalculatorImpl" />
</beans>

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:

public class SpringBeanContext {
 
    private static final SpringBeanContext instance;
    static {
        instance = new SpringBeanContext();
    }
 
    private ApplicationContext context;
 
    private SpringBeanContext() {
        context = new ClassPathXmlApplicationContext("META-INF/spring/appcontext-*.xml");
    }
 
    public Object getBean(Class<?> clazz) {
        Map<?,?> beans = context.getBeansOfType(clazz);
        if (beans != null && beans.size() > 0) {
            return beans.values().iterator().next();
        }
        throw new NoSuchBeanDefinitionException("There's no bean of type " + clazz);
    }
 
    public static SpringBeanContext getInstance() {
        return instance; // retorna o singleton
    }
}

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 carregados pelo Spring. O método getBean() foi criado para que possamos obter objetos gerenciados pelo Spring.

Definindo a anotação @InjectBean

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

@Retention(RetentionPolicy.RUNTIME)
public @interface InjectBean {}

A anotação @InjectBean, que 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 trabalho pesado:

public class SpringBeanInterceptor {
 
    @PostConstruct
    public void injectSpringBean(InvocationContext context) throws Exception {
        Object target = context.getTarget();
        for (Field field : getAnnotatedFields(target.getClass())) {
            injectBean(target, field);
        }
        context.proceed();
    }
 
    protected List<Field> getAnnotatedFields(Class<?> clazz) {
        List<Field> fields = new LinkedList<Field>();
        for (Field field: clazz.getDeclaredFields()) {
            if (field.getAnnotation(InjectBean.class) != null) {
                fields.add(field);
            }
        }
        return fields;
    }
 
    protected void injectBean(Object target, Field field) throws Exception {
        Object bean = null;
        bean = SpringBeanContext.getInstance().getBean(field.getType());
        if (!field.isAccessible()) {
            field.setAccessible(true);
        }
        field.set(target, bean);
    }
}

Nada de outro mundo, não? 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 Reflection 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:

@Stateless
@Interceptors(SpringBeanInterceptor.class)
public class MultiplicationRulerBean implements MultiplicationRuler {
 
    @InjectBean
    private Calculator calculator;
 
    // ...
}

Claro que, para este pequeno exemplo, esta abordagem poderia ser utilizada sem nenhum problema. Porém, definir o interceptor dessa forma é muito trabalhoso em situações onde temos muitos EJBs.

Para que possamos evitar o uso repetido da anotação @Interceptors, 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:

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar>
    <interceptors>
        <interceptor>
            <description>Spring-aware interceptor</description>
            <interceptor-class>com.destaquenet.tutorial.interceptor.SpringBeanInterceptor</interceptor-class>
        </interceptor>
    </interceptors>
 
    <assembly-descriptor>
        <interceptor-binding>
            <ejb-name>*</ejb-name>
            <interceptor-class>com.destaquenet.tutorial.interceptor.SpringBeanInterceptor</interceptor-class>
        </interceptor-binding>
    </assembly-descriptor>
</ejb-jar>

Neste caso, estamos associando o interceptor automaticamente a todos os EJBs, nos livrando de ter que configurar manualmente a associação do interceptor com possíveis novos EJBs que a aplicação 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 seus autores 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.

Apesar de dar conta do recado, a referida API conta com alguns problemas bastante complicados, dentre os quais eu destaco o design (horrível, diga-se de passagem) de suas classes e interfaces, que parecem fazer o possível para dificultar a testabilidade dos seus “clientes”.

Entendendo o problema

Uma técnica de testes bastante utilizada atualmente consiste no uso de frameworks para Mocking de objetos. Esses frameworks permitem testar código que faça uso de quaisquer recursos externos e que são, por natureza, difíceis de testar. Classes que necessitam acessar recursos de infraestrutura, como arquivos em disco, impressoras e bancos de dados, são ótimas candidatas a serem “mockadas”.

O grande problema é que, para que tais frameworks possam ser usados, o código a ser “mockado” tem de seguir algumas regrinhas de codificação. Por exemplo, alguns frameworks não conseguem “mockar” uma classe concreta; outros por sua vez, conseguem “mockar” classes concretas desde que elas não sejam finais.

Bom, só para resumir, o ideal seria que o código todo — tanto das classes de infraestrutura quanto das classes que fazem uso das primeiras — seja orientado a interfaces. Isso é necessário pois grande parte dos frameworks Java para Mocking de objetos se apoiam na API Proxy para fazer seu trabalho e, como muitos já devem saber, não é possível criar proxies de classes contretas através do uso dessa API.

Para ilustrar melhor o que estou tentando dizer, segue um exemplo de código que envia um e-mail com a API JavaMail:

Properties props = System.getProperties();
props.put("mail.smtp.host", "smtp.middlenet.com");
Session session = Session.getDefaultInstance(props);
 
MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress("Frodo", "frodo@theshire.com"));
message.addRecipient(RecipientType.TO, new InternetAddress("Gandalf", "blog@gandalf.com"));
message.setSubject("Be careful");
message.setText("Sauron is looking for the One Ring!");
 
Transport.send(message);

Veja, por exemplo, que o objeto Session é obtido através da chamada ao método estático getDefaultInstance(); de modo semelhante, temos também a chamada ao método estático send(), na última linha do código. Ah claro, sem contar que a classe Session é final! Como podemos fazer para testar o que vai para e o que volta da API JavaMail?

Uma solução

Apesar de não ser possível testar o código anterior usando um framework para Mocking de objetos “tradicional”, felizmente há uma luz no fim do túnel.

Uma opção bastante interessante é a utilização de um servidor SMTP “de mentirinha”, para o qual as mensagens são enviadas. Assim, podemos verificar o que acontece quando o código “conversa” com um servidor.

A boa notícia é que não precisamos implementar um servidor SMTP do zero! Uma opção de servidor como esse é o SubEthaSMTP Wiser (!). Com ele, podemos subir um servidor SMTP numa porta qualquer. Então, basta configurar nossa classe de envio de e-mails de modo que tal servidor seja usado no lugar do servidor de produção. As mensagens enviadas a esse servidor podem ser consultadas e verificadas através de asserções no código de testes.

Usando o SubEthaSMTP Wiser com o Maven

Se você usa o Maven, então basta adicionar a dependência no seu POM para tornar as classes do SubEthaSMTP Wiser disponíveis no seu ambiente de testes:

<dependency>
    <groupId>org.subethamail</groupId>
    <artifactId>subethasmtp-wiser</artifactId>
    <version>1.2</version>
    <scope>test</scope>
</dependency>

Talvez você veja uma mensagem de erro indicando que a dependência javax.activation:1.0.2 não foi encontrada. Se isso acontecer, você deverá baixar essa versão do site da Sun e fazer a instalação manualmente no seu repositório local. (o Maven informa qual comando rodar para fazer essa instalação).

Exemplo de uso

Usar esse servidor é uma tarefa bem simples. A maior dificuldade é configurar a nossa classe de envio de e-mails para se conectar nesse servidor em vez do servidor de produção. Veja só:

EmailMessage message = ... ; // objeto com os dados da mensagem
 
/* inicia o servidor */
Wiser server = new Wiser();
server.setPort(2500);
server.start();
 
/* configura o cliente */
Properties prop = System.getProperties();
prop.setProperty("mail.smtp.host", "localhost");
prop.setProperty("mail.smtp.port", "2500");
session = Session.getDefaultInstance(prop);
 
EmailSender sender = new JavaMailEmailSender(session); // minha classe
sender.send(message); // o parâmetro contém os dados de envio e corpo da mensagem
 
server.stop(); // pára o servidor
 
/* verifica o que foi enviado */
assertEquals(1, server.getMessages().size());
assertEquals("Sauron is looking for the One Ring!", server.getMessages().get(1).getMimeMessage().getContent());

Nas primeiras linhas iniciamos o servidor. Em seguida, configuramos a Session do JavaMail para que ela se conecte ao nosso servidor “de mentirinha”. A partir desse ponto, tudo funciona como de costume, com a vantagem de podermos realizar asserções para verificar se as mensagens chegaram ao servidor da forma esperada. Isso é especialmente útil quando utilizamos algum tipo de processador de templates durante o envio das mensagens, permitindo que possamos testar o que exatamente chegou ao servidor.

Para quem não gostou dessa abordagem…

Existe ainda uma outra opção que podemos utilizar para testar classes que fazem uso do JavaMail. Trata-se de um projeto chamado mock-javamail que, ao contrário do SubEthaSMTP Wiser, não usa um servidor SMTP “de mentirinha” para receber as mensagens; o que ele faz é configurar o JavaMail em runtime de modo que as mensagens enviadas sejam armazenadas em memória.

Usando o mock-javamail com o Maven

Primeiramente precisamos adicionar o repositório Maven do java.net:

<repositories>
    <repository>
        <id>java.net2</id>
        <url>http://download.java.net/maven/2</url>
    </repository>
</repositories>

Feito isso, basta declarar a dependência:

<dependency>
    <groupId>org.jvnet.mock-javamail</groupId>
    <artifactId>mock-javamail</artifactId>
    <version>1.3</version>
</dependency>

Exemplo de uso

Este projeto é mais simples de se utilizar que o SubEthaSMTP Wiser justamente pelo fato de não precisarmos iniciar um servidor SMTP. Isso fica evidente no exemplo abaixo, que é uma adaptação do código anterior:

EmailMessage message = ... ; // objeto com os dados da mensagem
 
/* configura o cliente */
Properties prop = System.getProperties();
prop.setProperty("mail.smtp.host", "localhost");
prop.setProperty("mail.smtp.port", "2500");
session = Session.getDefaultInstance(prop);
 
EmailSender sender = new JavaMailEmailSender(session); // minha classe
sender.send(message); // o parâmetro contém os dados de envio e corpo da mensagem
 
/* verifica o que foi enviado */
assertEquals(1, Mailbox.get("gandalf@asskickers.com").size());
assertEquals("Sauron is looking for the One Ring!", Mailbox.get("gandalf@asskickers.com").get(0).getContent());