Um dos mais badalados frameworks de ORM no mundo Java (e popular também no .NET), o Hibernate recentemente ganhou sua versão 4.0 Final, que chega para arrebentar de novidades. O framework surgiu em 2001, por iniciativa de Gavin King, e logo se tornou amplamente utilizado devido a uma grande diversidade de recursos para mapeamento objeto relacional. Com a especificação da JPA (Java Persistence API), solidificou-se como  a implementação mais utilizada. Diversos projetos também passaram a ser desenvolvidos pela equipe do Hibernate a fim de aprimorar os recursos existentes no framework. Muitos deles, em vez de serem anexados ao projeto Core, tornaram-se plugins, tais como Hibernate Search, o Hibernate OGM e o Hibernate Validator. Este último, inclusive, teve fortes influências para a criação de uma nova especificação, a Bean Validation (JSR 303).

A partir da versão 3.5, o Hibernate tornou-se uma implementação certificada para a JPA2 (JSR 317), lançada oficialmente no final de 2009. Várias annotations surgiram e muitos recursos foram aprimorados. Em dezembro de 2011, a versão 4.0 Final veio à tona, trazendo algumas importantes novidades que gostaríamos de destacar:

Redesign da SessionFactory

Possivelmente essa é uma das grandes mudanças no Hibernate 4. Estávamos habituados a obter uma SessionFactory da seguinte forma:

private static final SessionFactory sessionFactory =
    new Configuration().configure().buildSessionFactory();

Entretanto, agora o método buildSessionFactory() está listado como deprecated, bem como as classes de Configuration: org.hibernate.cfg.Configuration e AnnotationConfiguration. A nova forma de se obter uma SessionFactory é através do ServiceRegistry, que explicaremos adiante, lançado para esta versão 4:

ServiceRegistry serviceRegistry = new ServiceRegistryBuilder()
    .configure().buildServiceRegistry();
MetadataSources metadataSources = new MetadataSources(serviceRegistry);
metadataSources.addResource("algum.hbm.xml")
    .addAnnotatedClass(SuaEntidade.class);
Metadata metadata = metadataSources.buildMetadata();
SessionFactory sessionFactory = metadata.buildSessionFactory();

Para que possamos obter uma SessionFactory, precisamos de um ServiceRegistry, seguido de um MetadataSources (eventualmente podemos adicionar recursos, classes anotadas, entre outros, de forma similar ao Configuration); a partir deste obtemos um Metadata e então finalmente conseguimos uma SessionFactory.

Para obter uma EntityManagerFactory nada muda, podemos usufruir da classe javax.persistence.Persistence.

ServiceRegistry

Uma nova forma foi implementada para que o Hibernate gerencie seus serviços. Services são classes que fornecem ao Hibernate diversos tipos de funcionalidades, tais como ClassLoader, conexão com o banco (ConnectionProvider), descoberta de dialetos apropriados, entre outros. Você deve estar se perguntando por que isso é um ponto interessante. O fato chave é que agora todos os serviços possuem uma interface. Caso queira, você pode mudar a forma com que o Hibernate realiza algumas funcionalidades de uma maneira muito simples, apenas fazendo com que suas classes implementem a interface de serviço do Hibernate. É uma forma de desacoplar seu código interno e se tornar mais maleável.

Suporte a Multi-Tenancy

Para que não conhece o termo, aí vai um pequeno resumo – em um modelo multi-tenant, é possível compartilhar os mesmos recursos físicos para clientes/empresas diferentes, mas ao mesmo tempo permite-se que fiquem logicamente isolados. A frase anterior pode parecer abstrata, então imagine diversas aplicações de e-commerce. Muitas delas possuem um core muito similar e diferem apenas em questões de layout e UI. Imagine então que fosse criada uma base de código igual para todas essas lógicas de e-commerce e apenas o design de cada loja diferente fosse mudado; cada uma delas teria seu próprio namespace e um endereço na web; contudo a base de código seria a mesma. Esses websites de lojas de e-commerce seriam cada um, um tenant.

