Tá chegando a INFOESTE 2012 pessoal!

A faculdade na qual eu me formei (FIPP) anualmente promove a INFOESTE, um evento com a duração de uma semana composto por diversas atrações relacionadas a tecnologia e informática como: maratona de programação, palestras e mesas redondas, vários minicursos, competição de web design, festa de instalação linux entre outros.

Este ano estarei ministrando o minicurso Introdução ao Spring Framework nos dias 17 e 18/05.

Quem participar vai ter uma pequena introdução sobre o tal do Spring, porque foi criado, como funciona a injeção de dependência e alguns frameworks da família Spring.

Começaremos aprendendo o mais básico e mais poderoso, a injeção de dependência, como ela era no princípio (através de XMLs), como evoluiu (@Autowired) e como está hoje (@Value, @Configuration, …).

Depois iremos desenvolver o QuizMVC, um quiz web utilizando Spring MVC e Spring Security. Desenvolveremos a aplicação completa, desde o CRUD de perguntas do quiz até o controle de acesso através de usuários persistidos em um banco de dados.

Por fim veremos como utilizar o Spring Roo (aposto que todo mundo vai adorar! hehehe) e – dependendo do tempo – iremos dar uma passadinha por cima de alguns outros frameworks como Spring BlazeDS Integration e Spring for Android.

Quem participar vai sair conhecendo pelo menos um pouco por cima o que é o Spring e como desenvolver uma aplicação web utilizando as facilidades que ele provê.

Abraços e até a infoeste então pessoal!

Saab.

Algo um tanto quanto comum em aplicações de médio / grande porte é o agendamento de tarefas.

Exemplos: toda madrugada atualizar alguns registros que dependam de data (ex: contratos atrasados), todos os dias às 20:00h enviar e-mail para os clientes que façam aniversários no dia, todo domingo das 18:00h até  23:59h atualizar o data warehouse (DW) da empresa com as vendas da semana.

Surgem muitas e muitas idéias e possibilidades quando pensamos no agendamento de tarefas. Legal, na visão do cliente e do seu gerente é uma grande maravilha (de fato, realmente é) mas ai chega um requisito na tua mesa te falando pra magicamente fazer isso “pra ontem”.

E agora? Agora o Java Simples está aqui pra te ajudar!

Vamos criar um projeto utilizando o agendamento de tarefas provido pelo Spring pois é simples de usar e poderoso o suficiente para resolver a maioria das necessidades quando o assunto é agendamento.

Por que não utilizar o Quartz?

Pois  é uma ferramenta incrivelmente robusta que provê funcionalidades como suporte para clusterização e transações JTA. Na boa, na maioria dos casos o Quartz é um ferrari pra comprar pão na esquina – como dizia uma professora que tive.

Vamos manter as coisas simples até que seja realmente necessário complicá-las!

* Mas eu confesso, a imagem do post é do site do Quartz… hehehe

Nossa aplicação

Vamos imaginar que você trabalha em uma startup na área de desenvolvimento de software e o seu chefe te escolheu para criar uma pequena aplicação para ele poder ter mais controle sobre a empresa.

Nessa empresa é utilizado o Scrum como processo de desenvolvimento. Sempre antes de ir embora os desenvolvedores acessam o sistema de controle da empresa para marcar quais atividades estão concluídas, quais estão em andamento e quais ainda estão paradas.

Existem algumas máquinas que o chefe gosta de chamar de servidores (dá um desconto vai, está no começo ainda) pois elas executam os papéis de servidores de firewall, banco de dados (onde roda o mysql) e de aplicações (onde roda o tomcat).

O chefe quer chegar todo dia de manhã e a primeira coisa que ele quer fazer é verificar um e-mail enviado pelo novo sistema com o andamento das tarefas do dia anterior, inclusive, ele quer que no e-mail apareça em vermelho o nome das pessoas que não atualizaram o status das tarefas no dia anterior pra ele poder ter uma “conversinha” com elas. hehehehe

Outra coisa que acontece bastante na empresa é que os servidores costumar cair. Sempre que isso acontece você pensa: “Eu já disse que aquelas máquina não são servidores! Viu só! Não aguentam a carga!”.

Tudo bem, todos concordamos que essa situação não é muito legal mas até a empresa arranjar mais alguns clientes o chefe disse que não vai trocar nada. Por causa dessas quedas frequentes ele também quer que toda vez que algum servidor pare de funcionar ele receba um email avisando isso.

Uma última necessidade é que a aplicação seja web e seja possível o chefe saber qual servidor parou, quando o e-mail foi enviado, enfim, um histórico de tudo que o seu programa fez. Ele quer isso para que ele possa verificar tudo através do celular.

Recapitulando então, a aplicação vai ser web, vai ter que enviar um e-mail bem cedo com o andamento das tarefas do dia anterior e  toda vez que algum servidor cair ele quer receber um e-mail informando.

Legal, agora que já temos o nosso escopo vamos ao trabalho!

O projeto

No fim desse post teremos um projeto com essa estrutura:

Após o projeto web ter sido criado e todas as dependências corretamente referenciadas vamos dar uma olhada no web.xml:

<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
	version="3.0">
 
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>WEB-INF/applicationContext.xml</param-value>
	</context-param>
 
	<listener>
		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>
 
	<welcome-file-list>
		<welcome-file>index.jsp</welcome-file>
	</welcome-file-list>
</web-app>

Apenas informamos o listener para carregar o Spring assim que a aplicação for iniciada e definimos o arquivo para ser compatível com servlets 3.0 .

O arquivo de configuração do Spring também não tem nenhum segredo:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context"
	xmlns:task="http://www.springframework.org/schema/task"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd
		http://www.springframework.org/schema/task http://www.springframework.org/schema/task/spring-task-3.1.xsd">
 
	<context:component-scan base-package="br.blog.javasimples.spring.agendamento" />
 
	<task:annotation-driven />
 
</beans>

Através da tag <context:component-scan> o Spring vai procurar sozinho pelos beans que ele deve gerenciar (como explicado no post Injeção de dependências via anotações).

E através da tag <task:annotation-driven /> o Spring também vai procurar automaticamente por tarefas agendadas e vai ficar responsável pela execução delas.

A interface Web

Nossa aplicação web vai usar uma estrutura bem simples (servlet + JSP) apenas para não alongar muito o post.

A única página que vamos desenvolver vai mostrar um histórico de tudo que a aplicação já fez, vamos ver como ficaria a página index.jsp:

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
	pageEncoding="ISO-8859-1"%>
<%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Tarefas Agendadas</title>
</head>
<body>
	<p>
		<a href="./historico">Recarregar...</a>
	</p>
	<p>Tarefas executadas:</p>
 
	<c:if test="${historico != null && historico.size() > 0}">
		<ul>
			<c:forEach var="hist" items="${historico}">
				<li>${hist}</li>
			</c:forEach>
		</ul>
	</c:if>
</body>
</html>

Um simples JSP que vai mostrar todos os registros de um histórico que um servlet irá retornar. Vamos dar uma conferida no servlet:

/**
 * Servlet para a recuperação do histórico de todas as tarefas executadas.
 *
 * @author Felipe
 */
@WebServlet(value="/historico")
public class HistoricoServlet extends HttpServlet {
 
	private static final long serialVersionUID = -3612078136798710447L;
 
	@Autowired
	private HistoricoExecucao historicoExecucao;
 
	@Override
	public void init(ServletConfig config) throws ServletException {
		super.init(config);
		SpringBeanAutowiringSupport.processInjectionBasedOnServletContext(this, config.getServletContext());
	}
 
	@Override
	protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
		req.setAttribute("historico", historicoExecucao.getHistorico());
		RequestDispatcher dispatcher = req.getRequestDispatcher("index.jsp");
		dispatcher.forward(req, resp);
	}
 
}

Toda vez que chegar uma requisição GET na URL /historico da nossa aplicação o servlet vai carregar o histórico através do bean historicoExecucao e vai renderizar a página index.jsp para o usuário saber quais foram as últimas tarefas executadas.

Por que a sobrescrita do método init(ServletConfig)?

Bom… nosso servlet possui um atributo que precisa ser injetado pelo Spring; o Spring só consegue injetar dependências em beans que estão sendo gerenciador por ele, ou seja, os beans devem estar no contexto do Spring para terem suas dependências injetadas; em tempo de execução quem vai instanciar o servlet é o container web (ex: tomcat) e não o Spring;

Sendo assim, quando o servlet é instanciado ele não está no contexto do Spring e consequentemente não terá suas dependências injetadas. Para ter as suas dependências injetadas nós invocamos o método estático  processInjectionBasedOnServletContext(Object, ServletContext) da classe SpringBeanAutowiringSupport para o Spring fazer esse favor para nós.

Vamos ver então o que esse historicoExecucao faz:

/**
 * Classe que contém o histórico de execução de todas as tarefas.
 *
 * @author Felipe
 */
@Component
public class HistoricoExecucao {
 
	private List historico;
 
	private SimpleDateFormat simpleDateFormat;
 
	public HistoricoExecucao() {
		historico = new ArrayList();
		simpleDateFormat = new SimpleDateFormat("dd/MM/yyyy - HH:mm:ss");
	}
 
	public void novoHistorico(String hist) {
		historico.add(simpleDateFormat.format(new Date()) + ": " + hist);
	}
 
	public List getHistorico() {
		return historico;
	}
 
}

É uma classe que simplesmente mantém um histórico de mensagens em memória. Vamos utilizar ela para manter um histórico de todas as tarefas que foram executadas pela nossa aplicação.

Agendamento de tarefas

Uma vez que o servlet está pronto vamos começar a agendar as tarefas.

Vamos começar com a classe responsável por verificar o status dos servidores.

Tudo o que vamos fazer é realizar um ping nos servidores para verificar se eles estão online. Como você é um desenvolvedor esperto você pensou: “Bom.. pode ser que em um outro momento seja necessário utilizar a funcionalidade de dar ping em alguma máquina ou até mesmo recuperar os IPs dos servidores… Já sei! Vou colocar em uma classe utilitária!”

Boa! E com isso temos a classe InfraUtils:

/**
 * Classe utilitária para tarefas relacionadas a infra estrutura.
 *
 * @author Felipe
 */
public class InfraUtils {
 
	public static final String IP_SERVIDOR_FIREWALL = "192.168.0.20";
	public static final String IP_SERVIDOR_BD = "192.168.0.21";
	public static final String IP_SERVIDOR_APLICACAO = "192.168.0.22";
 
	public static final String[] IPS_SERVIDORES = {IP_SERVIDOR_FIREWALL, IP_SERVIDOR_BD, IP_SERVIDOR_APLICACAO}; 
 
