Se você já leu algum dos artigos anteriores desta série, poderá lembrar que eu estou desenvolvendo uma aplicação pequena, mas de uso quase comercial que procura por exceções em arquivos de log. Você também poderá se lembrar de que agora eu tenho uma classe que contém um monte de resultados que precisarão ser enviados para todos os interessados. Isso será feito através da implementação de minha interface Publisher mostrada abaixo.

public interface Publisher {

  public <T> boolean publish(T report);
}

Se você se recorda, a exigência foi:

7. Publicar o relatório usando e-mail ou alguma outra técnica.

Neste artigo, estou lidando com a parte concreta da exigência: o envio de um relatório por e-mail. Como trata-se de um aplicativo Spring, a maneira mais simples de enviar um e-mail é usar as classes de e-mail do Spring. Ao contrário daquelas classes fiéis à API do Spring, tais como classes template como a JdbcTemplate e a JmsTemplate, as classes de e-mail do Spring são baseadas em torno de um par de interfaces e suas implementações. As interfaces são:

1. MailSender
2. JavaMailSender estende MailSender
3. MailMessage

… e as implementações são:

1. JavaMailSenderImpl implementa JavaMailSender
2. SimpleMailMessage implementa MailMessage

Note que essas são as classes “básicas”. Você pode enviar e-mails mais bonitos, com conteúdo mais sofisticado, usando classes como: MimeMailMessage, MimeMailMessageHelper, ConfigurableMimeFileTypeMap e MimeMessagePreparator.

Antes de descer para algum código, há a pequena questão de configuração do projeto. Para usar as classes de e-mail do Spring, você precisa do seguinte entrada no seu arquivo POM do Maven:

<dependency>
    <groupId>javax.mail</groupId>
    <artifactId>mail</artifactId>
    <version>1.4</version>
</dependency>

Isso garante que as classes Java Mail subjacentes estarão disponíveis para seu aplicativo.

Uma vez que as classes Java Mail forem configuradas no build, a próxima coisa a fazer é configurar o XML do Spring.

<!-- Spring mail configuration -->

     <bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
          <property name="host" value="${mail.smtp.host}"/>
     </bean>
    
     <!-- this is a template message that we can pre-load with default state -->
     <bean id="mailMessage" class="org.springframework.mail.SimpleMailMessage">
          <property name="to" value="${mail.to}"></property>
            <property name="from" value="${mail.from}"/>
            <property name="subject" value="${mail.subject}"/>
     </bean>

Para os fins desse aplicativo, que é o envio de relatórios automatizados, eu incluí dois Spring beans: mailSender e mailMessage. mailSender é um exemplo de JavaMailSenderImpl configurado para usar um servidor de correio SMTP específico, com todas as outras propriedades, tais como a porta TCP, deixadas como padrão.

O segundo bean Spring é mailMessage, uma instância de SimpleMailMessage. Desta vez, eu já pré-configurei três propriedades: ‘to’, ‘from’ e ‘subject’. Isto porque, uma vez sendo mensagens automatizadas, esses valores são sempre idênticos.

Você pode, claro, configurá-las programaticamente, algo que você provavelmente terá que fazer se estivesse criando um GUI de e-mail.

Todo esse XML torna a implementação do Publisher muito mais simples.

@Service
public class EmailPublisher implements Publisher {

  private static final Logger logger = LoggerFactory.getLogger(EmailPublisher.class);

  @Autowired
  private MailSender mailSender;

  @Autowired
  private SimpleMailMessage mailMessage;

  @Override
  public <T> boolean publish(T report) {

    logger.debug("Sending report by email...");
    boolean retVal = false;
    try {
      String message = (String) report;
      mailMessage.setText(message);
      mailSender.send(mailMessage);
      retVal = true;
    } catch (Exception e) {
      logger.error("Can't send email... " + e.getMessage(), e);
    }

    return retVal;
  }

}

A classe Publisher contém um método: publsh, o que leva um argumento genérico T report. Isso, como eu disse antes, tem que ser do mesmo tipo que o argumento retornado pela implementação Formatter do meu artigo anterior.

Existem realmente apenas três etapas desse código a se considerar: primeiro, o T genérico é convertido em ums String (este é o lugar onde tudo isso vai cair se o argumento T report não for uma String.

O segundo passo é anexar o texto do e-mail para o mailMessage e, em seguida, enviar a mensagem usando mailSender.send (…).

O passo final é preencher o Publisher, retornando verdadeiro, a menos que o e-mail não seja enviado, caso em que a exceção é registrada e o valor de retorno é falso.

Em termos de escrever o código, isso é tudo. O próximo passo é resolver o agendamento, para que o relatório seja gerado na hora certa, mas falarei sobre isso mais tarde…

O código para este artigo está disponível no Github em: https://github.com/roghughe/captaindebug/tree/master/error-track.

Se você quiser olhar em outros artigos desta série, dê uma olhada aqui:

• Rastreamento de exceções em aplicativos com o Spring – Parte 01
• Rastreamento de exceções em aplicativos com o Spring: padrão de busca – Parte 02
• Rastreamento de exceções em aplicativos com o Spring: estratégia e pacote privado – Parte 03

***

Artigo traduzido pela Redação iMasters com autorização do autor. Publicado originalmente em http://www.captaindebug.com/2014/04/tracking-exceptions-part-4-springs-mail.html#.U8XkG_4yDYV