Podemos implementar o Multi-Tenancy de algumas formas: Instâncias de bancos separadas (cada tenant possui sua prórpia instância de banco); Schema separados (os tenants compartilham o mesmo banco físico, entretanto cada um deles possui um schema); e também podemos implementar o Multi-Tenancy através de Particionamento (usamos o mesmo banco físico e o mesmo Schema), onde os tenants são particionados de acordo com algum discriminator value (uma chave que apareceria em toda as tabelas) e uma única tabela guarda os dados de cada um deles. O Hibernate 4 dá suporte a esta última opção de maneira fácil. Para este caso, tomemos como exemplo uma tabela no banco denominada Cliente:

CLIENTE (
  ID BIGINT,
  NOME VARCHAR,
  ...
  TENANT_ID VARCHAR (ou uma chave estrangeira)
)

Note que precisamos do campo TENANT_ID, pois ele define a qual tenant nos referimos. Em um exemplo real, esse ID vai dizer a qual loja pertence determinado produto, por exemplo. Essa abordagem via Particionamento ainda dá suporte a cache de segundo nível.

Mas será que sempre precisaremos nos lembrar de criar um TENANT_ID em nossas tabelas? Como poderíamos ter algo como:

CLIENTE (
  ID BIGINT,
  NOME VARCHAR,
  ...
)

sem termos um TENANT_ID? Poderíamos ter schemas separados e criarmos uma SessionFactory para cada tenant. Entretanto, isso seria inviável se tivéssemos muitos tenants, pois muitas SessionFactories podem ser extremamente custosas para a memória. Uma outra ideia seria utilizarmos uma abordagem conhecida como application-supplied connections, onde abrimos uma Session em cada SessionFactory através de uma Connection específica que fornecemos. Podemos dizer ao Hibernate qual Connection utilizar em cada contexto. Lembra-se de quando explicamos o ServiceRegistry? Um dos Services, é o ConnectionProvider. Separando os schemas evitamos a necessidade de um TENANT_ID em cada tabela, mas perdemos a possibilidade de usar o cache de segundo nível de maneira fácil, além de ser mais trabalhoso realizar relatórios e estatísticas com mais de um cliente.

O Hibernate 4 fornece essas alternativas básicas para o cenário multi-tenant, de forma quase transparente.

Usando o Hibernate 4

Quer ver o Hibernate 4 em ação? A maneira mais fácil de colocá-lo em seu projeto é através do Maven:

  <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-core</artifactId>
    <version>4.0.1.Final</version>
  </dependency>
  <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-entitymanager</artifactId>
    <version>4.0.1.Final</version>
  </dependency>
  <dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-annotations</artifactId>
    <version>3.5.6-Final</version>
  </dependency>

Se você utiliza alguma outra ferramenta de build, aqui você encontra todas as dependências necessárias declaradas para Ivy, Gradle, SBT, entre outros.

Você também pode baixar os jars necessários para usá-los diretamente. Caso você use o JBoss AS 7 (conheça mais sobre essa nova versão do servidor), a versão 7.1 (ainda em Beta) já vem com o Hibernate 4 Final. Se você preferir o cloud, pode experimentar o Hibernate 4 no Openshift (aqui há um tutorial no blog da Caelum).

Gostou? Há muito mais nos links abaixo:

Webinar de Hibernate 4 – link
Hibernate 4 – post oficial do in.relation.to
Multi-Tenancy – mais informações (tutorial introdutório)
Multi-Tenancy e Hibernate 4 – Perguntas e Respostas

Também não deixe de visitar os vários posts da Caelum sobre Hibernate, inclusive o conhecido 7 hábitos dos desenvolvedores Hibernate e JPA altamente eficazes. Esperamos você no nosso curso de Hibernate e JPA!

Uma das features interessantes do Hibernate é gerar a Data Definition Language para criação da estrutura de tabelas do banco de dados (schema). Tudo que precisamos fazer é pensar em nosso modelo Orientado a Objeto que o banco é gerado automaticamente a partir das entidades. Aparentemente o processo de pensar na modelagem do banco de dados tornou-se obsoleto: é aí que mora o perigo.