	public static boolean pingaServidor(String ip) {
		// Simula o ping
		try {
			Thread.sleep(3500);
		} catch (InterruptedException e) {
			Thread.currentThread().interrupt();
		}
 
		// Verifica o resultado do ping
		if (((int) (Math.random() * 10))

Agora que já temos a estrutura para realizar um ping – ou pelo menos simular um – vamos para as tarefas mesmo. Vamos começar criando uma interface para padronizar todas as nossas tarefas:

/**
 * Contrato que define os métodos necessários para uma tarefa.
 *
 * @author Felipe
 */
public interface Tarefa {
	void executar(Object... args);
}

A única coisa que uma Tarefa vai ter que fazer é ser executada. Simples assim.

Agora que já sabemos como vai ser uma tarefa podemos criar a TarefaPingServidores:

/**
 * Tarefa para pingar os servidores e verificar se estão ativos ou não.
 *
 * @author Felipe
 */
@Component
public class TarefaPingServidores implements Tarefa {
 
	@Autowired
	private HistoricoExecucao historicoExecucao;
 
	@Override
	public void executar(Object... args) {
		if (args == null || args.length == 0) {
			throw new IllegalArgumentException("A tarefa deve receber o IP do servidor a ser pingado!");
		}
 
		String ipServidor = args[0].toString();
		String nomeServidor = "Servidor de " + InfraUtils.traduzirIp(ipServidor);
		String historico = "";
 
		if (InfraUtils.pingaServidor(ipServidor)) {
			historico = nomeServidor + " pingado com sucesso.";
		} else {
			historico = nomeServidor + " caiu!";
			EmailUtils.enviaEmail(EmailUtils.EMAIL_CHEFE, historico);
		}
 
		historicoExecucao.novoHistorico(historico);
	}
 
}

Nossa tarefa segue uma lógica um tanto quanto simples não? Garante que foi enviado o IP do servidor a ser pingado, pega o nome do servidor a partir do seu IP, se não pingou com sucesso, ou seja, se o servidor caiu envia um e-mail para o chefe e por fim registra o que aconteceu no histórico.

Como envia o e-mail? Sinto muito mas não vai ser hoje que vamos ver… hehehehe

/**
 * Classe utilitária para o envio de emails.
 *
 * @author Felipe
 */
public class EmailUtils {
 
	public static final String EMAIL_CHEFE = "chefe@empresa.com.br";
 
	public static void enviaEmail(String para, String mensagem) {
		System.out.println(String.format("Email enviado para %s com a mensagem \"%s\"",
							para,
							mensagem));
	}
 
}

A anotação @Scheduled

Ok, temos a nossa primeira tarefa pronta. Mas como vamos fazer ela ser executada a cada 5 segundos?

Vamos dar uma olhada na classe TarefasAgendadas que é onde vão ficar todas os nossos agendamentos para a execução de tarefas:

/**
 * Classe que contém todas as tarefas agendadas do sistema.
 *
 * @author Felipe
 */
@Component
public class TarefasAgendadas {
 
	@Autowired
	@Qualifier("tarefaPingServidores")
	private Tarefa pingarServidores;
 
	@Scheduled(fixedDelay=5000)
	private void pingarServidores() {
		String[] servidores = InfraUtils.IPS_SERVIDORES;
		for (int i = 0; i < servidores.length; i++) {
			pingarServidores.executar(servidores[i]);
		}
	}
}

A primeira coisa que precisamos prestar atenção é a classe está anotada com @Component, ou seja, ela será um bean que o Spring vai descobrir automaticamente. Uma vez que o Spring está gerenciando esse bean e encontra a anotação @Scheduled ele já prepara toda a infra estrutura necessária para realizar essa tarefa de acordo com o agendamento informado na anotação.

A anotação @Scheduled possui 3 parâmetros para podermos definir o agendamento das tarefas: fixedDelay, fixedRate e cron.

• fixedDelay é um valor em milissegundos que será esperado entre o fim de uma execução e o começo de outra;
• fixedRate é um valor em milissegundos que será esperado entre as invocações, ou seja, sem considerar o fim do método;
• cron é uma String contendo uma CronExpression. Veremos detalhes mais a seguir.

Para o método pingarServidores() nós definimos que a cada 5 segundos desde sua última execução ele deverá ser invocado novamente. Com isso basta executarmos a aplicação, esperar alguns segundos, clicar no link Recarregar e teremos uma saída parecida com essa:

A anotação @Async

Depois que você diz para o teu chefe que terminou a funcionalidade de pingar os servidores ele pergunta: “Mas o ping nos servidores está sendo feito de forma assíncrona certo?”. Errado! Do jeito que está as chamadas estão sendo feitas de maneira síncrona dentro do for, ou seja, para pingar o segundo servidor tem que esperar o ping do primeiro terminar e assim por diante.

Mas por sorte a galera do Spring já pensou nisso e já disponibilizou uma anotação para resolver o nosso problema: a anotação @Async.

Para tornarmos os pings assíncronos basta fazermos o seguinte:

/**
 * Classe responsável pelas tarefas agendadas relacionadas a infra estrutura.
 *
 * @author Felipe
 */
@Component
public class TarefaPingServidores implements Tarefa {
 
	@Autowired
	private HistoricoExecucao historicoExecucao;
 
	@Async
	@Override
	public void executar(Object... args) {
		if (args == null || args.length == 0) {
			throw new IllegalArgumentException("A tarefa deve receber o IP do servidor a ser pingado!");
		}
 
		String ipServidor = args[0].toString();
		String nomeServidor = "Servidor de " + InfraUtils.traduzirIp(ipServidor);
		String historico = "";
 
		if (InfraUtils.pingaServidor(ipServidor)) {
			historico = nomeServidor + " pingado com sucesso.";
		} else {
			historico = nomeServidor + " caiu!";
			EmailUtils.enviaEmail(EmailUtils.EMAIL_CHEFE, historico);
		}
 
		historicoExecucao.novoHistorico(historico);
	}
 
}

Só isso? Sim, só isso!

Para termos certeza de que isso vai funcionar mesmo vamos fazer o seguinte:

/**
 * Classe que contém todas as tarefas agendadas do sistema.
 *
 * @author Felipe
 */
@Component
public class TarefasAgendadas {
 
	@Autowired
	@Qualifier("tarefaPingServidores")
	private Tarefa pingarServidores;
 
	@Scheduled(fixedDelay=5000)
	private void pingarServidores() {
		String[] servidores = InfraUtils.IPS_SERVIDORES;
		for (int i = 0; i < servidores.length; i++) {
			pingarServidores.executar(servidores[i], i);
		}
	}
}

/**
 * Classe responsável pelas tarefas agendadas relacionadas a infra estrutura.
 *
 * @author Felipe
 */
@Component
public class TarefaPingServidores implements Tarefa {
 
	@Autowired
	private HistoricoExecucao historicoExecucao;
 
	@Async
	@Override
	public void executar(Object... args) {
		if (args == null || args.length == 0) {
			throw new IllegalArgumentException("A tarefa deve receber o IP do servidor a ser pingado!");
		}
 
		System.out.println(String.format("%s começando (%d)",Thread.currentThread().getName(), args[1]));
 
		String ipServidor = args[0].toString();
		String nomeServidor = "Servidor de " + InfraUtils.traduzirIp(ipServidor);
		String historico = "";
 
		if (InfraUtils.pingaServidor(ipServidor)) {
			historico = nomeServidor + " pingado com sucesso.";
		} else {
			historico = nomeServidor + " caiu!";
			EmailUtils.enviaEmail(EmailUtils.EMAIL_CHEFE, historico);
		}
 
		historicoExecucao.novoHistorico(historico);
 
		System.out.println(String.format("%s terminando (%d)",Thread.currentThread().getName(), args[1]));
	}
 
}

Vamos enviar para a tarefa em qual loop ela foi executada (pingarServidores.executar(servidores[i], i)) e depois vamos logar o início e fim da execução de cada tarefa para podermos acompanhar se está acontecendo tudo em sequência mesmo ou se estão asíncronas.

Ao executar a aplicação e observar o console por algum tempo iremos ver o seguinte:

Só pelo nome da thread já podemos ver que funcionou né… Em adição ao nome, se repararmos na saída podemos ver que algumas invocações posteriores podem começar a ser executadas antes. Ex: 1, 0, 2 e 0, 2, 1.

Devido a anotação @Async, assim que o método for chamado ele já vai retornar e o Spring irá executá-lo em uma thread única, por isso vale lembrar que isso irá funcionar para métodos que não possuam retorno (void). Caso seja necessário retornar um valor do método assíncrono devemos utilizar como retorno um objeto que implemente a interface java.util.concurrent.Future. Para mais informações consulte a documentação e/ou o google. hehehe

Com isso terminamos o agendamento da tarefa para pingar os servidores da empresa!

Vamos para a nossa última tarefa: criar uma tarefa que envie um e-mail para o chefe todo dia com o andamento das sprints. Vamo primeiro criar a tarefa que fará isso:

/**
 * Classe responsável pelo envio agendado de emails.
 *
 * @author Felipe
 */
@Component
public class TarefaAndamentoDiarioSprints implements Tarefa {
 
	@Autowired
	private HistoricoExecucao historicoExecucao;
 
	@Override
	public void executar(Object... args) {
		// Levanta os dados necessários e monta a mensagem
		String andamentoTarefas = "Segue o andamento das tarefas...";
		EmailUtils.enviaEmail(EmailUtils.EMAIL_CHEFE, andamentoTarefas);
 
		historicoExecucao.novoHistorico("Andamento das tarefas enviado por email.");
	}
}

Uma vez que temos a tarefa vamos agendá-la para que seja enviada no último segundo de cada dia, ou seja, 23:59:59h. Para isso usaremos o atributo cron da anotação @Scheduled:

/**
 * Classe que contém todas as tarefas agendadas do sistema.
 *
 * @author Felipe
 */
@Component
public class TarefasAgendadas {
 
	@Autowired
	@Qualifier("tarefaPingServidores")
	private Tarefa pingarServidores;
 
	@Autowired
	@Qualifier("tarefaAndamentoDiarioSprints")
	private Tarefa andamentoDiarioSprints;
 
	@Scheduled(fixedDelay=5000)
	private void pingarServidores() {
		String[] servidores = InfraUtils.IPS_SERVIDORES;
		for (int i = 0; i < servidores.length; i++) {
			pingarServidores.executar(servidores[i], i);
		}
	}
 
	@Scheduled(cron = "59 59 23 ? * *")
	private void andamentoDiarioSprint() {
		andamentoDiarioSprints.executar();
	}
}

Expressões cron

O que são expressões cron afinal de contas (que string esquisita…)?

cron é uma ferramenta UNIX muito poderosa para agendamento. Ela é utilizada há muito tempo, ou seja, sabemos que funciona! Expressões cron são as expressões que essa ferramenta utiliza para realizar os agendamentos. Tais expressões são formadas por 6 ou 7 campos separados por espaços em branco, representando períodos de tempo. Vamos dar uma olhada nesses campos:

Olhando para essa tabela agora já – quase – conseguimos ler a expressão que usamos na anotação @Scheduled(cron =”59 59 23 ? * *”)… Já sabemos que vai ser no horário 23:59:59, mas o que significam esses caracteres especiais? Vamos lá:

• Asterísco (*) – utilizado para selecionar todos os valores. Ex: * no campo segundos significa “todos os segundos”;
• Interrogação (?) – utilizador quando o valor do campo não importa. Ex: quero que seja disparada uma tarefa todo dia 10 mas não me importo qual dia da semana vai ser o dia 10;
• Hífen (-) – utilizado para informar períodos. Ex: “1-4″ no campo mês quer dizer que a tarefa será disparada em janeiro, fevereiro, março e abril;
• Vírgula (,) – utilizado para valores adicionais. Ex: “MON,WED,FRI” no campo dia da semana indica a execução na segunda, quarta e sexta feiras;
• Barra (/) – utilizado para especificar incrementos. Utiliza a seguinte sintaxe: <início>/<incremento> (se o início for omitido ele será interpretado como 0). Ex: “/30″ no campo segundos significa “a cada 30 segundos” e “1/5″ no campo dia do mês indica a execução nos dias “1, 6, 11, 16, …”;
• L (last) - possui alguns significados dependendo do campo em que é utilizado. Se for utilizado no campo dia do mês significa o último dia do mês, se for utilizado sozinho no campo dia da semana significa 7 ou SAT (sábado), se utilizado com algum valor no campo dia da semana seria “o último … do mês” (ex: “6L” seria “a última sexta feira do mês”), também é possível especificar um período antes do fim do mês no campo dia do mês (ex: “L-2″ seria o antepenúltimo dia do mês);
• W (weekday) – usado para especificar o dia útil (segunda – sexta) mais próximo do dia informado. Ex: “15W” no campo dia do mês vai executar na segunda feira (dia 14) caso o dia 15 caia em um sábado ou então vai executar em uma segunda (16) caso o dia 15 seja um domingo. Se utilizarmos “1W” e o primeiro dia do mês seja um sábado, só vai executar na segunda feira (dia 3). Só é possível utilizar esse caractere quando o dia do mês for um único dia, sua utilização com períodos não é permitida;
• Sustenido (#) – utilizado para especificar o “n-ésimo” dia do mês. Ex: “6#3″ no campo dia da semana significa “a terceira sexta feira do mês (6 = sexta, #3 = terceira)”; “4#5″ significa “a quinta quarta feira do mês”, porém se não houver uma quinta quarta feira no mês a tarefa não será executada.

Bom, expressões cron podem ser fáceis como “0 0 15 ? * *” ou podem ser complexas como “0/5 14,18,3-39,52 * ? JAN,MAR,SEP MON-FRI 2002-2010″.

Mas então… como saber se a sua expressão está certa ou não?

Para isso existe uma classe bem bacana na biblioteca do Quartz: CronExpression.java. Nela existe o método getNextValidTimeAfter(Date) que nos retorna a próxima data (a partir do parâmetro) na qual a tarefa será executada. Com isso nós podemos montar uma classe utilitária que nos permite testar se nossa expressão está certa ou não:

/**
 * Classe responsável por realizar testes com as Cron Expressions.
 *
 * @author Felipe
 */
public class TestaExpressao {
 
	private static SimpleDateFormat sdf = new SimpleDateFormat("dd/MM/yyyy HH:mm:ss");
 
	public static void main(String[] args) {
		mostrarProximasDatas("59 59 23 ? * *", 10);
	}
 
	public static void mostrarProximasDatas(String cron, int quantDatas) {
		try {
			CronExpression e = new CronExpression(cron);
			Date ultimaData = new Date();
			for (int i = 0; i < quantDatas; i++) {
				ultimaData = e.getNextValidTimeAfter(ultimaData);
				System.out.println(String.format("%02d: %s", i+1, sdf.format(ultimaData)));
			}
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}

Obs: para essa classe funcionar será necessário colocar a biblioteca do Quartz no classpath.

O método mostrarProximasDatas(String, int) recebe uma expressão e a quantidade de datas futuras em que essa expressão irá disparar serão exibidas como parâmetros. Ao executar o exemplo acima vamos ter uma saída parecida com essa:

Vemos que vai disparar todo dia exatamente às 23:59:59, ou seja, conferimos que nossa expressão vai fazer exatamente o que queremos!

Conclusão

Bom pessoal, depois desse pequeno post você vai conseguir entregar a aplicação para o seu chefe antes do prazo e ele vai ficar muito satisfeito com o resultado! hehehe

Mas sem brincadeiras, o Spring provê uma forma maneira muito fácil e ao mesmo tempo muito poderosa para agendarmos tarefas. Sem falar que incrivelmente legível né (devido ao uso de anotações e poucas configurações em XML).

Caso a sua aplicação seja muito grande mesmo e precise de tarefas agendadas como realizar transações bancárias (ou coisas de mesma importância) eu aconselharia dar uma olhada no Quartz mesmo. Ele provê algumas funcionalidades a nível de aplicações de grande porte como persistência dos jobs a serem executados (em caso de alguma falha), clusterização e suporte a transações JTA.

Caso queira o projeto basta realizar o download aqui.

Boa sorte com seus agendamentos!

[]s e até o próximo,

Saab.

Links

Seguem alguns links que me ajudaram e podem te ajudar também:

• Obtendo as bibliotecas do Spring 3 pelo Maven
• Simplificações em relação agendamento de tarefas no Spring 3
• Documentação do Spring 3
• CronTrigger Tutorial
• Download do Quartz

Porém essa atualização iria modificar uma parte da codificação do post então decidimos criar um novo focando somente em Spring 3.1 e Hibernate 4.0.

Aos que estão iniciando neste assunto, sugiro a leitura dos assuntos abordados em posts anteriores:

• Spring Framework Parte 1 -> Dependency Injection
• Spring Framework Parte 2 -> Aspect Oriented Programming
• Spring Framework Parte 3 -> Java Database Connectivity (JDBC)

Neste tópico vamos abordar a configuração de um projeto utilizando Hibernate 4 com anotações (annotations), Spring 3.1 e uma base de dados MySQL.

Usar Annotations ou XML?

Existe muita discussão sobre este assunto. O Hibernate permite as duas formas, ambas tem suas vantagens e desvantagens.

Na minha opnião o Annotations tem grande vantagem pois elimina arquivos para cada mapeamento, aumenta a produtividade pela configuração ficar diretamente no POJO, ou seja, na classe java que representa a tabela que está sendo mapeada.

Uma das maneiras mais diretas de interagir com banco de dados usando o Java é via JDBC, porém exige muita codificação para manter os dados persistentes no sistema. Atualmente temos ferramentas como o Hibernate que nos auxiliam neste trabalho e que está evoluindo constantemente para ficar ainda melhor.

Bom, chega de papo, vamos codificar!

Vamos criar no Eclipse um novo Java Project chamado Spring_HibernateAnnotations.

Bibliotecas e Dependências

Criarei no projeto uma pasta lib e colocarei dentro as bibliotecas necessárias para rodar o Spring 3.1 e o Hibernate 4.0. As bibliotecas podem ser encontradas em:

• Spring: http://www.springsource.org/download (todos os arquivos da pasta dist)
• Hibernate: http://sourceforge.net/projects/hibernate/files/hibernate4/ (todos os arquivos da pasta lib/required e lib/jpa)

O Spring e o Hibernate fazem uso de bibliotecas auxiliares que precisarão ser adicionadas:

• Commons Logging: http://commons.apache.org/logging/ (extraia e adicione somente o commons-logging-1.1.1.jar)
• SLF4J: http://www.slf4j.org/download.html (adicione somente slf4j-api-1.6.x.jar e slf4j-simple-1.6.x.jar)
• JTA: http://repo2.maven.org/maven2/javax/transaction/jta/1.1/ (adicione somente jta-1.1.jar)
• AspectJ http://www.eclipse.org/aspectj/downloads.php (Extraia o aspectj-1.x.x .jar com o Winrar e adicione em seu projeto os arquivos da pasta lib)
• AOPAlliance http://aopalliance.sourceforge.net/ (Adicione o aopalliance.jar)

Para conectar com a base de dados MySQL precisamos também do conector:

• Connector J: http://dev.mysql.com/downloads/connector/j/ (Adicione o mysql-connector-java-x.x.x-bin.jar)

Após adicionar os jars ao projeto devemos ter uma tela parecida com essa:

Mãos à obra

Vamos definir uma estrutura inicial de pacotes para o nosso projeto:

• conf: Guardará o arquivo de configurações
• spring_hibernateannotations:  Local onde ficarão as classes que farão execução
• spring_hibernateannotations.interfaces: Guardará as interfaces
• spring_hibernateannotations.modelo: Guardará os POJOs

Arquivo de configuração

Vamos criar o arquivo de configuração do Spring com o nome conf.xml no pacote conf:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
 
	<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
		<property name="driverClassName" value="com.mysql.jdbc.Driver" />
		<property name="url" value="jdbc:mysql://localhost/hibernate_teste" />
		<property name="username" value="root" />
		<property name="password" value="root" />
	</bean>
 
	<bean id="sessionFactory" class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">
		<property name="dataSource" ref="dataSource" />
		<property name="annotatedClasses">
			<list>
				<value>spring_hibernateannotations.modelo.Livro</value>
			</list>
		</property>
		<property name="hibernateProperties">
			<props>
				<prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>
				<prop key="hibernate.show_sql">true</prop>
			</props>
		</property>
	</bean>
 
	<bean id="banco_dados" class="spring_hibernateannotations.BancoDados">
		<property name="sessionFactory" ref="sessionFactory" />
	</bean>
 
</beans>

CREATE TABLE  'Livros' (
    'liv_cod' INT NOT NULL ,
    'liv_titulo' VARCHAR( 100 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL ,
    PRIMARY KEY (  'liv_cod' )
) ENGINE = INNODB CHARACTER SET utf8 COLLATE utf8_unicode_ci;

@Entity
@Table(name = "livros")
@GenericGenerator(name = "mygenLivros", strategy = "increment")
public class Livro implements Serializable {
 
	private static final long serialVersionUID = 6216997659936884192L;
 
	@Id
	@GeneratedValue(generator = "mygenLivros")
	@Column(name = "liv_cod")
	private int cod;
 
	@Column(name = "liv_titulo")
	private String titulo;
 
	// Getters e Setters
 
}

public interface IBanco {
 
	public Livro InserirLivro(Livro livro);
 
	public void AtualizarLivro(Livro livro);
 
	public void ApagarLivro(Livro livro);
 
	public List<Livro> SelecionarLivrosPorTitulo(String titulo);
 
	public Livro SelecionarLivroPorCodigo(int cod);
 
}

public class BancoDados implements IBanco {
 
	private SessionFactory sessionFactory;
 
	private Session sessao;
 
	private Transaction transacao;
 
	public void setSessionFactory(SessionFactory sessionFactory) {
		this.sessionFactory = sessionFactory;
		this.sessao = sessionFactory.openSession();
	}
 
	public Livro InserirLivro(Livro livro) {
		try {
			if(!sessao.isOpen()) {
				sessao = sessionFactory.openSession();
			}
			transacao = sessao.beginTransaction();
			int cod = (Integer) sessao.save(livro);
			transacao.commit();
			livro.setCod(cod);
		}
		catch(HibernateException e) {
			System.out.println("Erro: " + e.getMessage());
			transacao.rollback();
		}
		finally {
			try {
				if(sessao.isOpen()) {
					sessao.close();
				}
			}
			catch(Throwable e)
			{
				System.out.println("Erro ao finalizar inserção: " + e.getMessage());
			}
		}
 
		return livro;
 
	}
 
	public void AtualizarLivro(Livro livro) {
 
		try {
			if(!sessao.isOpen()) {
				sessao = sessionFactory.openSession();
			}
			transacao = sessao.beginTransaction();
			sessao.update(livro);
			transacao.commit();
		}
		catch(HibernateException e)
		{
			System.out.println("Erro: " + e.getMessage());
			transacao.rollback();
		}
		finally {
			try {
				if(sessao.isOpen()) {
					sessao.close();
				}
			}
			catch(Throwable e){
				System.out.println("Erro ao finalizar atualização: " + e.getMessage());
			}
		}
 
	}
 
	public void ApagarLivro(Livro livro) {
		try {
			if(!sessao.isOpen()) {
				sessao = sessionFactory.openSession();
			}
			transacao = sessao.beginTransaction();
			sessao.delete(livro);
			transacao.commit();
		}
		catch(HibernateException e) {
			System.out.println("Erro: " + e.getMessage());
			transacao.rollback();
		}
		finally {
			try {
				if(sessao.isOpen()) {
					sessao.close();
				}
			}
			catch(Throwable e) {
				System.out.println("Erro ao finalizar : " + e.getMessage());
			}
		}
	}
 
	public List<Livro> SelecionarLivrosPorTitulo(String titulo) {
		if(!sessao.isOpen()) {
			sessao = sessionFactory.openSession();
		}
		Criteria criteria = sessao.createCriteria(Livro.class);
		criteria.add(Restrictions.like("titulo", titulo));
		return criteria.list();
	}
 
	public Livro SelecionarLivroPorCodigo(int cod) {
		if(!sessao.isOpen()) {
			sessao = sessionFactory.openSession();
		}
		Criteria criteria = sessao.createCriteria(Livro.class);
		criteria.add(Restrictions.eq("cod", cod));
		Livro livro = (Livro) criteria.uniqueResult();
		return livro;
	}
 
}

public class Main {
 
	public static void main(String[] args) {
 
		ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/conf.xml");
		System.out.println("Spring inicializado");
 
		BancoDados banco = (BancoDados) ctx.getBean("banco_dados");
 
		Livro livro1 = new Livro();
		livro1.setTitulo("Spring + Hibernate");
		Livro livro2 = new Livro();
		livro2.setTitulo("Hibernate Avançado");
		System.out.println("Objetos Livro inicializados");
 
		livro1 = banco.InserirLivro(livro1);
		livro2 = banco.InserirLivro(livro2);
		System.out.println("Livros gravados no banco");
 
		//zerando os objetos Livro
		livro1 = null;
		livro2 = null;
 
		System.out.println("Selecionando livros por código");
		livro1 = banco.SelecionarLivroPorCodigo(1);
		exibe(livro1);
		livro2 = banco.SelecionarLivroPorCodigo(2);
		exibe(livro2);
 
		System.out.println("Selecionando livros que contenham 'Hibernate' no título");
		List<Livro> lista = banco.SelecionarLivrosPorTitulo("Hibernate");
		for (Livro l : lista){
			exibe(l);
		}
 
		System.out.println("Atualizando livro");
		livro1.setTitulo(livro1.getTitulo()+" Segunda Edição");
		banco.AtualizarLivro(livro1);
 
		System.out.println("Apagando livro");
		banco.ApagarLivro(livro2);
	}
 
	public static void exibe(Livro livro) {
		if (livro == null)
			System.out.println("Livro não encontrado");
		else
			System.out.println("Livro -> cod: " + livro.getCod() + " | Título: " + livro.getTitulo());
	}
 
}

Bem legal, já vimos que funciona e funciona muito bem desse jeito.

Porém, – sempre tem um porém hehe –  conforme o sistema vai começando a crescer os arquivos de configuração começam a se tornar verdadeiras teias de aranha. Crescem muito!

E como a ideia do Spring é simplificar ao invés de complicar existe um jeito alternativo aos arquivos XML para configurar a injeção de dependência nos nossos beans: anotações.

Utilizando simples anotações nós conseguimos deixar o(s) arquivo(s) de configuração do Spring o mais simples possível e ainda assim deixar o container cuidar da injeção de dependência.

NOSSA APLICAÇÃO

Vamos desenvolver um pequeno programa para simular o funcionamento de um computador então.

O projeto vai ter a seguinte estrutura:

OBS: a pasta lib contém todas as bibliotecas necessárias para rodar o projeto.

Vamos começar dando uma olhada no pacote br.blog.javasimples.spring.pecas para vermos as interfaces que definem as pecas do computador:

/**
 * Interface que define os métodos necessários para uma peça do computador.
 * 
 * @author Felipe
 */
public interface Peca {
 
	void ligar();
 
}

/**
 * Interface que define os métodos necessários para um Monitor.
 * 
 * @author Felipe
 */
public interface Monitor extends Peca {
 
	/**
	 * Escreve uma mensagem na tela.
	 */
	void escreverNaTela(String mensagem);
 
}

/**
 * Interface que define os métodos necessários para um Processador.
 * 
 * @author Felipe
 */
public interface Processador extends Peca {
 
	/**
	 * Soma dois inteiros.
	 */
	int soma(int x, int y);
 
}

Vamos dar uma olhada em como as implementações dessas interfaces funcionam (pacote br.blog.javasimples.spring.pecas.impl):

/**
 * Classe que representa um monitor CRT de 17 polegadas.
 * 
 * @author Felipe
 */
public class Monitor17 implements Monitor {
 
	private final int FREQUENCIA = 60;
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void ligar() {
		System.out.println("Iniciando o monitor [" + FREQUENCIA + "Hz];");
	}
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void escreverNaTela(String mensagem) {
		System.out.println("[" + mensagem + "]");
	}
 
}

/**
 * Classe que representa um processador DualCore.
 * 
 * @author Felipe
 */
public class DualCore implements Processador {
 
	private final double FRQUENCIA = 2.6;
 
	private final int NUCLEOS = 2;
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void ligar() {
		System.out.println("Iniciando o processador [" + FRQUENCIA + "GHz, " + NUCLEOS + " núcleos];");
	}
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public int soma(int x, int y) {
		return x + y;
	}
}

Cada implementação é específica de um produto, ou seja, temos um monitor CRT de 17” que só suporta 60Hz e um processador DualCore (Intel) cuja frequência é 2.6GHz.

E o computador? Como fica?

/**
 * Classe que representa o computador.
 * 
 * @author Felipe
 */
public class Computador {
 
	private Processador processador;
 
	private Monitor monitor;
 
	public Computador(Processador processador, Monitor monitor) {
		super();
		this.processador = processador;
		this.monitor = monitor;
	}
 
	public void ligar() {
		System.out.println("Ligando computador...");
		processador.ligar();
		monitor.ligar();
		System.out.println("Computador ligado.");
	}
 
	public void somar(int x, int y) {
		monitor.escreverNaTela(String.format("%d + %d = %d", x, y, processador.soma(x, y)));
	}
 
}

O computador foi escrito seguindo as melhores práticas de desenvolvimento conforme já conversamos na  Parte 1 da série né:

• Programação orientada a interfaces e não a implementações: perceba que o computador não sabe se na sua placa mãe tem um processador Intel ou AMD, ele só sabe que tem um processador que sabe como ligar e somar;
• Injeção de dependência: perceba que todas as dependências do computador são injetadas nele através do seu construtor, com isso ganhamos muita flexibilidade para futuras mudanças em relação a quais componentes devemos injetar no computador.

E o arquivo de configuração ficou da seguinte maneira:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
 
	<bean id="computador" class="br.blog.javasimples.spring.Computador">
		<constructor-arg name="monitor" ref="monitor" />
		<constructor-arg name="processador" ref="processador" />
	</bean>
 
	<bean id="processador" class="br.blog.javasimples.spring.pecas.impl.DualCore"/>
 
	<bean id="monitor" class="br.blog.javasimples.spring.pecas.impl.Monitor17"/>
 
</beans>

public class Main {
 
	public static void main(String[] args) {
		ApplicationContext context = new ClassPathXmlApplicationContext("br/blog/javasimples/spring/config/applicationContext.xml");
		Computador pc = (Computador) context.getBean("computador");
		pc.ligar();
		pc.somar(2, 2);
	}
 
}

O que acontece nela é que criamos o container do Spring a partir do arquivo de configuração, ligamos o computador e realizamos uma simples operação nele. Ao executar essa classe nós recebemos a seguinte saída:

Ligando computador...
Iniciando o processador [2.6GHz, 2 núcleos];
Iniciando o monitor [60Hz];
Computador ligado.
[2 + 2 = 4]

Legal, tudo funciona como nós já estávamos acostumados.

Preparando o container

Por padrão o container do Spring não vem com o suporte para injeção de dependência via anotações habilitado. Para fazer isso nós precisamos fazer uma pequena alteração no arquivo de configuração:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd">
 
	<context:annotation-config />
 
	<bean id="computador" class="br.blog.javasimples.spring.Computador"/>
 
	<bean id="processador" class="br.blog.javasimples.spring.pecas.impl.DualCore"/>
 
	<bean id="monitor" class="br.blog.javasimples.spring.pecas.impl.Monitor17"/>
 
</beans>

E como vamos utilizar a injeção de dependência via anotações nós já podemos remover as injeções declarativas do arquivo de configuração.

O Spring suporta algumas anotações para a injeção de dependência, são elas:

• A anotação do próprio Spring Framework @Autowired;
• A anotação @Inject da JSR-330 (Dependency Injection for Java);
• A anotação @Resource da JSR-250 (Common Annotations for the Java Plataform).

Hoje vamos ver somente a @Autowired. As outras são bem parecidas e ficam por sua conta o estudo ok?

A anotação @Autowired

A anotação @Autowired pode ser utilizada em setters, construtores ou até mesmo em uma variável de classe – independe da sua visibilidade, ou seja, mesmo que private.

Na nossa aplicação podemos utilizá-la assim:

public class Computador {
 
	private Processador processador;
 
	private Monitor monitor;
 
	@Autowired
	public Computador(Processador processador, Monitor monitor) {
		super();
		this.processador = processador;
		this.monitor = monitor;
	}
 
	// ...
 
}

Eu, particularmente, estou mais acostumado a utilizar assim:

public class Computador {
 
	@Autowired
	private Processador processador;
 
	@Autowired
	private Monitor monitor;
 
	public Computador(Processador processador, Monitor monitor) {
		super();
		this.processador = processador;
		this.monitor = monitor;
	}
 
	// ...
 
}

E a última maneira seria nos setters:

public class Computador {
 
	private Processador processador;
 
	private Monitor monitor;
 
	public Processador getProcessador() {
		return processador;
	}
 
	@Autowired
	public void setProcessador(Processador processador) {
		this.processador = processador;
	}
 
	public Monitor getMonitor() {
		return monitor;
	}
 
	@Autowired
	public void setMonitor(Monitor monitor) {
		this.monitor = monitor;
	}
 
	// ...
 
}

OBS: os getters não são uma obrigatoriedade, coloquei apenas por convenção.

Simples assim, toda vez que precisarmos das dependências elas estarão lá! Para testar podemos rodar o projeto novamente e veremos que nada mudou na saída, ou seja, tudo ainda está funcionando!

O Spring deve obrigatoriamente achar um bean para injetar no atributo anotado com @Autowired, caso contrário será lançada uma NoSuchBeanDefinitionException. Caso o atributo possa ter ou não valor, ou seja, se pode acontecer de o Spring não achar um bean para o atributo devemos setar a propriedade required da anotação para false:

public class Computador {
 
	@Autowired
	private Processador processador;
 
	@Autowired(required=false)
	private Monitor monitor;
 
	// ...
 
}

Porém quando fizer isso tome o cuidado de sempre verificar se o atributo está nulo ou não antes de utilizá-lo para evitar os famosos NullPointerException.

Outra coisa que devemos saber é que o Spring realiza uma busca por tipo (byType) para encontrar as dependências para atributos anotados com @Autowired, ou seja, como anotamos um atributo do tipo br.blog.javasimples.spring.pecas.Monitor o Spring vai procurar por algum bean que implemente essa interface para poder injetar no nosso computador.

Como disse anteriormente, caso ele não encontre nenhum bean será lançada uma NoSuchBeanDefinitionException.

Mas… – aqueles momentos em que você tem uma ideia que você acha que ninguém teve antes – e se ele encontrar mais de um bean que implemente essa interface?

Esse será o assunto do nosso próximo tópico, e só a nível de curiosidade, caso isso aconteça e não seja tratado o Spring também irá lançar uma NoSuchBeanDefinitionException.

Tratando dependências ambíguas com @Qualifier

E agora entra mais uma anotação para o nosso arsenal! hehehe

Para tratar dependências ambíguas o Spring nos oferece a anotação @Qualifier e algumas maneiras de utilizá-la. Antes de vermos todas essas maneiras vamos nos armar uma própria emboscada: criar mais um monitor para podermos simular tal erro.

/**
 * Classe que representa um monitor LED de 22 polegadas.
 * 
 * @author Felipe
 */
public class MonitorLED22 implements Monitor {
 
	private final int FREQUENCIA = 75;
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void ligar() {
		System.out.println("Iniciando o monitor [" + FREQUENCIA + "Hz];");
	}
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void escreverNaTela(String mensagem) {
		System.out.println("[[[" + mensagem + "]]]");
	}
 
}

Nosso novo monitor é LED, muito melhor do que o antigo CRT, e tem 22”, um tamanho bem agradável. Ele é tão melhor que até o seu método de escrever coloca umas frescurinhas a mais para tentar agradar o usuário (heheheh). Vamos adicioná-lo ao arquivo de configuração:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd">
 
	<context:annotation-config />
 
	<bean id="computador" class="br.blog.javasimples.spring.Computador"/>
 
	<bean id="processador" class="br.blog.javasimples.spring.pecas.impl.DualCore"/>
 
	<bean id="monitor" class="br.blog.javasimples.spring.pecas.impl.Monitor17"/>
 
	<bean id="monitorLED22" class="br.blog.javasimples.spring.pecas.impl.MonitorLED22"/>
 
</beans>

Se tentarmos rodar agora iremos ver a nossa tão comentada NoSuchBeanDefinitionException.

Vamos ver então como podemos resolver isso de algumas maneiras diferentes.

Selecionando de acordo com o ID

Podemos especificar na anotação @Qualifier qual o ID do bean que queremos injetar:

public class Computador {
 
	@Autowired
	private Processador processador;
 
	@Autowired
	@Qualifier("monitorLED22")
	private Monitor monitor;
 
	// ...
 
}

Ao executar nossa aplicação assim será exibida a seguinte saída indicando que nosso computador está utilizando o monitor de 22”:

Ligando computador...
Iniciando o processador [2.6GHz, 2 núcleos];
Iniciando o monitor [75Hz];
Computador ligado.
[[[2 + 2 = 4]]]

Selecionando de acordo com um qualificador

No exemplo anterior nós utilizamos o monitor novo, mas e se quiséssemos utilizar o antigo?

public class Computador {
 
	@Autowired
	private Processador processador;
 
	@Autowired
	@Qualifier("monitor")
	private Monitor monitor;
 
	// ...
 
}

Assim funciona porém não está muito intuitivo né… Um Monitor anotado com @Qualifier(“monitor”) não é muito fácil de entender né, em uma futura manutenção o pobre coitado vai ter que caçar no XML qual o bean que tem id=”monitor” para poder chegar na respectiva classe. Seria muito mais fácil se a anotação fosse @Qualifier(“monitorCRT17″) não seria?

A primeira ideia que vem na cabeça é: “beleza, vou mudar de id=”monitor” para id=”monitorCRT17″! ”.

Como nossa aplicação é apenas um exemplo bem pequeno não teria problema nenhum. Mas imagine em uma aplicação grande que já está em produção.. O risco de gerar algum erro mudando o id do bean é um pouco maior.

Para evitar isso o Spring permite que informemos um qualificador para o bean. Podemos fazer isso de duas maneiras diferentes:

No XML de configuração:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd">
 
	<context:annotation-config />
 
	<bean id="computador" class="br.blog.javasimples.spring.Computador"/>
 
	<bean id="processador" class="br.blog.javasimples.spring.pecas.impl.DualCore"/>
 
	<bean id="monitor" class="br.blog.javasimples.spring.pecas.impl.Monitor17">
		<qualifier value="monitorCRT17" />
	</bean>
 
	<bean id="monitorLED22" class="br.blog.javasimples.spring.pecas.impl.MonitorLED22"/>
 
</beans>

Ou então na própria classe:

@Qualifier("monitorCRT17")
public class Monitor17 implements Monitor {
 
	// ...
 
}

Criando qualificadores customizados

Se você, assim como eu, acha que ficar se referindo diretamente aos IDs (ou até mesmo qualificadores) não é uma solução muito elegante o Spring permite que criemos nossos próprios qualificadores criando anotações que sejam anotadas com @Qualifier.

Vamos criar um qualificador que vai qualificar as tecnologias dos monitores, ou seja, @MonitorLED e @MonitorCRT (vou criar as anotações em um novo pacote br.blog.javasimples.spring.pecas.anotacoes):

@Target({ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Qualifier
public @interface MonitorCRT {
}

@Target({ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Qualifier
public @interface MonitorLED {
}

E vamos também anotar cada monitor com seu respectivo tipo:

@MonitorCRT
public class Monitor17 implements Monitor {
 
	// ...
 
}

@MonitorLED
public class MonitorLED22 implements Monitor {
 
	// ...
 
}

Com isso podemos facilmente anotar a dependência do computador com a nossa nova anotação:

public class Computador {
 
	@Autowired
	private Processador processador;
 
	@Autowired
	@MonitorLED
	private Monitor monitor;
 
	// ...
 
}

Nesse momento há aquele flash na sua cabeça (de novo) e você pergunta: “e se eu tiver 2 monitores de LED porém com tamanhos diferentes?”.

Vamos adicionar um novo monitor de LED ao nosso projeto então:

/**
 * Classe que representa um monitor LED de 19 polegadas.
 * 
 * @author Felipe
 */
@MonitorLED
public class MonitorLED19 implements Monitor {
 
	private final int FREQUENCIA = 75;
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void ligar() {
		System.out.println("Iniciando o monitor [" + FREQUENCIA + "Hz];");
	}
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void escreverNaTela(String mensagem) {
		System.out.println("[[" + mensagem + "]]");
	}
 
}

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd">
 
	<context:annotation-config />
 
	<bean id="computador" class="br.blog.javasimples.spring.Computador"/>
 
	<bean id="processador" class="br.blog.javasimples.spring.pecas.impl.DualCore"/>
 
	<bean id="monitor" class="br.blog.javasimples.spring.pecas.impl.Monitor17"/>
 
	<bean id="monitorLED19" class="br.blog.javasimples.spring.pecas.impl.MonitorLED19"/>
 
	<bean id="monitorLED22" class="br.blog.javasimples.spring.pecas.impl.MonitorLED22"/>
 
</beans>

Ao executar esse código caímos novamente na nossa adorável NoSuchBeanDefinitionException.

Para resolver isso podemos utilizar combinações de qualificadores, ou seja, vamos criar mais alguns qualificadores para as polegadas:

@Target({ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Qualifier
public @interface Monitor19 {
}

@Target({ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Qualifier
public @interface Monitor22 {
}

Vamos qualificar os monitores:

@MonitorLED
@Monitor19
public class MonitorLED19 implements Monitor {
 
	// ...
 
}

@MonitorLED
@Monitor22
public class MonitorLED22 implements Monitor {
 
	// ...
 
}

E por fim identificar corretamente qual monitor nosso computador irá possuir:

public class Computador {
 
	@Autowired
	private Processador processador;
 
	@Autowired
	@MonitorLED
	@Monitor19
	private Monitor monitor;
 
	// ...
 
}

Ao executar esse código recebemos a seguinte saída indicando que nosso monitor de 19 entrou em ação:

Ligando computador...
Iniciando o processador [2.6GHz, 2 núcleos];
Iniciando o monitor [75Hz];
Computador ligado.
[[2 + 2 = 4]]

Na minha humilde opinião essa é a melhor e mais elegante solução para resolver o problema. Podemos fazer qualquer combinação com os qualificadores desde que ela identifique somente um bean.

Descoberta automática de beans

A utilização da tag <context:annotation-config /> no arquivo de configuração do Spring possibilita a utilização de várias anotações para a injeção de dependência porém não elimina a necessidade de declarar todos os seus beans no arquivo de configuração.

Em um sistema grande ainda teremos que declarar muitos beans no XML, o que acaba sendo um pouco chato…

Para evitar isso o Spring tem uma facilidade que possibilita que ele mesmo procure pelos beans em tempo de execução, ou seja, não precisamos declará-los via XML.

Para isso precisaremos fazer uma mudança no arquivo de configuração:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd">
 
	<context:component-scan base-package="br.blog.javasimples.spring" />
 
</beans>

Agora sim temos um belo arquivo de configuração em!

A tag <context:component-scan base-package=”br.blog.javasimples.spring” /> possibilita o uso das anotações que anteriormente a tag <context:annotation-config /> possibilitava e ainda permite que o Spring procure sozinho por beans a partir do pacote br.blog.javasimples.spring (incluindo todos os subpacotes).

Porém o Spring só vai saber quais são os beans se eles estiverem identificados. Para fazer isso basta anotarmos os beans com uma das seguintes anotações:

• @Component – Uma anotação de propósitos gerais para identificar um bean;
• @Controller – Indica que o bean é um controlador do Spring Web MVC;
• @Repository – Indica que a classe é um repositório de dados;
• @Service – Indica que a classe é um serviço.

OBS: Para @Controller, @Repository e @Service existem situações em que essas anotações possuem um tratamento especial. Bateu a curiosidade? Go go Google! hehehe

Como em nossa pequena aplicação nós não precisaremos de nenhum comportamento especial podemos simplesmente anotar as nossas classes que representam beans para o container com @Component:

@Component
public class Computador {
 
	// ...
 
}

@Component
public class DualCore implements Processador {
 
	// ...
 
}

@Component
@MonitorCRT
public class Monitor17 implements Monitor {
 
	// ...
 
}

@Component
@Monitor19
@MonitorLED
public class MonitorLED19 implements Monitor {
 
	// ...
 
}

@Component
@Monitor22
@MonitorLED
public class MonitorLED22 implements Monitor {
 
	// ...
 
}

Ao executarmos nossa aplicação agora tudo irá funcionar perfeitamente bem (ou pelo menos deveria hehehe).

É nesse momento que você tem sua última epifania do post e pergunta: “ué, lá na classe Main.java nós buscamos o computador pelo ID dele, como o Spring pegou a classe certa?”.

Muito bem observado! hehehe

Quando o Spring busca e cria automaticamente os beans ele seta o ID de cada bean com o nome da classe no padrão CamelCase para identificadores. Com isso Computador fica computador.

Mas caso haja a necessidade de especificar qual será o ID do bean basta informar na própria anotação @Component:

@Component("pc")
public class Computador {
 
	// ...
 
}

E na hora de recuperar ele basta utilizar o novo ID:

public class Main {
 
	public static void main(String[] args) {
		ApplicationContext context = new ClassPathXmlApplicationContext("br/blog/javasimples/spring/config/applicationContext.xml");
		Computador pc = (Computador) context.getBean("pc");
		pc.ligar();
		pc.somar(2, 2);
	}
 
}

Conclusão

E no fim do post temos um XML de configuração do Spring com apenas 1 linha!

Não sei quanto a vocês mas eu acho isso fantástico, onde for possível minimizar as configurações em XML é melhor pois torna o código bem mais legível e fácil de entender.

O download o projeto está disponível aqui.

Todo e qualquer feedback é muito apreciado, não custa nada escrever o que achou, é rapidinho… hehehe

[]s e até a próxima,

Saab.

Neste post iremos ver como obter ainda mais produtividade no desenvolvimento de aplicações Java + FLEX adicionando o framework dpHibernate ao nosso projeto da Agenda, que foi criado na Parte 1 e melhorado na Parte 2 dessa série.

Para utilizarmos o dpHibernate com todo o seu potencial precisaremos melhorar um pouco mais a nossa agenda pois até agora temos apenas uma entidade no projeto: o Contato. Iremos adicionar a entidade Pessoa, sendo assim, Contato passará a ser uma entidade filha de Pessoa. Em outras palavras: uma Pessoa poderá ter nenhum ou muitos Contatos.

Mas vamos a um pouco de teoria antes (caso você já conheça o dpHibernate pode pular para a parte onde a ação começa a acontecer hehehe):

O QUE É dpHibernate?

De acordo com o site do projeto:

dpHibernate is a custom Flex Library and a custom BlazeDS Hibernate adapter that work together to give you support for lazy loading of hibernate objects from inside your flex applications.

dpHibernate é uma biblioteca para projetos Flex e um adaptador customizado do BlazeDS com suporte para o Hibernate que trabalham juntos para proporcionar suporte a lazy loading de objetos hibernate a partir da sua aplicação flex.

Quer dizer, o dpHibernate é composto por dois projetos: uma biblioteca que será referenciada no projeto FLEX (um arquivo .swc) e outra biblioteca que vai ser referenciada no projeto Java (arquivo .jar) que vão proporcionar o lazy loading de objetos do hibernate a partir da sua aplicação FLEX!!

Vamos facilitar ainda mais com um exemplo:

Vamos pensar nas entidades que vamos utilizar daqui a pouco: Pessoa e Contato.

Na classe Pessoa nós vamos ter uma lista de Contato:

public class Pessoa {
 
    // Outros atributos
 
    @OneToMany(fetch=FetchType.LAZY, ...)
    private List contatos;
 
    // Getters e setters
 
}

Se antes de enviarmos uma Pessoa do Java para o FLEX não executarmos o método getContatos() do objeto Pessoa a lista não será inicializada pois está marcada para ser carregada preguiçosamente (FetchType.LAZY), e consequentemente não será enviada para o FLEX.

OBS: isso acontece porque estamos utilizando o Spring BlazeDS Integration no nosso projeto, e ele possui essa funcionalidade, somente listas inicializadas são enviadas para o FLEX.

Mas o que acontece caso eu queira a lista de contatos no FLEX? Ou inicializamos a lista antes de enviar o objeto para o FLEX, ou seja, executar o getter da lista, ou então quando precisarmos da lista no FLEX nós fazemos mais uma chamada remota para carregar a lista.

Pensando em performance o correto é carregar a lista somente quando realmente precisarmos dela, quando abrir a tela dos contatos por exemplo.

E é exatamente esta a função do dpHibernate! A primeira vez que uma lista for acessada (na aplicação FLEX) o dpHibernate vai verificar se essa lista já foi carregada ou não e caso ela não tenha sido ele irá se encarregar de fazer uma chamada remota para carregá-la. Tudo isso de uma maneira completamente transparente para o programador!

Agora que já sabemos como o dpHibernate funciona vamos preparar a nossa agenda adicionando a entidade Pessoa.

ADICIONANDO A ENTIDADE PESSOA

Na Parte 2 fizemos uma agenda que funcionava em torno de apenas uma entidade: Contato. Ou seja, tinhamos um DAO e um Service para o Contato. Tudo era relacionado com Contato.

Agora vamos adicionar um relacionamento ao contato, vamos seguir o seguinte diagrama de classes:

Com isso a nossa aplicação não vai mais girar em torno de Contato, e sim em torno de Pessoa, ou seja, ao invés de um DAO e um Service para Contato, eles serão para Pessoa. Como Contato passou a ser uma entidade filha, ela vai ser gerenciada através do “seu pai”, a pessoa.

Como essa alteração vai ocupar um bom espaço aqui do post eu sugiro que baixe as classes (e o ddl para o banco) que utilizaremos como base.

Aproveitei e dei uma arrumada no layout da nossa aplicação, agora ela está assim:

Muito bem, agora que a aplicação já está com um relacionamento podemos partir para a parte interessante do post, configurar o dpHibernate!

CONFIGURANDO O dpHibernate

A primeira coisa a se fazer é baixar as bibliotecas. Elas podem ser pegas através do site do projeto ou podem ser pegas aqui no Java Simples.

Por que pegar as bibliotecas aqui? Pois eu corrigi um pequeno probleminha no projeto (descrito nesse link). O problema que acontece na última versão disponível do projeto é na deserialização de identificadores (o id da entidade) do tipo java.lang.Long, o deserializador do projeto se confunde e tenta converter o valor vindo do FLEX para o tipo java.lang.Integer. Apliquei um pequeno patch disponibilizado por um dos commiters do projeto e tudo passou a funcionar perfeitamente, portanto caso você – assim como eu – utilize o tipo java.lang.Long para os identificadores sinta-se a vontade para baixar as bibliotecas já corrigidas ou para aplicar o patch no projeto (os códigos fonte podem ser pegos através da página do projeto).

OBS: no pacote de bibliotecas disponíveis aqui no blog também estão algumas bibliotecas adicionais necessárias para o correto funcionamento do projeto.

Com as bibliotecas baixadas basta adicionar os arquivos .jar no classpath do projeto Java e o arquivo .swc ao classpath do projeto FLEX.

Mãos à obra então!

Vamos começar alterando nossas entidades (classes do modelo). Para permitir que as classes sejam monitoradas pelo dpHibernate precisamos fazer apenas algumas alterações nelas: as classes Java devem estender HibernateProxy e sobrescrever o método getProxyKey() retornando um identificador único (o id funciona muito bem não? hehe) e as classes AS devem esternder HibernateBean e receber o metadado [Managed].

Pessoa.java

/**
 * Clase que representa uma pessoa na agenda.
 * Cada pessoa poderá ter vários {@link Contato contatos} (email, telefone,
 * site, ...).
 *
 * @author Felipe Saab
 */
@Entity
@Table(name = "PESSOA")
public class Pessoa extends HibernateProxy {
 
	private static final long serialVersionUID = 3815773591498770002L;
 
	@Id
	@GeneratedValue(strategy=GenerationType.AUTO)
	@Column(name = "ID", length=11, nullable=false)
	private Long id;
 
	@Column(name = "NOME", nullable = false, length = 100)
	private String nome;
 
	@OneToMany(fetch = FetchType.LAZY, mappedBy = "pessoa", cascade = CascadeType.ALL, orphanRemoval = true)
	private List contatos;
 
	@Override
	public Object getProxyKey() {
        	return id;
	}
 
	// Getters e Setters e outros métodos
 
}

Contato.java

/**
 * Classe que representa um contato de uma {@link Pessoa pessoa} na agenda.
 *
 * @author Felipe Saab
 */
@Entity
@Table(name = "CONTATO")
public class Contato extends HibernateProxy {
 
	private static final long serialVersionUID = -1549466344815889020L;
 
	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	@Column(name = "ID", length = 11, nullable = false)
	private Long id;
 
	@Column(name = "TIPO", length = 50, nullable = false)
	private String tipo;
 
	@Column(name = "CONTATO", length = 100)
	private String contato;
 
	@ManyToOne(fetch = FetchType.LAZY)
	@JoinColumn(name = "ID_PESSOA", referencedColumnName = "ID")
	private Pessoa pessoa;
 
	@Override
	public Object getProxyKey() {
		return id;
	}
 
	// Getters e Setters e outros métodos
 
}

Pessoa.as

[Managed]
[RemoteClass(alias="br.blog.javasimples.agenda.model.Pessoa")]
public class Pessoa extends HibernateBean
{
	public var id:Number;
	public var nome:String;
	public var contatos:ArrayCollection;
 
	public function Pessoa()
	{
	}
 
	public function addContato(contato:Contato):void
	{
		if (!contatos)
		{
			contatos = new ArrayCollection();
		}
		contatos.addItem(contato);
		contato.pessoa = this;
		contatos.refresh();
	}
 
	public function removeContato(contato:Contato):void
	{
		if (!contatos) return;
		var index:int = contatos.getItemIndex(contato);
		if ( index == -1 ) return;
		contatos.removeItemAt(index);
		contatos.refresh();
	}
}

Contato.as

[Managed]
[RemoteClass(alias="br.blog.javasimples.agenda.model.Contato")]
public class Contato extends HibernateBean
{
	public var id:Number;
	public var tipo:String;
	public var contato:String;
	public var pessoa:Pessoa;
 
	public function Contato()
	{
	}
}

Modelo preparado, podemos partir então para a configuração da aplicação web e do Spring:

A estrutura de pastas e arquivos da aplicação web ficou assim:

Passamos a ter 3 arquivos de configuração do Spring: WEB-INF\spring\applicationContext.xml, WEB-INF\spring\persistence-config.xml e WEB-INF\spring\flex-config.xml. Mas vamos entendê-los mais a fundo nas próximas linhas, vamos começar do começo:

web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="http://java.sun.com/xml/ns/javaee" 
	xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_4.xsd"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_4.xsd"
	id="WebApp_ID" version="2.4">
 
	<!-- Listener responsável por iniciar o container do Spring -->
	<listener>
		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>
 
	<!-- Localização do arquivo de configuração para o listener configurar o 
		container -->
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>/WEB-INF/spring/applicationContext.xml</param-value>
	</context-param>
 
	<!-- Filtro para manter sempre - e apenas! - uma sessão do Hibernate aberta -->
	<filter>
		<filter-name>openSessionInViewFilter</filter-name>
		<filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class>
	</filter>
 
	<!-- DispatcherServlet para o Spring BlazeDS Integration -->
	<servlet>
		<servlet-name>springMessageBroker</servlet-name>
		<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
		<init-param>
			<param-name>contextConfigLocation</param-name>
			<param-value>/WEB-INF/spring/flex-config.xml</param-value>
		</init-param>
	</servlet>
 
	<!-- Mappings -->
	<filter-mapping>
		<filter-name>openSessionInViewFilter</filter-name>
		<url-pattern>/*</url-pattern>
	</filter-mapping>
 
	<servlet-mapping>
		<servlet-name>springMessageBroker</servlet-name>
		<url-pattern>/messagebroker/*</url-pattern>
	</servlet-mapping>
</web-app>

No deployment descriptor (vulgo web.xml hehehe) definimos que o Spring vai inicializar um container para a aplicação através do listener ContextLoaderListener, que o Hibernate vai ter somente uma sessão aberta durante toda a vida da nossa aplicação (isso é essencial para o lazy loading funcionar corretamente) através do filtro OpenSessionInViewFilter, e por fim definimos o DispatcherServlet do Spring MVC requerido pelo Spring BlazeDS Integration (como vimos na Parte 2).

Com isso já achamos onde são usados 2 arquivos de configuração do Spring: o applicationContext.xml vai conter os beans que poderão ser acessados de qualquer lugar da aplicação pois estarão no contexto da aplicação (ApplicationContext) e o flex-config.xml que é arquivo de configuração para o DispatcherServlet vai conter as configurações do Spring BlazeDS Integration.

OBS: caso não se lembre do servlet DispatcherServlet ou caso não conheça o Spring MVC eu sugiro que dê uma olhada no post: Spring Framework Parte 5 -> Spring Web MVC.

Vamos por partes então, primeiro o applicationContext.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="http://www.springframework.org/schema/beans 
                           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd 
                           http://www.springframework.org/schema/context 
                           http://www.springframework.org/schema/context/spring-context.xsd">
 
	<!-- Configurações de persistência -->
	<import resource="/spring/persistence-config.xml"/>
 
	<!-- Habilita a injeção de dependência através de anotações -->
	<context:annotation-config />
 
	<!-- Faz com que os Services sejam beans gerenciados pelo container do Spring -->
	<context:component-scan base-package="br.blog.javasimples.agenda.service.impl" />
 
	<!-- Faz com que os DAOs sejam beans gerenciados pelo container do Spring -->
	<context:component-scan base-package="br.blog.javasimples.agenda.dao.impl" />
 
</beans>

E de cara já vimos onde é utilizado o último arquivo de configuração, essa foi rápida né! hehehe

Os maiores motivos para a separação dos arquivos de configuração foi para eles ficarem mais legíveis e coesos, sendo assim o arquivo WEB-INF\spring\persistence-config.xml vai conter somente os beans relacionados à persistência dos dados. Para carregar esses beans no contexto da aplicação utilizamos a tag <import>, com isso todos os beans que estiverem dentro do arquivo persistence-config.xml também serão carregados no contexto da aplicação.

Mas no applicationContext.xml além da inclusão dos beans relacionados à persistência foram definidas também as tags responsáveis por permitir a injeção de dependência e o gerenciamento dos Services e DAOs através de anotações.

persistence-config.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
	xmlns:p="http://www.springframework.org/schema/p"
	xmlns:tx="http://www.springframework.org/schema/tx"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
						http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.0.xsd">
 
	<!-- DataSource -->
	<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
		<property name="driverClassName">
			<value>com.mysql.jdbc.Driver</value>
		</property>
 
		<property name="url">
			<value>jdbc:mysql://localhost:3306/javasimples_agenda</value>
		</property>
 
		<property name="username">
			<value>usuario</value>
		</property>
 
		<property name="password">
			<value>senha</value>
		</property>
	</bean>
 
	<!-- Hibernate SessionFactory -->
	<bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
 
		<property name="dataSource">
			<ref local="dataSource" />
		</property>
 
		<!-- Carrega todos os Beans -->
		<property name="packagesToScan">
			<list>
				<value>br.blog.javasimples.agenda.model</value>
			</list>
		</property>
 
		<!-- Propriedades do Hibernate -->
		<property name="hibernateProperties">
			<props>
				<prop key="hibernate.dialect">org.hibernate.dialect.MySQL5InnoDBDialect</prop>
				<prop key="hibernate.show_sql">true</prop>
				<prop key="hibernate.format_sql">true</prop>
			</props>
		</property>
	</bean>
 
	<!-- Habilita as transações nas operações do banco -->
	<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
		<property name="sessionFactory">
			<ref bean="sessionFactory" />
		</property>
	</bean>
 
	<tx:annotation-driven />
 
</beans>

Apesar do arquivo ser um pouco grande não há muita coisa a ser dita sobre esses beans, foram definidos um DriverManagerDataSource para conversar com o banco de dados, a SessionFactory responsável pelo mapeamento do Hibernate e o HibernateTransactionManager responsável pelas transações das operações do Hibernate.

Dando continuidade aos arquivos de configuração vamos ver os beans que serão definidos no escopo do DispatcherServlet do Spring BlazeDS Integration:

flex-config.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"
	xmlns:flex="http://www.springframework.org/schema/flex"
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="http://www.springframework.org/schema/beans 
                           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd 
                           http://www.springframework.org/schema/flex
                           http://www.springframework.org/schema/flex/spring-flex-1.0.xsd
                           http://www.springframework.org/schema/context 
                           http://www.springframework.org/schema/context/spring-context.xsd">
 
	<!-- Injeção de dependência (e outras configurações) através de anotações -->
	<context:annotation-config />
 
	<!-- MessageBroker vai utilizar o adaptador do dpHibernate -->
	<flex:message-broker>
		<flex:remoting-service default-adapter-id="dpHibernateRemotingAdapter" default-channels="my-amf" />
	</flex:message-broker>
 
	<!-- Adaptador remoto que vai interceptar as mensagens do FLEX e vai aplicar a lógica do dpHibernate -->
	<bean id="dpHibernateRemotingAdapter"
		class="org.springframework.flex.core.ManageableComponentFactoryBean">
		<constructor-arg value="org.dphibernate.adapters.SpringAwareRemotingAdapter" />
		<property name="properties">
			<value>
				{
				"dpHibernate" :
				{
				"serializerFactory" : "org.dphibernate.serialization.SpringContextSerializerFactory"
				}
				}
	        </value>
		</property>
	</bean>
 
	<!-- Serviço que será utilizado para o lazy loading -->
	<bean id="dataAccessService" class="org.dphibernate.services.SpringDataAccessService" autowire="constructor">
		<flex:remoting-destination />
	</bean>
 
	<!-- Cache que evita que um mesmo objeto seja serializado mais de uma vez -->
	<bean id="dpHibernateCache" class="org.dphibernate.serialization.DPHibernateCache" scope="prototype" />
 
	<!-- Serializador e Deserializador que enviam (serializam) e recebem (deserializam) os objetos do FLEX -->
	<bean id="dpHibernateSerializer" class="org.dphibernate.serialization.HibernateSerializer" scope="prototype"/>
	<bean id="dpHibernateDeserializer" class="org.dphibernate.serialization.HibernateDeserializer" scope="prototype" />
 
	<!-- Gerencia o CRUD das entidades. -->
	<bean id="objectChangeUpdater"
		class="org.dphibernate.persistence.state.BaseSpringWiredObjectChangeUpdater"
		scope="prototype"/>
 
	<!-- Utilizado nas operações CRUD para converter os proxys novamente para as entidades -->
	<bean id="hibernateProxyResolver" class="org.dphibernate.persistence.state.DbProxyResolver" scope="prototype">
		<constructor-arg ref="sessionFactory" />
	</bean>
 
</beans>

Aqui é onde a mágica do dpHibernate acontece! hehehe

Começando de cima para baixo temos:

A injeção de dependência nesse contexto (DispatcherServlet) também poderá ser utilizada com anotações graças à tag <context:annotation-config />, definimos o MessageBroker (não lembra dele? dê uma lidinha rápida na Parte 1 então) através da tag <flex:message-broker> e definimos que o adaptador utilizado para processar as requisições será o dpHibernateRemotingAdapter (definido imediatamente abaixo).

Após o adaptador é definido o dataAccessService que vamos utilizar para cuidar das operações CRUD e do lazy loading das nossas entidades, com isso os nossos services vão conter apenas as regras de negócio envolvidas nas entidades, nada mais de CRUD nos services!

OBS: a tag <flex:remoting-destination /> é responsável por explicitamente definir o bean como um destination para o FLEX, ou seja, quando criarmos um RemoteObject podemos definir o destination = dataAccessService e essa classe (org.dphibernate.services.SpringDataAccessService) vai receber as requisições.

Logo em seguida é definida uma classe responsável por cachear os objetos serializados para evitar que eles sejam serializados mais de uma vez (assunto meio paralelo, então deixa pra outra hora.. heheh) e o serializador e o deserializador utilizados para converter os objetos Java para AMF e vice versa.

Depois temos o objectChangeUpdater que – de um jeito muito inteligente – cuida de todo o CRUD das entidades gerenciadas pelo dpHibernate. Aconselho fortemente a fazer checkout do código fonte e dar uma olhada.

E por fim temos o hiberanteProxyResolver, classe responsável por manter a integridade dos objetos que ele vai proxiar entre as diversas operações que realizar. Toda classe gerenciada pelo dpHiberante possui uma proxyKey, tanto que sobrescrevemos o getter dessa chave nas entidades para garantir que seja retornado sempre um valor único. O dpHibernate utiliza essa chave para saber qual objeto foi enviado do FLEX para o Java e utilizar o objeto que já estava na sessão do hibernate, mantendo assim a integridade dos dados. Bem simples e bem legal não?

Bom, é isso! Com isso terminamos de configurar o dpHibernate do lado servidor da nossa aplicação. Vamos passar então para o lado do cliente, a aplicação FLEX:

AgendaF.mxml

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
			   xmlns:s="library://ns.adobe.com/flex/spark"
			   xmlns:mx="library://ns.adobe.com/flex/mx"
			   xmlns:dphibernate="http://www.dphibernate.org/2010/mxml"
			   applicationComplete="onApplicationComplete(event)">
 
	<fx:Script>
		<![CDATA[
 
			// Imports...
 
			private var pessoaService:RemoteObject=new RemoteObject("pessoaService");
 
			[Bindable]
			private var agenda:ArrayCollection=new ArrayCollection();
 
			/**
			 * Carrega todas as pessoas já cadastradas.
			 */
			private function getAgenda():void
			{
				var token:AsyncToken=pessoaService.getAgenda();
				token.addResponder(new mx.rpc.Responder(getAgendaSucesso, erro));
			}
 
			/**
			 * Agenda carregada com sucesso.
			 */
			private function getAgendaSucesso(event:ResultEvent):void
			{
				this.agenda=event.result as ArrayCollection;
			}
 
			/**
			 * Quando ocorrer algum erro nas chamadas remotas.
			 */
			private function erro(event:FaultEvent):void
			{
				Alert.show("Ocorreu o seguinte erro: " + event.fault.faultString);
			}
 
			/**
			 * Inicializações gerais.
			 */
			protected function onApplicationComplete(event:FlexEvent):void
			{
				var remoteObject:HibernateRemoteObject=new HibernateRemoteObject("dataAccessService");
				HibernateManaged.defaultHibernateService=remoteObject;
				this.getAgenda();
			}
		]]>
	</fx:Script>
 
	<mx:Form width="500">
		<mx:FormItem label="Nome"
					 width="100%"
					 direction="horizontal">
			<s:TextInput id="txtNome"
						 width="100%"/>
			<s:Button label="Salvar"
					  click="this.salvaPessoa()"/>
		</mx:FormItem>
 
		<mx:HBox width="100%">
			<mx:DataGrid id="grdPessoa"
						 width="100%"
						 dataProvider="{this.agenda}"
						 doubleClickEnabled="true"
						 doubleClick="mostraContatos(agenda.getItemAt(grdPessoa.selectedIndex))">
				<mx:columns>
					<mx:DataGridColumn headerText="Nome"
									   dataField="nome"/>
 
					<!-- Coluna que vai ter o botão dos contatos -->
					<mx:DataGridColumn headerText="Contatos"
									   width="60">
						<mx:itemRenderer>
							<fx:Component>
								<mx:HBox horizontalAlign="center">
									<mx:Button label="Exibir"
											   icon="@Embed('br/blog/javasimples/agenda/imagens/contatos.png')"
											   width="25"
											   click="outerDocument.mostraContatos(data)"/>
								</mx:HBox>
							</fx:Component>
						</mx:itemRenderer>
					</mx:DataGridColumn>
 
					<!-- Coluna que vai ter o botão para a exclusão -->
					<mx:DataGridColumn headerText="Apagar"
									   width="50">
						<mx:itemRenderer>
							<fx:Component>
								<mx:HBox horizontalAlign="center">
									<mx:Button icon="@Embed('br/blog/javasimples/agenda/imagens/apagar.png')"
											   width="25"
											   click="outerDocument.apagaPessoa(data)"/>
								</mx:HBox>
							</fx:Component>
						</mx:itemRenderer>
					</mx:DataGridColumn>
				</mx:columns>
			</mx:DataGrid>
		</mx:HBox>
	</mx:Form>
 
</s:Application>

Nossa aplicação sofreu uma pequena mudança apenas para ter a interface melhorada, foram adicionados dois ícones na grid: um para mostrar os contatos e outro para remover a pessoa. Ambas funcionalidades serão vistas no próximo tópico, vamos nos atentar primeiro à configuração do dpHibernate.

É na função onApplicationComplete que nós faremos a única configuração no projeto FLEX: vamos criar um Service padrão para o dpHibernate poder utilizar para as operações CRUD. Isso é feito criando um HibernateRemoteObject que vai enviar as requisições para o service que definimos no contexto do DispatcherServlet: o dataAccessService.

E pronto! Java e FLEX configurados!!

SALVAR, ATUALIZAR E APAGAR REGISTROS

Vamos então utilizar as vantagens desse mundo de configurações né… hehehehe

Repare no código do arquivo AgendaF.mxml (listagem anterior) que quando o usuário clicar no botão Salvar será chamada a função salvaPessoa():

/**
 * Salva uma pessoa.
 */
private function salvaPessoa():void
{
	var pessoa:Pessoa=new Pessoa();
	pessoa.nome=txtNome.text;
	pessoa.contatos=new ArrayCollection();
 
	var token:AsyncToken=pessoa.save();
	token.addResponder(new mx.rpc.Responder(salvaPessoaSucesso, erro));
}
 
/**
 * Pessoa salva com sucesso.
 */
private function salvaPessoaSucesso(event:ResultEvent):void
{
	Alert.show("Pessoa salva com sucesso!");
 
	// Recupera a agenda com todas as pessoas
	this.getAgenda();
}

Para salvar ou atualizar (save ou update) uma entidade gerenciada pelo dpHiberante devemos apenas chamar a sua função save(). Ela funciona do mesmo modo que uma chamada a um método remoto, ou seja, retorna um AsyncToken referente à chamada para podermos saber se houve sucesso ou erro durante sua execução.

Se repararmos no código do botão da grid referente a apagar a pessoa veremos que ele chama a função apagaPessoa():

/**
 * Apaga a pessoa e seus contatos.
 */
public function apagaPessoa(obj:Object):void
{
	var pessoa:Pessoa=obj as Pessoa;
	if (pessoa)
	{
		var token:AsyncToken=pessoa.deleteRecord();
		token.addResponder(new mx.rpc.Responder(apagaPessoaSucesso, erro));
	}
}
 
/**
 * Pessoa apagada com sucesso.
 */
private function apagaPessoaSucesso(event:ResultEvent):void
{
	Alert.show("Pessoa apagada com sucesso!");
 
	// Recupera a agenda com todas as pessoas
	this.getAgenda();
}

Do mesmo modo que a função save() as entidades gerenciadas pelo dpHibernate passam a ter também a função deleteRecord() que é um tanto quanto intuitiva certo? hehehe Apaga do banco a entidade que chamou a função.

E com isso terminamos o cadastro básico de Pessoa, vamos agora colocar os contatos na aplicação:

Contatos.mxml

<?xml version="1.0" encoding="utf-8"?>
<s:TitleWindow xmlns:fx="http://ns.adobe.com/mxml/2009"
			   xmlns:s="library://ns.adobe.com/flex/spark"
			   xmlns:mx="library://ns.adobe.com/flex/mx"
			   creationComplete="init()"
			   title="Contatos"
			   close="fechaJanela()">
 
	<fx:Script>
		<![CDATA[
 
			// Imports...
 
			[Bindable]
			private var tipos:ArrayCollection;
 
			[Bindable]
			public var pessoa:Pessoa;
 
			/**
			 * Inicializações.
			 */
			private function init():void
			{
				this.tipos=new ArrayCollection();
				this.tipos.addItem("Residencial");
				this.tipos.addItem("Comercial");
				this.tipos.addItem("Celular");
				this.tipos.addItem("Email");
				this.tipos.addItem("Website");
			}
 
			/**
			 * Fecha o formulário.
			 */
			private function fechaJanela():void
			{
				PopUpManager.removePopUp(this);
			}
 
			/**
			 * Cria um novo contato e adiciona a lista de contatos da pessoa.
			 */
			private function criaContato():void
			{
				var contato:Contato=new Contato();
				contato.tipo=cbbTipo.selectedItem;
				contato.contato=txtContato.text;
				contato.pessoa=this.pessoa;
 
				if (pessoa.contatos == null)
					pessoa.contatos=new ArrayCollection();
 
				pessoa.addContato(contato);
				var token:AsyncToken=pessoa.save();
				token.addResponder(new mx.rpc.Responder(contatoSalvo, erro));
			}
 
			/**
			 * Confirmação de que o contato foi inserido.
			 */
			private function contatoSalvo(event:ResultEvent):void
			{
				Alert.show("Contato salvo com sucesso!");
			}
 
			/**
			 * Quando ocorrer algum erro nas chamadas remotas.
			 */
			private function erro(event:FaultEvent):void
			{
				Alert.show("Ocorreu o seguinte erro: " + event.fault.faultString);
			}
 
			/**
			 * Remove o contato da lista de contatos da pessoa.
			 */
			public function apagaContato(obj:Object):void
			{
				var c:Contato = obj as Contato;
				pessoa.removeContato(c);
				c.deleteRecord();
			}
		]]>
	</fx:Script>
 
	<mx:Form>
		<mx:FormItem label="Tipo"
					 width="100%"
					 direction="horizontal">
			<s:ComboBox id="cbbTipo"
						dataProvider="{tipos}"
						selectedIndex="0"/>
			<mx:Spacer width="100%"
					   height="10"/>
			<s:Button label="Adicionar"
					  click="criaContato()"/>
		</mx:FormItem>
		<mx:FormItem label="Contato"
					 direction="horizontal"
					 width="100%">
			<s:TextInput id="txtContato"
						 width="100%"/>
		</mx:FormItem>
 
		<mx:HBox width="100%">
			<mx:DataGrid id="grdContato"
						 width="100%"
						 dataProvider="{this.pessoa.contatos}">
				<mx:columns>
					<mx:DataGridColumn headerText="Tipo"
									   dataField="tipo"
									   width="90"/>
					<mx:DataGridColumn headerText="Contato"
									   dataField="contato"/>
					<mx:DataGridColumn headerText="Apagar"
									   width="50">
						<mx:itemRenderer>
							<fx:Component>
								<mx:HBox horizontalAlign="center">
									<mx:Button icon="@Embed('br/blog/javasimples/agenda/imagens/apagar.png')"
											   width="25"
											   click="outerDocument.apagaContato(data)"/>
								</mx:HBox>
							</fx:Component>
						</mx:itemRenderer>
					</mx:DataGridColumn>
				</mx:columns>
			</mx:DataGrid>
		</mx:HBox>
	</mx:Form>
</s:TitleWindow>

O formulário de contatos segue o mesmo padrão do de pessoa: ao clicar no botão salvar é criado um novo Contato, adicionado na lista de contatos da pessoa e então a pessoa é salva novamente para persistir o novo contato no banco (em cascata); para remover um contato nós apenas o removemos da lista de contatos da pessoa e o apagamos do banco. Simples assim!

Para mostrar a tela de contatos, perceba que quando o botão referente a essa função for clicado ele vai chamar a função mostraContatos():

/**
 * Abre uma nova janela com os contatos da pessoa selecionada.
 */
public function mostraContatos(obj:Object):void
{
	var pessoa:Pessoa=obj as Pessoa;
	if (pessoa)
	{
		var formContatos:Contatos=new Contatos();
		formContatos.pessoa=pessoa;
		PopUpManager.addPopUp(formContatos, this, true);
		PopUpManager.centerPopUp(formContatos);
	}
}

Criamos o formulário de contatos, passamos a pessoa que vai ter os contatos exibidos para dentro dele e por fim o adicionamos na tela utilizando o PopUpManager.

LAZY LOADING

Mas no fim das contas, como funciona o lazy loading que nós nem vimos acontecer? hehehehe

Repare na grid que mostra os contatos:

<mx:HBox width="100%">
	<mx:DataGrid id="grdContato"
				 width="100%"
				 dataProvider="{this.pessoa.contatos}">
		<mx:columns>
			<mx:DataGridColumn headerText="Tipo"
							   dataField="tipo"
							   width="90"/>
			<mx:DataGridColumn headerText="Contato"
							   dataField="contato"/>
			<mx:DataGridColumn headerText="Apagar"
							   width="50">
				<mx:itemRenderer>
					<fx:Component>
						<mx:HBox horizontalAlign="center">
							<mx:Button icon="@Embed('br/blog/javasimples/agenda/imagens/apagar.png')"
									   width="25"
									   click="outerDocument.apagaContato(data)"/>
						</mx:HBox>
					</fx:Component>
				</mx:itemRenderer>
			</mx:DataGridColumn>
		</mx:columns>
	</mx:DataGrid>
</mx:HBox>

O dataProvider da grid é o atributo contatos do objeto pessoa. Quando o formulário está sendo carregado e a grid executa o primeiro get no atributo o dpHibernate já se encarrega de fazer uma chamada remota para carregar os contatos.

Quando utilizamos atributos que irão ser carregados preguiçosamente (lazy loading) no MXML (como na grid) não precisamos nos preocupar com absolutamente nada, o FLEX e o dpHibernate se encarregam de tudo. Mas e quando precisamos utilizar tais atributos no AS (em uma função)?

Todo objeto que sofre lazy loading dispara o evento LazyLoadEvent. Tal evento possui 3 tipos:

LazyLoadEvent.pending: é disparado antes de fazer a chamada remota que carregará o objeto;

LazyLoadEvent.failed: é disparado quando ocorre uma falha no processo de carregamento do objeto;

LazyLoadEvent.complete: é disparado quando o carregamento foi concluído, ou seja, a chamada remota retornou com os dados e o objeto já foi atualizado com tais dados.

Então vamos fazer uma pequena alteração na função que abre o formulário de contatos para ver se isso verdade:

/**
 * Abre uma nova janela com os contatos da pessoa selecionada.
 */
public function mostraContatos(obj:Object):void
{
	var pessoa:Pessoa=obj as Pessoa;
	if (pessoa)
	{
		var formContatos:Contatos=new Contatos();
		if (pessoa.contatos.length > 0)
			pessoa.contatos.getItemAt(0).addEventListener(LazyLoadEvent.complete, formContatos.contatosCarregados);
		formContatos.pessoa=pessoa;
		PopUpManager.addPopUp(formContatos, this, true);
		PopUpManager.centerPopUp(formContatos);
	}
}

Tudo bem, concordo que não é um código muito bonito… hehehe Mas como vimos a pouco, quem dispara o evento é o objeto que vai ser carregado preguiçosamente, sendo assim precisamos acessar algum desses objetos para poder colocar um listener nele. Devemos sempre ter certeza de que existe pelo menos um contato a ser carregado para poder acessá-lo e colocar um listener nele pois caso não fizéssemos a verificação antes e tentássemos abrir o formulário de contatos para uma pessoa que não tem nenhum contato nós iriamos receber um erro em tempo de execução.

Devemos sempre tomar muito cuidado ao programar as funções em AS, qualquer errinho vai estourar uma mensagem não muito agradável para o usuário final.

Dando continuidade, o listener que adicionamos foi para chamar a função contatosCarregados() do formulário de contatos, vamos a ela então:

/**
 * Mostra uma mensagem avisando que os contatos foram carregados.
 */
public function contatosCarregados(event:LazyLoadEvent):void
{
	Alert.show("A lista de contatos foi carregada com sucesso!");
}

Com isso, a primeira vez que abrirmos o formulário de contatos de uma pessoa que possua pelo menos um contato a ser carregado iremos receber a mensagem:

CARREGAMENTO EM LOTES (BATCH LOADING)

Uma última coisa (e não menos importante) para fecharmos esse post: carregamento em lotes.

Sem muita teoria, vou demonstrar com exemplos pois vai ser muito mais facil de entender né.

Eu criei uma pessoa e adicionei 3 contatos a ela, na próxima vez que eu entrar no sistema e abrir o formulário de contatos dela e seus contatos forem carregados reparem na saída impressa no console (ou arquivos de log) do tomcat:

{operation})****************loadBean
{deserialize} 0
Hibernate:
    select
        contato0_.ID as ID0_0_,
        contato0_.CONTATO as CONTATO0_0_,
        contato0_.ID_PESSOA as ID4_0_0_,
        contato0_.TIPO as TIPO0_0_
    from
        CONTATO contato0_
    where
        contato0_.ID=?
{invoke} 10
{serialize} 1
{operation})****************loadBean
{deserialize} 1
Hibernate:
    select
        contato0_.ID as ID0_0_,
        contato0_.CONTATO as CONTATO0_0_,
        contato0_.ID_PESSOA as ID4_0_0_,
        contato0_.TIPO as TIPO0_0_
    from
        CONTATO contato0_
    where
        contato0_.ID=?
{invoke} 15
{serialize} 0
{operation})****************loadBean
{deserialize} 0
Hibernate:
    select
        contato0_.ID as ID0_0_,
        contato0_.CONTATO as CONTATO0_0_,
        contato0_.ID_PESSOA as ID4_0_0_,
        contato0_.TIPO as TIPO0_0_
    from
        CONTATO contato0_
    where
        contato0_.ID=?
{invoke} 1
{serialize} 1

Cada vez que o dpHibernate imprime {operation})*********nome_da_operacao quer dizer que chegou uma chamada remota! Repare que até tem quanto tempo levou para deserializar a chamada e para serializar a resposta.

Quer dizer, 1 chamada remota para carregar cada contato… Vamos e venhamos, isso não é muito eficiente né.

Para suprir esse problema o dpHibernate consegue trabalhar com lotes de requisições (explicados detalhadamente pelo criador neste post), ou seja, ao invés de uma requisição para cada contato, todas são agrupadas em um lote e são enviadas para o servidor em apenas uma chamada remota.

Para habilitar isso precisamos de mais uns ajustes nas configurações (coisa rápida, prometo!).

Vamos adicionar um novo bean no contexto do DispatcherServlet do Spring BlazeDS Integration (arquivo WEB-INF\spring\flex-config.xml):

<bean id="proxyBatchLoader" class="org.dphibernate.services.ProxyBatchLoader" autowire="constructor" />

E na função onApplicationComplete() onde definimos o service padrão para o CRUD do dpHibernate vamos indicar que ele deve começar a enviar as requisições em lotes:

/**
 * Inicializações gerais.
 */
protected function onApplicationComplete(event:FlexEvent):void
{
	var remoteObject:HibernateRemoteObject=new HibernateRemoteObject("dataAccessService");
	remoteObject.bufferProxyLoadRequests=true;
	HibernateManaged.defaultHibernateService=remoteObject;
	this.getAgenda();
}

E pronto! Ao rodar a aplicação novamente, abrir o formulário de contatos da pessoa que possui 3 contatos e observar o console (ou log) do tomcat veremos a seguinte saída:

{operation})****************loadProxyBatch
{deserialize} 6
Hibernate:
    select
        this_.ID as ID0_0_,
        this_.CONTATO as CONTATO0_0_,
        this_.ID_PESSOA as ID4_0_0_,
        this_.TIPO as TIPO0_0_
    from
        CONTATO this_
    where
        this_.ID in (
            ?, ?, ?
        )
{invoke} 219
{serialize} 5

Apenas uma requisição que já carregou os 3 contatos!

Agora sim a nossa aplicação está 100%! Bonita, funcional e eficiente!

Os projetos completos (incluindo as biliotecas) podem ser baixados aqui (20MB).

CONCLUSÃO

É isso ai pessoal, o post acabou ficando um pouco longo mas creio que se você leu até aqui não ficou decepcionado com o tempo gasto, certo? hehehe

Um ponto que vale a pena ser comentado é em relação ao nosso Service e nosso DAO de Pessoa, depois de implantar o dpHibernate no nosso projeto vamos ver como eles ficaram:

/**
 * Interface que define os métodos de um serviço para {@link Pessoa}.
 *
 * @author Felipe Saab
 */
public interface PessoaService {
 
	/**
	 * Recupera todas as pessoas da agenda.
	 *
	 * @return Todos as pessoas
	 */
	List getAgenda();
}

/**
 * Interface que define os métodos necessários para o DAO de Pessoa.
 *
 * @author Felipe Saab
 */
public interface PessoaDao {
 
	/**
	 * Recupera todas as pessoas da agenda.
	 *
	 * @return Todos as pessoas
	 */
	List getAgenda();
 
}

Como ficou simples! Sem os métodos referentes ao CRUD (tudo bem, ainda tem um select ai.. dá um desconto poxa.. heheh) o Service e o DAO passam a ter somente a regra de negócio referente a entidade pela qual são responsáveis. A aplicação acaba se tornando mais legível!

Olhando agora para a nossa aplicação e tudo o que fizemos nela desde a Parte 1 dessa série podemos ver que utilizamos vários frameworks para aumentar a nossa produtividade: Spring, Hibernate, Spring BlazeDS Integration e dpHibernate. Com isso conseguimos construir uma aplicação como esta agenda em poucas horas (chegaria em horas mesmo? hehehe), desde o banco de dados até a interface agradável para o usuário final.

O dpHibernate é um framework poderosíssimo (li em blogs que já foi utilizado para projetos de grande porte) e open source! Caso esteja curioso sobre como ele funciona basta fazer checkout no repositório SVN na página do projeto (o que eu aconselho fortemente) e fuçar… muito legal mesmo!

Espero que tenha gostado deste post, todos os feedbacks são importantes, não deixe de comentar por favor.

PS: Caso esteja desenvolvendo um projeto com o dpHibernate sinta-se a vontade para me procurar caso esteja passando por alguns problemas, já passei por vários e você não precisa passar por eles também. =]

[]s e até a próxima,
Saab.

REFERÊNCIAS

[1] Using the ItemRenderer with a DataGrid

[2] Explicitly mapping ActionScript and Java objects

[3] Steps for getting going with dpHibernate

[4] Serialization issue with using primitive type long

[5] Batch loading proxies in dpHibernate

Fala pessoal, finalmente a parte 2 do tutorial da nossa integração Java + FLEX!

CONSIDERAÇÕES INICIAIS

Caso você não tenha visto a Parte 1 do tutorial, por favor, veja ou baixe a aplicação pois a refatoração será feita em cima do projeto desenvolvido no tutorial anterior.

INTRODUÇÃO

Até agora o que temos é uma aplicação com o objetivo de ser uma Agenda de Contatos, porém os contatos estão ficando apenas em memória (uma lista estática na classe ContatoService.java), ao parar o servidor e rodá-lo novamente os contatos anteriormente salvos sumiram.. Ok, para evitar isso vamos persistir os contatos em um banco de dados, e para facilitar ainda mais a nossa vida vamos utilizar o Hibernate para nem nos preocuparmos com SQL, mecher apenas com as classes.

OBS: Por favor não me entenda errado, saber SQL é extremamente importante!! Mesmo utilizando o Hibernate as vezes precisamos construir querys utilizando HQL ou mesmo SQL, mas como nossa aplicação é extremamente simples nós podemos deixar isso de lado e utilizar todas as facilidades que o Hibernate provê.

E tem também o Spring! Ele nos será útil por dois fatores:

Injeção de Dependência: vamos utilizar interfaces e anotações para o Spring injetar os beans que precisamos em cada classe. Por consequência melhorar muito o projeto (design) da nossa aplicação pois as classes ficarão desacopladas (pois utilizaremos as interfaces). Conforme formos escrevendo o código isso ficará mais claro.

Integração com o BlazeDS: vamos utilizar um framework que a SpringSource criou para a integração do Spring com o BlazeDS para não precisarmos de muitas configurações e para termos possibilidade de aproveitar todas as funcionalidades do Spring como segurança e mensagens por exemplo. Para entender melhor sobre este projeto recomendo a leitura da referência [1].

Vamos fazer as coisas por partes então: primeiro vamos adicionar o Spring ao nosso projeto e depois adicionaremos o Hibernate pois ele vai ser um bean gerenciado pelo Spring também.

DOWNLOADS

Spring Framework: Iremos precisar do Spring Framework (utilizarei o 3.1.0 M2) em si e de um outro projeto da SpringSource chamado Spring BlazeDS Integration projetado para facilitar a comunicação do Spring com o FLEX.

Hibernate: No momento em que estou escrevendo este post a última versão é a 3.6.5.

MÃO NA MASSA: SPRING

Vamos começar a escrever códigos então!

Hoje o serviço que o FLEX acessa para recuperar/adicionar os contatos é a classe ContatoService que tem todos os métodos já implementados. Vamos criar uma interface para este serviço para tornar a nossa aplicação mais desacoplada (para mais informação sobre interfaces  e suas vantagens leia este post).

Vamos mudar o nome da classe ContatoService.java para ContatoServiceImpl.java e mudar ela de pacote também: vamos criar um novo pacote e movê-la para ele: br.blog.javasimples.agenda.service.impl.

Agora que a classe já está com o novo nome podemos criar a interface com o nome antigo (ContatoService.java) no pacote br.blog.javasimples.agenda.service (apenas por questões de padrão de nomenclatura). Sendo assim temos a seguinte estrutura:

A interface ContatoService apenas vai definir os métodos que um serviço para contatos deve ter:

/**
 * Interface que define os métodos de um serviço para {@link Contato}.
 *
 * @author Felipe Saab
 */
public interface ContatoService {
 
	/**
	 * Salva um contato.
	 *
	 * @param contato - {@link Contato} a ser salvo
	 */
	void salvar(Contato contato);
 
	/**
	 * Recupera todos os contatos.
	 *
	 * @return Todos os contatos
	 */
	List<contato> getAgenda();
}

E a classe ContatoServiceImpl.java agora deve implementar a interface:

/**
 * Serviço para {@link Contato}.
 *
 * @author Felipe Saab
 */
public class ContatoServiceImpl implements ContatoService {
 
	/**
	 * {@link List Lista} que guarda todos os contatos.
	 */
	private static List<contato> agenda = new ArrayList<contato>();
 
	/**
	 * {@inheritDoc}
	 */
	public void salvar(Contato contato) {
		ContatoServiceImpl.agenda.add(contato);
		System.out.println("Contato adicionado: " + contato);
	}
 
	/**
	 * {@inheritDoc}
	 */
	public List<contato> getAgenda() {
		return ContatoServiceImpl.agenda;
	}
}

Legal, agora que o serviço já virou uma interface e tem sua implementação vamos adicionar as bibliotecas do Spring no nosso projeto.

As bibliotecas que precisamos estão em: {pasta de download do spring}/dist e {pasta de donwload do spring blazeds integration}/dist.

Fiz um pacote com algumas bibliotecas que o Spring utiliza e irão gerar erro caso não estejam no projeto. Adicione essas bibliotecas no classpath também.

Para adicionar as bibliotecas basta colar (CTRL + V) elas na pasta WebContent/WEB-INF/lib do projeto ContatosJ:

Vamos agora começar a mecher em algumas configurações:

WebContent/WEB-INF/web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
	version="2.4">
	<servlet>
		<servlet-name>spring</servlet-name>
		<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
		<init-param>
			<param-name>contextConfigLocation</param-name>
			<param-value>/WEB-INF/applicationContext.xml</param-value>
		</init-param>
		<load-on-startup>1</load-on-startup>
	</servlet>
	<servlet-mapping>
		<servlet-name>spring</servlet-name>
		<url-pattern>/messagebroker/*</url-pattern>
	</servlet-mapping>
</web-app>

Antes nós tinhamos o MessageBrokerServlet definido no nosso arquivo, porém com o projeto de integração entre BlazeDS e Spring nós não precisamos mais ter isso tão explícito, o próprio projeto (Spring BlazeDS Integration) se responsabiliza por criar o MessageBroker e fazer todas as configurações internamente.

Porém o pessoal que criou o projeto utilizou o Spring Web MVC internamente (aceitável né… hehehe), sendo assim, tudo o que precisamos fazer é criar um DispatcherServlet (controlador responsável por todas as requisições que chegam para o Spring Web MVC) e mapear todas as requisições que chegarem para o MessageBroker (/messageBroker/*) para ele, ou seja, toda vez que o FLEX enviar uma requisição para a nossa aplicação (a URL vai ser +/- assim: http://localhost:8080/AgendaJ/messageBroker/my-amf/…) ela vai ser encaminhada para o DispatcherServlet e ele por sua vez vai encaminhar para a classe que deve receber e tratar a requisição.

Vamos criar o arquivo de configuração do Spring em WebContent/WEB-INF/applicationContext.xml (pois informamos este caminho no DispatcherServlet definido no web.xml).

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:p="http://www.springframework.org/schema/p"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:flex="http://www.springframework.org/schema/flex"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                           http://www.springframework.org/schema/context
                           http://www.springframework.org/schema/context/spring-context.xsd
                           http://www.springframework.org/schema/flex
                           http://www.springframework.org/schema/flex/spring-flex-1.0.xsd">
 
	<!-- Cria o MessageBroker com as configurações padrão -->
	<flex:message-broker />
 
	<!-- Habilita a injeção de dependência através de anotações -->
	<context:annotation-config />
 
	<!-- Faz com que os Services sejam beans gerenciados pelo container do Spring -->
	<context:component-scan base-package="br.blog.javasimples.agenda.service.impl" />
 
</beans>

Neste pequeno arquivo de configuração nós estamos definindo tudo que precisamos para fazer o Spring conversar com FLEX como se fosse por mágica! hehehe

Com a tag <flex:message-broker /> nós estamos pedindo para o Spring BlazeDS Integration criar o MessageBroker (a classe que vai receber as requisições através do DispatcherServlet que configuramos no web.xml).

A tag <context:annotation-config /> habilita a injeção de dependência através de anotações. Para que o Spring BlazeDS Integration consiga fazer com que a comunicação aconteça sem que nós fiquemos configurando muita coisa os Serviços que vão receber as chamadas remotas devem ser gerenciados pelo container do Spring. Para isso nós poderíamos declarar os beans de serviço no applicationContext.xml através da tag <bean id=”contatoService” class=”br.blog.javasimples.service.impl.ContatoServiceImpl” /> porém para cada novo serviço deveríamos fazer o mesmo. Para evitar isso utilizaremos a anotação @Service nas classes para fazer com que o Spring possa gerenciá-las. É equivalente à utilização da tag <bean>. Se você ainda não entendeu continue lendo que já já vai ficar claro.

E a tag <context:component-scan /> fala para o container do Spring procurar no pacote br.blog.javasimples.agenda.service.impl por classes que estejam anotadas com @Service e com outras anotações que ele conhece para gerenciá-las, ou seja, para poder fazer injeção de dependência e para utilizá-las para comunicar com o FLEX.

Para terminarmos a parte de configuração do Spring vamos voltar e mecher na implementação do serviço de Contato adicionando algumas anotações nele:

/**
 * Serviço para {@link Contato}.
 *
 * @author Felipe Saab
 */
@Service
@RemotingDestination(value="contatoService")
public class ContatoServiceImpl implements ContatoService {
 
	/**
	 * {@link List Lista} que guarda todos os contatos.
	 */
	private static List<contato> agenda = new ArrayList<contato>();
 
	/**
	 * {@inheritDoc}
	 */
	public void salvar(Contato contato) {
		ContatoServiceImpl.agenda.add(contato);
		System.out.println("Contato adicionado: " + contato);
	}
 
	/**
	 * {@inheritDoc}
	 */
	public List<contato> getAgenda() {
		return ContatoServiceImpl.agenda;
	}
}

A anotação @Service diz que a classe ContatoServiceImpl vai ser gerenciada pelo Spring, ou seja, ela vai estar presente no container do Spring, consequentemente ela vai conseguir ser acessada por injeção de dependência, e pelo Spring BlazeDS Integration (e qualquer outro lugar que precise dessa classe através do Spring).

E a anotação @RemotingDestination informa qual o id devemos utilizar no RemoteObject do FLEX para chamar os métodos desta classe. Simples assim!!!

Lembra que criamos uma tag <destination> no arquivo WebContent/WEB-INF/flex/remoting-config.xml informando o id e a classe? Agora não precisa mais, só essa anotação já resolve todos os problemas, faz com que o Spring BlazeDS Integration faça tudo sozinho por trás.

Com o Spring BrazeDS Integration tomando conta de criar e gerenciar todas as configurações que vamos precisar para a comunicação Java <-> FLEX podemos “fazer um limpa” nos arquivos de configuração do BlazeDS que nós não vamos utilizar ou que o Spring irá criar sozinho. Podemos apagar os arquivos WebContent/WEB-INF/flex/remoting-config.xml, WebContent/WEB-INF/flex/messaging-config.xml e WebContent/WEB-INF/flex/proxy-config.xml:

Agora vamos ajeitar o arquivo WebContent/WEB-INF/flex/services-config.xml para não referenciar mais os arquivos excluídos:

<?xml version="1.0" encoding="UTF-8"?>
<services-config>
	<services>
		<default-channels>
			<channel ref="my-amf" />
		</default-channels>
	</services>
 
	<security>
		<login-command class="flex.messaging.security.TomcatLoginCommand"
			server="Tomcat" />
	</security>
 
	<channels>
		<channel-definition id="my-amf"
			class="mx.messaging.channels.AMFChannel">
			<endpoint
				url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf"
				class="flex.messaging.endpoints.AMFEndpoint" />
		</channel-definition>
	</channels>
 
	<logging>
		<target class="flex.messaging.log.ConsoleTarget" level="Error">
			<properties>
				<prefix>[BlazeDS] </prefix>
				<includeDate>true</includeDate>
				<includeTime>true</includeTime>
				<includeLevel>true</includeLevel>
				<includeCategory>true</includeCategory>
			</properties>
			<filters>
				<pattern>Endpoint.*</pattern>
				<pattern>Service.*</pattern>
				<pattern>Configuration</pattern>
			</filters>
		</target>
	</logging>
 
	<system>
		<redeploy>
			<enabled>true</enabled>
			<watch-interval>20</watch-interval>
			<watch-file>{context.root}/WEB-INF/flex/services-config.xml</watch-file>
			<touch-file>{context.root}/WEB-INF/web.xml</touch-file>
		</redeploy>
	</system>
</services-config>

A grande alteração nesse arquivo foi na tag <services> onde removemos as referências aos arquivos que acabamos de excluir e indicamos para o BlazeDS que o canal padrão para a comunicação é o canal my-amf, ou seja, todas as requisições que chegarem para o message-broker e não tiverem um canal em específico irão ser enviados para o canal my-amf.

OBS: também foram removidas as referências dos arquivos removidos da tag <redeploy>.

E com isso terminamos a configuração do Spring! Que maravilha não?!?! Valeu SpringSource por fazer esse projetinho show de bola!

ADICIONANDO O HIBERNATE

Uma vez que o Spring está configurado vamos para a persistência dos dados com o Hibernate.

Primeiro de tudo vamos criar um banco de dados para a nossa aplicação:

CREATE TABLE contato (
	id INT( 11 ) NOT NULL AUTO_INCREMENT,
	nome VARCHAR( 50 ) NOT NULL ,
	telefone VARCHAR( 14 ) NOT NULL ,
	email VARCHAR( 50 ) NULL ,
	PRIMARY KEY ( id )
) ENGINE = innodb CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Ok, agora precisamos das bibliotecas do Hibernate no classpath da nossa aplicação. Vamos adicionar as bibliotecas:
{pasta download hibernate}/hibernate3.jar
{pasta download hibernate}/lib/jpa
{pasta download hibernate}/lib/required
{pasta download hibernate}/lib/bytecode/javassist

E também precisamos da biblioteca que contém o driver do banco de dados que estamos utilizando (no meu caso a do MySQL).

Agora já podemos realizar o mapeamento objeto relacional da nossa classe Contato.java para a tabela Contato do banco de dados (eu gosto de mapear utilizando anotações, mas não tem problema nenhum utilizar xml):

/**
 * Classe que representa um Contato da agenda.
 *
 * @author Felipe Saab
 */
@Entity
@Table(name = "CONTATO")
public class Contato implements Serializable {
 
	private static final long serialVersionUID = -1549466344815889020L;
 
	@Id
	@GeneratedValue(strategy=GenerationType.AUTO)
	@Column(name="ID", length=11, nullable=false)
	private Long id;
 
	@Column(name="NOME", length=50, nullable=false)
	private String nome;
 
	@Column(name="TELEFONE", length=14, nullable=false)
	private String telefone;
 
	@Column(name="EMAIL", length=50)
	private String email;
 
	public Long getId() {
		return id;
	}
 
	public void setId(Long id) {
		this.id = id;
	}
 
	public String getNome() {
		return nome;
	}
 
	public void setNome(String nome) {
		this.nome = nome;
	}
 
	public String getTelefone() {
		return telefone;
	}
 
	public void setTelefone(String telefone) {
		this.telefone = telefone;
	}
 
	public String getEmail() {
		return email;
	}
 
	public void setEmail(String email) {
		this.email = email;
	}
 
	@Override
	public String toString() {
		StringBuilder sb = new StringBuilder();
		sb.append("[");
		sb.append(this.getNome() + ",");
		sb.append(this.getTelefone() + ",");
		sb.append(this.getEmail());
		sb.append("]");
		return sb.toString();
	}
}

Foi adicionado o atributo id para representar a chave primária do contato.

Como também existe uma classe Contato no FLEX precisamos atualizá-la:

package br.blog.javasimples.agenda.model
{
	[Bindable]
	[RemoteClass(alias="br.blog.javasimples.agenda.model.Contato")]
	public class Contato
	{
		public var id:Number;
		public var nome:String;
		public var telefone:String;
		public var email:String;
 
		public function Contato()
		{
		}
	}
}

Vamos utilizar agora um padrão de projeto (design pattern) chamado DAO (Data Access Object): tal padrão visa centralizar o acesso aos dados em um único objeto, ou seja, sempre que precisarmos gravar/recuperar algo do banco de dados vamos utilizar os métodos desse objeto.

Do mesmo jeito que fizemos a interface ContatoService é interessante fazer a ContatoDao. Seguindo o padrão de nomenclarura dos pacotes vamos criá-la no pacote br.blog.javasimples.agenda.dao:

/**
 * Interface que define os métodos de um DAO para {@link Contato}.
 *
 * @author Felipe Saab
 */
public interface ContatoDao {
	/**
	 * Salva um contato.
	 *
	 * @param contato - {@link Contato} a ser salvo
	 */
	void salvar(Contato contato);
 
	/**
	 * Recupera todos os contatos.
	 *
	 * @return Todos os contatos
	 */
	List<contato> getAgenda();
}

Foram definidos os métodos que já estamos utilizando em ContatoService para acessar os dados para depois que o DAO estiver pronto nós apenas delegarmos a chamada do Service para DAO.

Vamos para a implementação então – sempre seguindo o padrão de nomenclatura dos pacotes: br.blog.javasimples.agenda.dao.impl.

/**
 * DAO para {@link Contato}.
 *
 * @author Felipe Saab
 */
@Repository
public class ContatoDaoImpl extends HibernateDaoSupport implements ContatoDao {
 
	@Autowired
	public void init(SessionFactory sessionFactory) {
		super.setSessionFactory(sessionFactory);
	}
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public void salvar(Contato contato) {
		this.getHibernateTemplate().save(contato);
	}
 
	/**
	 * {@inheritDoc}
	 */
	@Override
	public List<contato> getAgenda() {
		return this.getHibernateTemplate().loadAll(Contato.class);
	}
 
}

A anotação @Repository funciona como a anotação @Service, ou seja, o container do Spring vai conseguir gerenciá-la dinamicamente por causa dessa anotação. Essa anotação também é utilizada para alguns tratamentos específicos para a camada de persistência de dados, mas não vem ao caso agora. heheh

O método init(SessionFactory) que é executado internamente após a classe ser instanciada  serve para configurar a classe pai (HibernateDaoSupport) setando a SessionFactory nele. Esse método possui a anotação @Autowired pois antes dele ser executado o Spring vai injetar o atributo sessionFactory para nós (a classe estando anotada com @Repository demonstra que ela pode estar no container e o Spring vai conseguir injetar as dependências).

Porém essa nova classe precisa de mais algumas configurações no arquivo de configuração do Spring (applicationContext.xml) para poder funcionar:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:p="http://www.springframework.org/schema/p"
	xmlns:context="http://www.springframework.org/schema/context"
	xmlns:flex="http://www.springframework.org/schema/flex"
	xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                           http://www.springframework.org/schema/context
                           http://www.springframework.org/schema/context/spring-context.xsd
                           http://www.springframework.org/schema/flex
                           http://www.springframework.org/schema/flex/spring-flex-1.0.xsd">
 
	<!-- Cria o MessageBroker com as configurações padrão -->
	<flex:message-broker />
 
	<!-- Habilita a injeção de dependência através de anotações -->
	<context:annotation-config />
 
	<!-- Faz com que os Services sejam beans gerenciados pelo container do Spring -->
	<context:component-scan base-package="br.blog.javasimples.agenda.service.impl" />
 
	<!-- Faz com que os DAOs sejam beans gerenciados pelo container do Spring -->
	<context:component-scan base-package="br.blog.javasimples.agenda.dao.impl" />
 
	<!-- DataSource -->
	<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
		<property name="driverClassName">
			<value>com.mysql.jdbc.Driver</value>
		</property>
 
		<property name="url">
			<value>jdbc:mysql://localhost:3306/javasimples_agenda</value>
		</property>
 
		<property name="username">
			<value>usuario</value>
		</property>
 
		<property name="password">
			<value>senha</value>
		</property>
	</bean>
 
	<!-- Hibernate SessionFactory -->
	<bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
 
		<property name="dataSource">
			<ref local="dataSource" />
		</property>
 
		<!-- Carrega todos os Beans -->
		<property name="packagesToScan">
			<list>
				<value>br.blog.javasimples.agenda.model</value>
			</list>
		</property>
 
		<!-- Propriedades do Hibernate -->
		<property name="hibernateProperties">
			<props>
				<prop key="hibernate.dialect">org.hibernate.dialect.MySQL5InnoDBDialect</prop>
				<prop key="hibernate.show_sql">true</prop>
				<prop key="hibernate.format_sql">true</prop>
			</props>
		</property>
	</bean>
 
</beans>

Adicionamos uma nova tag <context:component-scan> informando que o pacote onde vão estar os DAOs também deve ser gerenciado pelo Spring, definimos um DataSource (para saber mais leia este post) e definimos a SessionFactory (para saber mais leia este post) que vai ser injetada no método init(SessionFactory) da classe ContatoDaoImpl.

Uma vez que o DAO está criado e configurado corretamente precisamos mudar o ContatoServiceImpl para utilizá-lo ao invés da lista estática que utilizava antes:

/**
 * Serviço para {@link Contato}.
 *
 * @author Felipe Saab
 */
@Service
@RemotingDestination(value="contatoService")
public class ContatoServiceImpl implements ContatoService {
 
	/**
	 * DAO
	 */
	@Autowired
	private ContatoDao contatoDao;
 
	/**
	 * {@inheritDoc}
	 */
	public void salvar(Contato contato) {
		this.contatoDao.salvar(contato);
		System.out.println("Contato adicionado: " + contato);
	}
 
	/**
	 * {@inheritDoc}
	 */
	public List<contato> getAgenda() {
		return this.contatoDao.getAgenda();
	}
}

Mais uma vez aproveitamos da facilidade da injeção de dependência através de anotações para não nos preocuparmos em instanciar/recuperar o objeto contatoDao, o Spring se encarrega disso para nós.

Prontinho, com isso nós acabamos de incrementar a nossa pequena agenda com Spring e Hibernate!

CONCLUSÃO

Se testarmos a aplicação com essas alterações veremos que ela continua funcionando exatamente da mesma maneira que estava funcionando antes porém agora com o Spring tomando conta da comunicação entre o Java e o FLEX e o Hibernate persistindo os contatos no banco, quando formos adicionar novas funcionalidades temos que pensar apenas na funcionalidade, não precisamos ficar nos preocupando com os detalhes mais baixo nível (como a comunicação Java + FLEX). Tenho uma palavra para isso: produtividade! hehehe

Todo esse processo que realizamos é mais conhecido como refatoração: não mudamos nada do ponto de vista do usuário, apenas melhoramos a estrutura interna do aplicativo.

O código fonte pode ser pego aqui (sem as bibliotecas).

[]s e até a próxima,

Saab.

REFERÊNCIAS

[1] An introduction to Spring BlazeDS Integration

[2] Simple Flex Webapp

[3] Página do projeto Spring BlazeDS Integration

[4] Using Spring BlazeDS Integration 1.0

PS: Gostou? Não gostou? Ajudou? Não ajudou? Quebrou um galho? Perdeu 10 minutos da tua vida lendo? Comente! Divulgue! Fale mal! Compartilhe sua opinião com toda a comunidade!

Hoje iremos abordar uma integração (que eu particularmente acho) fantástica: Java e FLEX (cuja versão mais atual se chama Flash Builder 4).

A primeira grande (super, ultra, …) vantagem que me vem na cabeça quando falo deste assunto é a facilidade para criar belas interfaces. Eu sou uma negação quando o assunto é criar interfaces, design me dá arrepios…

Outro ponto que é um grande vantagem é que toda a interface roda em cima do Flash, ou seja, basta ter o flash instalado no navegador e é certeza que o programa vai abrir exatamente do jeito que você o projetou! Não dá pau de navegador pra navegador!!!! Quem meche com CSS sabe do que eu estou falando, tua página está perfeita no Firefox e quando abre ela no IE dá até medo. Hahahaha quem nunca passou por isso que atire a primeira pedra.

Enfim, veremos como é possível ter uma interface fácil de desenvolver e ao mesmo tempo amigável para o usuário final com um backend poderosíssimo rodando o nosso bom e (não tão) velho Java e todos os frameworks que estamos acostumados a usar, como Spring e Hibernate.

Esta série será dividida (a princípio) em 2 partes:

• Parte 1 – Comunicação básica entre Java e FLEX
• Parte 2 – Integrando Spring e Hibernate na nossa aplicação

Antes de começarmos propriamente dito com o tutorial deixe me falar como funciona essa integração: como o FLEX roda na máquina virtual do Flash que fica no browser (diferente do AIR que é desktop) a nossa aplicação Java também vai rodar em um servidor de aplicativos web (neste caso o Tomcat) para eles poderem se comunicar.

Ambos (FLEX e Java) rodando na web fazem com que o canal de comunicação fique na nossa cara: a própria WEB! Sendo assim, toda vez que o FLEX precisa se comunicar com o Java (quando o usuário manda salvar um objeto por exemplo) o FLEX envia uma mensagem (utilizando o protocolo AMF) para o Java através da WEB.

No servidor Java vai haver um servlet responsável por receber essas mensagens, decodificá-las, transformar os dados em objetos Java e encaminhar para a classe e método que tais objetos devem ser encaminhados e retornar o resultado para o FLEX.

Dita a teoria vamos a prática! hehehe

Vamos precisar ter algumas coisas instaladas:

Eclipse IDE
Flash Builder 4 Eclipse Plugin (Trial por 60 dias)
BlazeDS 4 (Site da Adobe) ou local

Caso você já tenha o Eclipse instalado em sua máquina basta informar o caminho para ele durante a instalação que ele já instalará todos os plugins necessários. Caso não tenha o Eclipse basta baixar uma versão do Flash Builder que já vem com uma versão da IDE (porém não é a mais recente).

Depois que tudo estiver instalado vamos começar importando a estrutura base do projeto Java que vem junto com o arquivo do BlazeDS. No Eclipse selecione o menu Arquivo > Importar e selecione Arquivo WAR na categoria Web.

Na próxima tela informe o caminho para o arquivo blazeds.war (que veio no arquivo do BlazeDS que você baixou) e informe o nome que o novo projeto vai ter. Iremos fazer uma simples (e bonita! hehe) agenda de contatos onde guardaremos os telefones e emails dos nossos amigos, então irei chamar o projeto de AgendaJ.

*OBS: Para o desenvolvimento Java + FLEX são criados 2 projetos: uma projeto Java e um projeto FLEX. Eu tenho o costume (e diria que é uma boa prática) de dar o mesmo nome aos dois projetos adicionando como sufixo J ou F caso o projeto seja Java ou FLEX, respectivamente.

Ok. Agora podemos dar uma espiada para ver como funciona toda a configuração da nossa aplicação Java. Vamos começar olhando para o deployment descriptor WebContent/WEB-INF/web.xml*:

*Apaguei os comentários que vieram junto com o arquivo pois não vamos utilizá-los.

<web-app>
	<display-name>BlazeDS</display-name>
	<description>BlazeDS Application</description>
 
	<!-- Http Flex Session attribute and binding listener support -->
	<listener>
		<listener-class>flex.messaging.HttpFlexSession</listener-class>
	</listener>
 
	<!-- MessageBroker Servlet -->
	<servlet>
		<servlet-name>MessageBrokerServlet</servlet-name>
		<display-name>MessageBrokerServlet</display-name>
		<servlet-class>flex.messaging.MessageBrokerServlet</servlet-class>
		<init-param>
			<param-name>services.configuration.file</param-name>
			<param-value>/WEB-INF/flex/services-config.xml</param-value>
		</init-param>
		<load-on-startup>1</load-on-startup>
	</servlet>
 
	<servlet-mapping>
		<servlet-name>MessageBrokerServlet</servlet-name>
		<url-pattern>/messagebroker/*</url-pattern>
	</servlet-mapping>
 
	<welcome-file-list>
		<welcome-file>index.html</welcome-file>
		<welcome-file>index.htm</welcome-file>
	</welcome-file-list>
</web-app>

Foi definido um servlet chamado MessageBrokerServlet da classe flex.messaging.MessageBrokerServlet que recebe o parâmetro services.configuration.file indicando qual é o arquivo que contém as configurações dos serviços do FLEX. Conseguimos ver também que o MessageBrokerServlet recebe todas as requisições que chegam para a URL “…/messagebroker/*”, ou seja, sempre que o FLEX envia uma requisição para o Java já sabemos que é seguindo este padrão de URL (caso ainda não esteja claro já já vai ficar ).

Olhando o arquivo de configuração dos serviços (WebContent/WEB-INF/flex/services-config.xml)* podemos observar que:

*Retirei alguns comentários e fiz alguns pequenos ajustes nesse arquivo.

• ele inclui três outros arquivos de configuração através da tag <service-include> dentro da tag <service>;
• diz qual classe vai ser responsável pela segurança (autenticação e autorização) em um servidor de aplicativos J2EE;
• define quais canais estarão disponíveis para a comunicação através da tag <channels>. Cada canal definido dentro desta tag indica o mapeamento de um padrão de URL para uma classe em específico, por exemplo, a classe flex.messaging.endpoints.AMFEndpoint irá receber todas as requisições que forem para a URL “…/messagebroker/amf”;
• configura o Logging das comunicações;
• configura o redeploy automático de alguns arquivos que ele fica “observando” em intervalos de tempo definidos.

<services-config>
    <services>
        <service-include file-path="remoting-config.xml" />
        <service-include file-path="proxy-config.xml" />
        <service-include file-path="messaging-config.xml" />
    </services>
 
    <security>
        <login-command class="flex.messaging.security.TomcatLoginCommand" server="Tomcat"/>
    </security>
 
    <channels>
        <channel-definition id="my-amf" class="mx.messaging.channels.AMFChannel">
            <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf" class="flex.messaging.endpoints.AMFEndpoint"/>
        </channel-definition>
 
        <channel-definition id="my-secure-amf" class="mx.messaging.channels.SecureAMFChannel">
            <endpoint url="https://{server.name}:{server.port}/{context.root}/messagebroker/amfsecure" class="flex.messaging.endpoints.SecureAMFEndpoint"/>
            <properties>
                <add-no-cache-headers>false</add-no-cache-headers>
            </properties>
        </channel-definition>
 
        <channel-definition id="my-polling-amf" class="mx.messaging.channels.AMFChannel">
            <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amfpolling" class="flex.messaging.endpoints.AMFEndpoint"/>
            <properties>
                <polling-enabled>true</polling-enabled>
                <polling-interval-seconds>4</polling-interval-seconds>
            </properties>
        </channel-definition>
    </channels>
 
    <logging>
        <target class="flex.messaging.log.ConsoleTarget" level="Error">
            <properties>
                <prefix>[BlazeDS] </prefix>
                <includeDate>true</includeDate>
                <includeTime>true</includeTime>
                <includeLevel>true</includeLevel>
                <includeCategory>true</includeCategory>
            </properties>
            <filters>
                <pattern>Endpoint.*</pattern>
                <pattern>Service.*</pattern>
                <pattern>Configuration</pattern>
            </filters>
        </target>
    </logging>
 
    <system>
        <redeploy>
            <enabled>true</enabled>
            <watch-interval>20</watch-interval>
            <watch-file>{context.root}/WEB-INF/flex/services-config.xml</watch-file>
            <watch-file>{context.root}/WEB-INF/flex/proxy-config.xml</watch-file>
            <watch-file>{context.root}/WEB-INF/flex/remoting-config.xml</watch-file>
            <watch-file>{context.root}/WEB-INF/flex/messaging-config.xml</watch-file>
            <touch-file>{context.root}/WEB-INF/web.xml</touch-file>
        </redeploy>
    </system>
</services-config>

OBS: perceba que todos os canais tem o padrão de URL parecido (“…/messagebroker/…”). Por isso que o MessageBrokerServlet recebe todas as requisições para a URL “…/messagebroker/*”, ele verifica para qual canal ela vai e encaminha para a classe correta.

Os outros arquivos de configuração não contém nada que precise chamar a atenção agora. Então já dá pra dizer que sabemos como o Java recebe e trata as requisições do FLEX!

Vamos preparar o backend da nossa aplicação então: vamos criar a classe que vai representar um contato da nossa agenda e um serviço para executar as regras de negócio da nossa aplicação:

Contato.java

public class Contato implements Serializable {
 
	private static final long serialVersionUID = -1549466344815889020L;
 
	private String nome;
 
	private String telefone;
 
	private String email;
 
	public String getNome() {
		return nome;
	}
 
	public void setNome(String nome) {
		this.nome = nome;
	}
 
	public String getTelefone() {
		return telefone;
	}
 
	public void setTelefone(String telefone) {
		this.telefone = telefone;
	}
 
	public String getEmail() {
		return email;
	}
 
	public void setEmail(String email) {
		this.email = email;
	}
 
	@Override
	public String toString() {
		StringBuilder sb = new StringBuilder();
		sb.append("[");
		sb.append(this.getNome()+",");
		sb.append(this.getTelefone()+",");
		sb.append(this.getEmail());
		sb.append("]");
		return sb.toString();
	}
}

A classe que representa um contato possui apenas o nome, telefone e email do contato. Suficiente para nossa pequena agenda.

OBS: essa classe implementa a interface java.io.Serializable pois ela vai trafegar na Web (do Java para o FLEX e vice versa). É aconselhavel que todo objeto que for ser transmitido através de um canal (socket, web, etc) implemente esta interface e tenha o serialVersionUID (que o Eclipse gerou pra mim hehe) que indica um número único para identificar aquela classe.

Vamos ver agora o serviço que irá tratar a inserção de novos contatos na nossa agenda:

ContatoService.java

public class ContatoService {
 
	private static List<contato> agenda = new ArrayList<contato>();
 
	public void salvar(Contato contato) {
		ContatoService.agenda.add(contato);
		System.out.println("Contato adicionado: " + contato);
	}
 
	public List<contato> getAgenda() {
		return ContatoService.agenda;
	}
}

Como ainda não vamos utilizar o banco de dados e o Hibernate nesta parte do tutorial vamos simular um “banco de dados” (está entre aspas duplas tá.. hehehe) com uma lista estática.

O método salvar(Contato) simplesmente adiciona um novo contato na agenda e o método getAgenda() retorna a nossa agenda com todos os contatos.

Esses métodos vão ser utilizados para o FLEX pedir para o Java salvar um novo contato na agenda e para ele recuperar a agenda com os contatos atualizados.

Para finalizar o desenvolvimento do nosso backend precisamos apenas expor nossa classe de serviço para que as classes que recebem a requisição do FLEX (pacote flex.messaging.endpoint) consigam localizá-la em tempo de execução.

Para isso adicionaremos uma nova tag <destination> no arquivo WebContent/WEB-INF/flex/remoting-config.xml informando um ID para este novo destino e qual classe é responsável por tratar as requisições destinadas a ele. Desta maneira nós informaremos este mesmo ID no FLEX quando precisarmos chamar algum método desta classe.

<service id="remoting-service" class="flex.messaging.services.RemotingService">
 
	<adapters>
		<adapter-definition id="java-object" class="flex.messaging.services.remoting.adapters.JavaAdapter" default="true" />
	</adapters>
 
	<default-channels>
		<channel ref="my-amf" />
	</default-channels>
 
	<destination id="contatoService">
		<properties>
			<source>br.blog.javasimples.agenda.service.ContatoService</source>
		</properties>
	</destination>
 
</service>

Agora já podemos deixar o Java um pouco de lado e ir pra parte nova: o FLEX!

Vamos criar um novo projeto no Eclipse: Arquivo > Novo > Projeto. Na categoria Flash Builder vamos escolher um Flex Project. Na primeira tela configuramos o nome do projeto (vou colocar AgendaF como já comentei lá em cima), dizemos que ele vai rodar na Web e vai se comunicar com um servidor J2EE utilizando o BlazeDS.

OBS: tenha certeza de que o checkbox “Create combined Java/Flex project using WTP” está DESMARCADO.

Na próxima tela informamos algumas configurações do servidor J2EE (no meu caso o Tomcat):

• Root folder –> O caminho pra raiz da aplicação Java no disco;
• Root URL –> O caminho para a raiz da aplicação Java através do servidor;
• Context Root –> O contexto da aplicação no servidor;
• Output Folder (o Eclipse sugere) –> Caminho para a pasta onde o projeto FLEX será compilado e ficará “guardado”. Fica dentro da raiz da aplicação Java pra ser executada junto com o servidor.

Na próxima tela temos que adicionar uma pasta que será a raíz dos códigos fonte. Na aba Source Path apenas clique em Add Folder… e crie uma nova pasta com o nome src.

Após criado o projeto temos mais um ajuste a fazer: caso o Flash Builder 4 que você tenha baixado veio na língua inglesa e seu sistema operacional esteja em português o Eclipse vai criar uma configuração em português (porque ele “reflete” o locale do SO) e o Flash Builder não vai se dar muito bem com ele não… hehehe

Para corrigir esse parâmetro vamos nas propriedades do projeto (botão direito no projeto > Propriedades) e na categoria Flex Compiler existe o campo de texto Additional compiler arguments onde está escrito “-services …\services-config.xml –locale pt_BR”. Vamos apenas trocar o parâmetro “-locale pt_BR” por “-locale en_US”.

Legal, vamos começar a programar mesmo. Mude a perspectiva do Eclipe para Flash (caso ainda não tenha o feito). Vamos entrar em outro mundo agora, vamos deixar o Java um pouco de lado e programar em ActionScript 3 (aka AS3), linguagem utilizada na plataforma FLEX (e outras da Adobe).

OBS: eu não vou entrar em detalhes da linguagem propriamente dita, uma vez que o nome do blog não é AS3 Simples.. kkkkkkkk Mas não tem diferenças muito grandes não, uma pessoa que está acostumada com Java consegue pegar o AS3 rapidinho.

Vamos começar criando a classe que representa um contato da agenda. Vamos criar um pacote com o mesmo nome do pacote no Java (outra boa prática) e criar uma ActionScript Class com o mesmo nome (Contato.as):

package br.blog.javasimples.agenda.model
{
	[Bindable]
	[RemoteClass(alias="br.blog.javasimples.agenda.model.Contato")]
	public class Contato
	{
		public var nome:String;
		public var telefone:String;
		public var email:String;
 
		public function Contato()
		{
		}
	}
}

A classe que representa o contato do lado do FLEX deve possuir os atributos com os mesmos nomes do nome de atributo extraído dos getters da classe Java. Estranho né… heheheh Vamos ver com um pequeno exemplo:

Na classe Contato.java eu tenho os getters getNome(), getTelefone() e getEmail(). Quando o BlazeDS vai enviar os dados do Java para o FLEX ele vai fazer um algorítmo que siga uma lógica parecida com essa (não olhei no código fonte pra saber se é assim mesmo, porém o resultado final é algo assim):

String getterName = "getEmail";
String attributeName = getterName.replaceFirst("get",""); // attributeName == "Email"
attributeName = attributeName.substring(0,1).toUpperCase() + attributeName.substring(1); // // attributeName == "email"

Ou seja, com os getters getNome(), getTelefone() e getEmail() o BlazeDS vai enviar os valores para a classe Contato.as esperando que existam os atributos nome, telefone e email.

O BlazeDS segue esse mesmo padrão para enviar os dados do FLEX para o Java, ou seja, os setters devem seguir esse mesmo padrão de nomenclatura.

Continuando com a nossa classe, algo novo para quem nunca usou AS3 são as anotações: [Bindable] e [RemoteClass(alias)].

Se essas anotações fossem em Java seriam: @Bindable e @RemoteClass(alias=”…”). Só a primeira vista que confunde um pouco, mas é a mesma coisa.

Segue o significado de tais anotações:

• [Bindable] – é algo como a implementação do design pattern Observer. Todo lugar que estiver referenciando alguma propriedade dessa classe será imediatamente avisado assim que alguma delas sofrer alguma mudança;
• [RemoteClasse(alias)] – indica para o BlazeDS qual a classe correspondente a essa na aplicação Java.

Tão simples quanto fazer um POJO no Java não?! hehehe

Agora vem a parte que me fascina no FLEX: layout!

Vamos abrir o arquivo AgendaF.mxml que o Eclipse gerou para nós. Ao mudar para a aba design nós podemos criar a nossa tela com um simples clicar e arrastar de componentes. Arrastei alguns componentes e mudei os labels e em menos de 10 minutos eu fiz o design da nossa aplicação de exemplo:

O código do arquivo AgendaF.mxml ficou assim:

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
               xmlns:s="library://ns.adobe.com/flex/spark"
               xmlns:mx="library://ns.adobe.com/flex/mx">
 
    <mx:Form width="500">
        <mx:FormItem label="Nome" width="100%" direction="horizontal">
            <s:TextInput id="txtNome" width="220"/>
            <mx:Spacer width="100%" height="10"/>
            <mx:FormItem label="Telefone" direction="horizontal">
                <s:TextInput width="100" id="txtTelefone"/>
            </mx:FormItem>
        </mx:FormItem>
        <mx:FormItem label="Email" width="100%" direction="horizontal">
            <s:TextInput width="220" id="txtEmail"/>
            <mx:Spacer width="100%" height="10"/>
            <s:Button label="Salvar"/>
        </mx:FormItem>
        <mx:HBox width="100%">
            <mx:DataGrid width="100%">
                <mx:columns>
                    <mx:DataGridColumn headerText="Nome"/>
                    <mx:DataGridColumn headerText="Telefone"/>
                    <mx:DataGridColumn headerText="Email"/>
                </mx:columns>
            </mx:DataGrid>
        </mx:HBox>
    </mx:Form>
 
</s:Application>