Na orientação a objetos é preferível favorecer especialização através da divisão de responsabilidades. Em vez de criar uma classe gigantesca devemos quebrá-la em pequenas classes.

Quando o assunto é banco de dados a análise é bem diferente. No modelo relacional, a preocupação é normalização dos dados e a modelagem ao mesmo tempo tende a ser pensada de forma a evitar a necessidade de alguns joins que seriam mais caros. Muitas vezes é preferível criar uma tabela com várias colunas com todas as informações pertinentes a criar várias tabelas especializadas. Para ilustrar, considere as entidades:

@Entity
public class Produto {
  @Id
  @GeneratedValue
  private Long id;
  private String nome;
  private BigDecimal preco;
  private Calendar inicioPeriodoPromocional;
  private Calendar fimPeriodoPromocional;
  // outros atributos e metodos
}

@Entity
public class Promocao {
 private Calendar inicio;
 private Calendar fim;
 //outros atributos e metodos
}

Suponha que gostaríamos de saber se uma promoção é aplicável a um produto e por quantos dias podemos aproveitar uma promoção. Colocar esse código dentro de um controller ou managed bean não parece uma boa idéia. Esse trecho rapidamente reaparecerá em outro lugar. Onde então podemos criar métodos para essa análise? Poderíamos começar criando a classe Intervalo:

public class Intervalo {
  private Calendar inicio;
  private Calendar fim;
}

E em vez de Produto e Promocao guardarem referências para duas datas, guardariam para um Intervalo, removendo os respectivos Calendars:

@Entity
public class Produto {
  @Id
  @GeneratedValue
  private Long id;
  private String nome;
  private BigDecimal preco;
  private Intervalo periodoPromocional;
  //...
}

@Entity
public class Promocao {
  private Intervalo vigencia;
  //...
}

A criação da classe Intervalo pode trazer benefícios muito maiores do que a eliminação da repetição de atributos. Adotando a boa prática de unir dados a comportamentos, podemos isolar todo comportamento relacionado a um intervalo de datas nessa nova classe:

public class Intervalo {
  private Calendar inicio;
  private Calendar fim;

  public int getDias() {...}
  public Intervalo interseccaoCom(Intervalo outro) {...}
}

Para saber quantos dias temos para aproveitar a promoção faríamos:

Intervalo janelaDeOportunidade =
  produto.getPeriodoPromocional().interseccaoCom(promocao.getVigencia());

int diasParaAproveitar = janelaDeOportunidade.getDias();

Mas como mapeamos a classe Intervalo? Criar uma tabela e referenciar seus registros através de chaves estrangeiras nas tabelas Produto e Promocao só trará a necessidade de joins. A JPA nos oferece uma alternativa: criar uma classe Embeddable, um dos assuntos básicos abordados no FJ-25. Quando anotamos uma classe com @Embeddable, seus atributos serão colunas na tabela da entidade que tem o atributo anotado com @Embedded.

@Embeddable
public class Intervalo {
  //...
}

@Entity
public class Promocao {
  @Embedded
  private Intervalo vigencia;
  // a tabela Promocao terá uma coluna inicio e outra fim
  // ...
}

A classe Intervalo não precisa de um identificador único: ela é definida pelo seu valor e pode ser encarada como um Value Object. É importante conhecer os diversos recursos do Hibernate que nos dão a possibilidade de não precisar adequar nossas entidades às nossas tabelas, nem de adequar nossas tabelas às nossas entidades. Por exemplo, tabelas secundárias oferecem o serviço inverso: uma entidade mapeada em duas tabelas. O próprio @ManyToMany evita a criação de uma classe a mais apenas para manter referências para as duas classes relacionadas. Há ainda o suporte a chaves compostas, herança, nomenclatura das tabelas, namespaces e colunas, e até mesmo tipos definidos pelo próprio usuário para cada banco de dados diferente.

Uma reclamação frequente dos novos usuários do Hibernate é o excesso de queries realizadas pelo framework, afetando não só a performance mas também a escalabilidade da aplicação. Será realmente culpa do framework? Práticas simples podem ajudar a enfrentar esses gargalos ao usar o Hibernate, mas como detectá-los numa aplicação que já foi mapeada sem muito cuidado? Uma das ferramentas mais úteis para o desenvolvedor na hora de otimizar e corrigir problemas com o Hibernate, além dos logs, são as estatísticas. Através do Hibernate Statistics poderemos dizer quantas vezes cada entidade, coleção (relacionamento) e query está sendo carregada/executada, quantas vezes o cache foi usado, tempo médio de cada query, etc. Em mão desses dados, temos mais pistas de onde colocar cache, configurar batchsize e fazer joins com fetch eager.

Para habilitar o uso das estatísticas do Hibernate temos duas formas. A primeira através do arquivo de configuração do hibernate e a segunda programaticamente. Ao escolher a maneira programática temos a vantagem de poder habilitar e desabilitar a coleta de estatísticas a qualquer momento. Mas não se preocupe, pois podemos usar as duas ao mesmo tempo!

Para habilitar através do arquivo de configuração basta adicionar a seguinte propriedade no hibernate.cfg.xml:

<property name="hibernate.generate_statistics">true</property>

Programaticamente usamos o SessionFactory:

sessionFactory.getStatistics().setStatisticsEnabled(true);

Passada etapa de configuração vamos ver um exemplo de ajuda que o hibernate statistics pode dar. Para o exemplo abaixo temos uma classe utilitária para facilitar a criação de Sessions e das Statistics:

public class HibernateUtil {

	private static SessionFactory factory;

	static {
		factory = new Configuration().configure().buildSessionFactory();
	}

	public static Session openSession() {
		return factory.openSession();
	}

	public static Statistics getStatistics() {
		if (!factory.getStatistics().isStatisticsEnabled()) {
			factory.getStatistics().setStatisticsEnabled(true);
		}
		return factory.getStatistics();
	}
}

O indicado nesses casos seria usar algum container de Injeção de Dependências para fazer este controle, mas esse é um outro assunto.

O caso abaixo é o exemplo Pessoa que possui uma lista de Telefone. Nesse código estamos simulando a criação de 10 pessoas e seus respectivos telefones. Porém se notarmos bem o código, estamos salvando primeiro o telefone e depois a pessoa. Essa ordem acabará gerando (dependendo do dialeto hibernate utilizado no banco) um update para cada par de Pessoa e Telefone que inserirmos, pois o hibernate ao salvar o telefone ainda não tem o id da pessoa para enviar no insert de telefone.

Com o Hibernate Statistics podemos conferir quantos updates foram disparados através do método getEntityUpdateCount e conferir se realmente estamos disparando as operações da maneira correta:

public class TesteQuantidadeUpdatesOrdemErrada {
	public static void main(String[] args) {
		Session session = HibernateUtil.openSession();
		Statistics statistics = HibernateUtil.getStatistics();
		long antes = statistics.getEntityUpdateCount();

		for (int i = 0; i < 10; i++) {
			Transaction transaction = session.beginTransaction();

			Pessoa p = new Pessoa();
			p.setNome("Caelum "+1);
			Telefone t1 = new Telefone();
			t1.setValor("5571-2751");
			t1.setTipo("comercial");
			t1.setPessoa(p);

			session.save(t1);
			session.save(p);
			transaction.commit();
		}
		long depois = statistics.getEntityUpdateCount();
		System.out.println(depois-antes);
	}
}

Ao rodar o código temos a saída “Updates disparados:10″. Graças ao Hibernate Statistics foi fácil de ver esses updates a mais, sem ter de ficar verificando os enormes logs de queries que uma aplicação pode gerar. Para resolver essa pendência basta inverter a ordem dos saves que teremos 0 updates no hibernate statistics.

O código abaixo insere dez pessoas no banco:

public static void main(String[] args) {
		Statistics statistics = HibernateUtil.getStatistics();

		long abertas = statistics.getSessionOpenCount();
		long fechadas = statistics.getSessionCloseCount();
		System.out.println("Sessoes nao fechadas:"+(abertas-fechadas));

		for (int i = 0; i < 10; i++) {
			Session session = HibernateUtil.openSession();
			Transaction transaction = session.beginTransaction();
			try{
				Pessoa p = new Pessoa();
				p.setNome("Caelum "+1);
				session.save(p);
				transaction.commit();
				session.close();
			}catch (Exception e) {
				System.err.println(e);
				transaction.rollback();
			}
		}
		abertas = statistics.getSessionOpenCount();
		fechadas = statistics.getSessionCloseCount();
		System.out.println("Sessoes nao fechadas:"+(abertas-fechadas));
	}
}

Em uma execução normal teríamos todas as sessões fechadas sem problema algum, porém vamos simular um erro a cada 3 saves:

Pessoa p = new Pessoa();
p.setNome("Caelum " + 1);
if (i%3 == 0) {
	throw new RuntimeException();
}
session.save(p);
transaction.commit();
session.close();

Agora vemos através do hibernate statistics que nosso try/catch está falho e que, caso algo saia errado, esquecemos de fechar a sessão no catch. O certo neste caso era fechar a sessão no bloco finally, evitando que por causa de esquecimento alguém não tenha fechado a sessão.

}catch (Exception e) {
	System.err.println(e);
	transaction.rollback();
}finally{
	session.close();
}

Agora o hibernate statistics mostrará que todas as sessões foram fechadas para esse caso. Vale lembrar que ainda devemos verificar se o close terminou com sucesso, eliminando as possibilidades de uma sessão ou transação permanecer aberta (em último caso, deve ser logado com prioridade).

Podemos até coletar informações sobre as transações, adicionando as linhas de código abaixo, mostrando a quantidade de transações totais e as que deram certo:

System.out.println("Quantidade total de Transacoes:" +
    statistics.getTransactionCount());
System.out.println("Quantidade de Transacoes ok:" +
    statistics.getSuccessfulTransactionCount());

É de grande ajuda que os sistemas tenham uma página que possa mostrar algumas dessas informaçãoes a qualquer hora. Inclusive o hibernate tem um método que mostra no log um resumo de todas as estatísticas importantes, para ver esse imprimi-lo basta invocar logSummary da classe Statistics.

O Hibernate Statistics está cheio de métodos uteis, uma pequena lista dos principais:

• getEntity[Delete,Insert,Load,Update]Count():long
  serve para obter informações sobre os CRUD das entidades
• getQueryExecutionMaxTimeQueryString():String
  retorna a consulta mais demorada
• getQueryExecutionMaxTime():long
  retorna o tempo de execução da consulta mais demorada
• getSecondLevelCacheHitCount():long
  retorna quantas vezes o hibernate conseguiu a informação que queria
  através do cache
• getSecondLevelCacheMissCount():long
  retorna quantas vezes o hibernate teve que ir no banco buscar a
  informação que queria pois ela não estava no cache

Existem muitos outros métodos interessantes que podem ser conferidos no javadoc da classe Statistics. Suas informações vai te ajudar a decidir que queries devem ser reescritas, colocadas no second level cache, quais relacionamentos devem ser carregados em modo batch, etc.

Apenas as estatísticas do Hibernate não vão ajudar a resolver todos os problemas da aplicação, porém facilitará muito quando você tiver que achar pequenas falhas, inconsistências, lentidão e excessos na comunicação aplicação-banco. Monitorar muito bem sua aplicação é essencial, para não depender apenas de utilizar profilings e debuggers, que deveriam ser ferramentas apenas nos casos mais graves.

O maior problema com o GenericDAO é que não necessariamente todas as operações fazem sentido para uma determinada classe. Daí o que fazer se, por exemplo, não faz sentido excluir um pagamento?

public class PagamentoDAO
          extends GenericDAO<Pagamento> {

     @Override
     public void excluir(Pagamento pagamento) {
         throw new UnsupportedOperationException();
     }
}

Não parece uma solução muito elegante, mas é um dos únicos jeitos de proibir uma operação declarada na classe mãe, e ainda assim, só funciona em tempo de execução. Esse é um dos principais motivos para muitos não gostarem de usar o GenericDAO e preferirem usar composição ao invés de herança. Mas como fazer para não repetir o código trivial das operações do CRUD?

Um dos jeitos é usar uma outra abstração de persistência de objetos: o Repository. Com o Repository, temos um lugar onde podemos guardar e buscar por objetos, não importando como fazemos isso. O DAO já está muito ligado com armazenamento em banco de dados, e foi criado quando as operações do BD eram muito trabalhosas (em especial no JDBC).

E como juntar o Repository com o GenericDAO? O Repository pode ser definido, por exemplo, como uma interface, e aí podemos fazer o seguinte: se, para um pagamento, faz sentido apenas salvar e listar, mas não excluir, então criamos a interface:

public interface PagamentoRepository {
    void salva(Pagamento pagamento);
    Pagamento busca(Long id);
    List<Pagamento> lista();
}

E usamos o GenericDAO como implementação dessa interface:

class PagamentoDAO
          extends GenericDAO<Pagamento>
          implements PagamentoRepository {
   // implementacao extra
}

E no nosso código de domínio “nunca” referenciaremos o PagamentoDAO, apenas o PagamentoRepository, assim mesmo que a implementação saiba fazer mais coisas, a interface só expõe as operações suportadas.

Se você usa Injeção de Dependências e algum framework que a suporta (como o VRaptor, Spring ou Java EE6), você pode deixar os DAOs apenas como infraestrutura, e usar os Repositories como interfaces públicas da sua aplicação:

public class PagamentoController {
    public PagamentoController(PagamentoRepository repository) {
         this.repository = repository;
    }

    public void salva(Pagamento pagamento) {
         // validações e outras regras
         repository.salva(pagamento);
    }
}

Ainda poderíamos melhorar o nome do nosso repositório para BaseDePagamentos, ContasAPagar ou ainda Pagamentos, evitando usar sufixos nas classes. Usando abstrações e padrões simples conseguimos evitar repetição de código sem perder a semântica e restrições das nossas classes de modelo, além de esconder detalhes de implementação.

A Caelum sempre reconheceu o poder da comunidade e do open source, e ativamente participa de ambas. Disponibilizamos várias apostilas para download, organizamos o GUJ e o InfoQ Brasil e estamos diretamente envolvidos em diversos projetos de código aberto. Há desde novos projetos como VRaptor, Restfulie e Stella, até a participação em projetos existentes como Hibernate, XStream e PicoContainer.

Aliás, hoje, o VRaptor é um dos principais projetos que desenvolvemos, e acaba de ter sua versão 3.1.2 lançada. A nova série 3.x já possui mais de 8000 downloads.

O Restfulie é outro importante projeto que tem revolucionado a forma como se aplica REST hoje mundo a fora. O projeto é liderado por Guilherme Silveira que foi apresentado juntamente com Ian Robinson e Jim Webber da ThoughtWorks no WWW 2010, um evento com palestrantes de peso como o “criador” da web, Tim Berns Lee. Há uma entrevista com o Guilherme (em inglês) para você conhecer mais do assunto.

E, agora, para incentivar ainda mais a comunidade, a Caelum lança sua Iniciativa Open Source, que traz descontos em todos os cursos para alunos que participam de projetos de código aberto. Saiba mais na página da iniciativa e participe também com o seu projeto.

O primeiro desafio de um iniciante em Hibernate, antes mesmo de fazer um tutorial prático, como o disponível na apostila FJ-21 da Caelum, é organizar as dependências necessárias. Até o Hibernate 3.3, a maneira a qual ele era distribuído dava trabalho pra quem precisasse usar a JPA: além do zip contendo o hibernate, era necessário fazer o download de um outro jar contendo a implementação do EntityManager e ainda outro contendo as anotações e interfaces da JPA.

A versão 3.5, como a 3.6, além de trazer uma implementação da JPA2, juntou todos esses pacotes em um só. A documentação está ainda mais completa, assim como a parte explicando o processo de setup do seu primeiro projeto. Apesar disso, como se pode ler na documentação, ela é feita assumindo que você esteja usando o maven. Muitos iniciantes em Java ainda tem dificuldades pra encarar o Maven, ou há ainda quem prefira usar o Ant, Ivy ou gerenciar as dependências manualmente. Quais dependências preciso então para rodar uma aplicação com Hibernate 3.5/3.6?

Para facilitar seu trabalho, deixamos aqui um zip com todas essas dependências do Hibernate 3.5.0, além de um arquivo de configuração para o Log4J, um hibernate.cfg.xml e jars opcionais.

Ou então você pode juntar esses jars seguindo o passo a passo: primeiramente precisa baixar a distribuição 3.5/3.6 a partir da página de downloads do hibernate no sourceforge. Ao descompactá-la, encontramos os seguintes arquivos e diretórios:

O hibernate3.jar é um jar contendo as classes fundamentais do Hibernate. Agora, dentro de lib, temos o diretório required, que são dependências que sempre precisaremos utilizar junto com o Hibernate. Todas essas 6 dependências são necessárias:

Dentro de lib, ainda precisamos do jar hibernate-jpa-2.0-api-1.0.0.Final.jar que está na pasta jpa para poder utilizar as anotações do Java EE. Caso você va usar o MySQL, também precisa fazer o download do driver JDBC para ele.

Ainda não terminou. Precisamos do nosso logging funcionando. Se você tentar executar algum exemplo agora, vai receber o conhecido Exception in thread “main” java.lang.NoClassDefFoundError: org/slf4j/impl/StaticLoggerBinder. O SL4J, usado pelo Hibernate, é uma casca para as outras ferramentas de logging, e precisa então de um jar que indique qual logger será utilizado como backend. Na página de distribuições do SL4J você deve baixar a versão correspondente que está usando, seria a 1.5.8 no caso do Hibernate 3.5.0, e pegar o adaptador slf4j-log4j12-1.5.8.jar. Para o Hibernate 3.6.2, é necessário o slf4j-log4j12-1.6.1.jar. Também precisamos do jar do Log4J 1.2.x.

Principais dependências opcionais

Usar o Hibernate facilita muito o desenvolvimento com banco de dados, porém para uma performance e escalabilidade adequada é necessário ficar atento em alguns pontos fundamentais, e também simples, para que ele não se torne um gargalo na sua aplicação. Dentro do diretório optional, destaco como essenciais o c3p0 para pool de conexão e o ehcache para second level cache. O ehcache necessitará do commons-logging por sua vez.

Para você tirar todo o poder da JPA 2, vai querer também usar a api de meta modelos, e pra isso precisa do gerador de modelos do Hibernate.

Na nova versão do Java EE lançada dezembro de 2009 existem grandes novidades: Servlets 3.0, JAX-RS, CDI, JSF 2.0 e a Bean Validation, definida pela JSR 303. Com a Bean Validation é possível realizarmos validações atráves de metadados (anotações) e as utilizarmos em todas as camadas de nossa aplicação.

Podemos até mesmo criar nossas próprias regras de validações e aplicarmos em outros pontos do nosso sistema. Essas regras podem ser facilmente integradas com JPA e JSF, por exemplo. Vamos considerar uma classe que represente um contato:

public class Contato {

  private String nome;

  private String email;

  // getters e setters

  public void enviaEmail() {
    // codigo envio de email
  }
}

E vamos adicionar nossas regras de validação utilizando a Bean Validation:

public class Contato {

  @NotEmpty
  @Pattern(regexp = ".+@.+\\.[a-z]+")
  private String email;

  @NotEmpty
  private String nome;

  // getters e setters

  public void enviaEmail() {
  // codigo envio de email
  }
}

A anotação @NotEmpty garante que o email não poderá ser vazio assim como o atributo nome. No atributo email também colocamos a anotação @Pattern, onde podemos passar qualquer expressão regular, que o Bean Validation validará o valor passado ao atributo nome com a expressão regular.

Lembrando que o Bean Validation é uma especificação e como toda especificação, para utilizarmos precisamos de uma implementação para a utilizarmos. A implementação usada nos exemplos é a Hibernate Validator, e é a implementação de referência.

Integrando com o JSF

O código abaixo mostra um formulário simples utilizando JSF, que chama um método enviaEmail do ManagedBean quando clicamos no botão “EnviaEmail“:

<h:form id="formulario">
     <h:panelGrid columns="3">
          <h:inputText id="email" value="#{contato.email}"/>
          <h:message for="email" styleClass="error"/>
          <h:commandButton action="#{contato.enviaEmail}"
               value="Enviar Email"/>
     </h:panelGrid>
</h:form>

Precisamos ainda anotar nossa classe Contato com @ManagedBean(name="contato") e @RequestScoped para que a mesma seja um ManageBean e consiga integrar-se com o JSF.
Quando clicarmos no botão “Enviar Email” automaticamente será validado se o atributo email foi preenchido a atende a expressão regular da anotação @Pattern.

Podemos muitas vezes nos deparar com algum caso onde é necessário fazermos uma validação um pouco mais específica, algo que não esteja implementado por padrão no Bean Validation. Validar um CEP seria um bom exemplo. O primeiro passo para fazermos nossa própria validação é criar uma anotação que sugira o nome desta validação.

@Constraint(validatedBy = CepValidator.class)
@Documented
@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Cep {

  String message() default "Cep inválido";
  Class<?>[] groups() default { };
  Class<? extends Payload>[] payload() default { };

}

Reparem que em nenhum momento fizemos de fato a validação se o CEP é válido ou não. Por isso anotamos a anotação CEP que acabamos de criar com @Constraint e setamos o atributo validatedBy com a classe que está nossa validação realmente.
O próximo passo é criarmos a classe CEPValidator que fará a validação. Esta classe tem que obrigatóriamente implementar a interface javax.validation.ConstraintValidator:

public class CepValidator implements
            ConstraintValidator<Cep, String> {

  private Pattern pattern =
          Pattern.compile("[0-9]{5}-[0-9]{3}");

  @Override
  public void initialize(Cep constraintAnnotation) {

  }

  @Override
  public boolean isValid(String value,
           ConstraintValidatorContext context) {
    Matcher m = pattern.matcher(value);
    return m.matches();
  }

}

No método isValid verificamos e retornamos um booleano dizendo se a String passada como argumento está de acordo com a expressão regular que criamos no topo da classe. Podemos agora validar qualquer atributo de algum Java Bean, devendo apenas anotar o atributo com a nossa recém criada @CEP. Por exemplo:

public class Contato {

  @Cep
  private String cep;

  // getters e setters
}

Para rodar esse exemplo precisamos de um servidor de aplicação compatível com o Java EE 6, como o Glassfish 3.0. A premissa do Bean Validation é que muitos outros frameworks acabem por adotar um único mecanismo de validação, sendo possível reaproveitar o código criado aqui. O Caelum Stella, que fornece diversos validadores para sistemas que envolvem o domínio brasileiro, em breve será compatível com essa especificação, possibilitando que você utilize-o em todas as diversas especificações que compões o Java EE.

Além disso precisamos de um Servidor de Aplicação compatível com a versão 6 do Java EE. Por enquanto o único servidor que implementa essa versão é o Glassfish v3.0 que por sinal também é uma implementação de referência.

Depois de mais de 4000 downloads nesses 3 meses de vida, lançamos o VRaptor 3.1 com muitas novidades e bugfixes, com destaque ao suporte aos novos recursos das servlets no Java EE 6, o que permite usar o VRaptor 3 sem nem mesmo um web.xml em containers compatíveis com servlets 3.0, além de novos recursos para AJAX, lógicas genéricas e facilidades no mapeamento de URLs, forwards e redirects.

Aproveitando o lançamento dessa nova versão do framework, estamos disponibilizando a atualização da apostila do curso FJ-28 de VRaptor, Hibernate e AJAX, que já está disponível para download. O material não abrange apenas VRaptor, Hibernate e JSP, mas também entra em detalhes de como fazer a costura de maneira correta, gerenciando suas Sessions, Transactions, etc, através da criação de uma webapplication desde o zero.