Integre o DeltaSpike ao seu projeto JavaEE

Você pode estar órfão das funcionalidades do Seam 3, CDI Source ou Apache CODI.  Pode também estar muito bravo com a especificação JAAS do JavaEE com sua falta de atualização e difícil uso. Além disso, triste com o suporte ao escopo de Conversation do CDI ser ainda tão ruim na integração com JSF e Ajax. Por fim, sua aplicação utiliza um servlet container e você ainda tem aqueles códigos toscos pouco produtivos de abertura e fechamento de transações controlados manualmente.

Para ajudar nesses questionamentos a resposta é DeltaSpike. É uma biblioteca cujo objetivo principal foi unificar as diferentes funcionalidades existentes das mais diversas bibliotecas que auxiliam nas tarefas diárias do desenvolvedor. Além disso, ele pretende ser a biblioteca padrão para extensões ligadas principalmente ao JavaEE. Basicamente é um junção de forças, ao invés de cada um fazer a sua solução, os commiters dos projetos citados anteriormente se uniram.

O projeto possui uma api extensa, passando por testes, validação, ajuda para ter acesso aos contextos HTTP, criação de Repositórios, até mesmo uma integração com o Quartz. Enfim, muitas features interessantes para facilitar o seu trabalho, inclusive se você já estiver em um Application Server, que mesmo com a ótima versão do JavaEE 7, ainda possui alguns gaps, como a parte de segurança. Seria impossível cobrir todas elas, até porque desconheço boa parte, mas tenho certeza que você escreverá nos comentários as features que está usando para debatermos.

A configuração inicial do DeltaSpike é bem simples, basicamente é adicionar dependências no pom.xml. Como o projeto é divido por módulos, o único realmente necessário é o core, o resto é adicionado de acordo com a necessidade do desenvolvedor. Vamos para o código então.

Supondo que você esteja em um Servlet Container, o primeiro passo a ser feito é prover um EntityManager para o DeltaSpike poder trabalhar. Com CDI, basta usar uma fábrica:

public class JPAUtil
{

	private static EntityManagerFactory emf = Persistence.createEntityManagerFactory("cacs");

	public static void closeEntityManagerFactory()
	{
		JPAUtil.emf.close();
	}

	@Produces
	@RequestScoped
	public EntityManager createEntityManager()
	{
		return JPAUtil.emf.createEntityManager();
	}

	public void closeEntityManager(@Disposes final EntityManager entityManager)
	{
		if (entityManager.isOpen())
		{
			entityManager.close();
		}
	}
}

Pronto, vamos pesquisar alguns dados de usuário. Para isso, precisamos criar um repositório e suas queries. O modulo data tem um suporte muito parecido com o framework Esfinge, basta montar o nome do método com um formato pré-definido e a query será gerada dinamicamente

@Repository(forEntity = Usuario.class)
public interface TodosUsuarios extends EntityRepository<Usuario, Integer>
{
  List<Usuario> findByEmailLikeOrderById(String email);

  Usuario findByEmailEqualAndSenhaEqual(String email, String senha);

  Long count();
}

Agora basta injetar a referência para TodosUsuarios conforme exemplo:

@Path("/usuarios")
public class ServicosUsuario {

  @Inject
  private TodosUsuarios todosUsuarios;

  @GET
  @Path("/{email}")
  @Produces(MediaType.APPLICATION_JSON)
  public Response listarUsuariosPorEmail(@PathParam("email") String email)
  {
    return Response.ok(todosUsuarios.findByEmailLikeOrderById("%"+email+"%")).build();
  }

  @GET
  @Path("/total")
  public Response total()
  {
    return Response.ok(todosUsuarios.count()).build();
  }
}

Ainda relacionado ao Banco de Dados, nos códigos que precisamos de transação, a solução era chamar diretamente o entityManager.getTransaction().begin() ou criar na mão interceptadores CDI para criar transações demarcadas. O módulo JPA já oferece esse serviço, basta adicionar o interceptador no beans.xml e anotar os métodos que necessitam de transação com @Transactional (importe do pacote deltaSpike). O módulo também oferece um suporte interessante para Extended Persistence Context.

No aspecto de segurança, o JavaEE deixa muito a desejar, então o módulo do projeto oferece serviços interessantes, por exemplo, determinados métodos na sua aplicação só podem ser acessos caso o usuário tenha determinado perfil. Criamos uma anotação para identificar essa regra:

@Retention(RetentionPolicy.RUNTIME)
@Target(value = { ElementType.TYPE, ElementType.METHOD })
@Documented
@SecurityBindingType
public @interface Critico {
}

Criamos um classe para fazer a regra de negocio, perceba que o UsuarioLogado é um classe provida pelo CDI:

public class AutorizadorCritico {
  @Secures
  @Critico
  public boolean conferirPerfil(InvocationContext invocationContext, BeanManager manager,
    UsuarioLogado usuarioLogado) throws Exception {
    return usuarioLogado.isAdministrador()? true : false;
  }

  @Produces
  @Critico
  @Named("fornecedores")
  public List<Fornecedor> listaFornecedores() {
     return todosFornecedores.listar();
  }
}

Por fim, o módulo de JSF oferece vários recursos, talvez o mais interessante seja uma nova gama de escopos. Um cenário comum em aplicações que usam esta tecnologia é o cadastro baseado em wizards, no qual há navegação por mais de uma tela. Apesar das novas novidades da versão 2.0 do framework, fazer isso em JSF não costuma ser muito trivial. Você pode usar o @ViewScoped, o @ConversationScoped do CDI ou até mesmo o Flash scope, mas a solução que eu achei mais conveniente é o @ViewAcessScoped do DeltaSpike.

Temos um cadastro no qual a primeira página é a listagem dos elementos e quando um elemento é selecionado, ocorre uma navegação para a página de edição. As duas páginas possuem referência para o mesmo BackingBean. Quando selecionamos um item na página de listagem, queremos que este item ainda fique ativo na página de edição. Se usássemos o @ViewScope do JSF, quando ocorre a navegação, o BackingBean seria criado novamente, perdendo a referência para o item selecionado.

O @ViewAccessScoped resolve esse problema. A definição é muito boa:

However, sometimes you need beans with a lifetime which is as long as needed and as short as possible – which are terminated automatically (as soon as possible)

.
O escopo mantém um objeto ativo enquanto estiver referência para ele. Exemplificando:

Primeira página de listagem: #{usuarioBean.usuarios} e #{usuarioBean.editar(usuario)}

@ViewAcessScoped
@ManagedBean
class UsuarioBean {

}

Já na segunda página de edição temos a referência #{usuarioBean.usuarioSelecionado.nome}. Aqui o objeto UsuarioBean ainda está ativo e só irá morrer quando o usuário navegar para uma próxima  página em que não haja referência para este ManagedBean.

The simple rule is, as long as the bean is referenced by a page – the bean will be available for the next page (if it’s used again the bean will be forwarded again)

.

Por incrível que pareça ainda recebo muitos questionamentos em sala sobre o Seam, e nas minhas aulas toda vez que eu falo sobre o DeltaSpike os alunos costumam gostar, espero que agora ainda mais. Você pode se inteirar mais sobre essas tecnologias com nossos cursos, onde sempre debatemos as novidades e outras opções. E você, gostou de alguma feature? Já utiliza? Não esqueça de deixar seu comentário.

8 Comentários

  1. Rafael Ponte 18/11/2014 at 11:57 #

    Oi Rapha,

    Quem trabalhou muito com JSF 1.2 sempre teve que recorrer a recursos e features de outros frameworks, como Seam, MyFaces Orchestra [esse possui excelentes escopos, semelhante ao que você @ViewAcessScoped], FlowScope do Trinidad, Tomahawk, RestFaces e outros. Apesar do JSF 2 e 2.2 terem trazidos diversas melhorias, ainda dependemos de soluções auxiliares em determinados tipos de cenários.

    Enfim, excelente post! Espero que você continue nesse ritmo de postagem, pois você sempre tem muito a compartilhar com a comunidade!

    Um abraço!

  2. Douglas Arantes 18/11/2014 at 14:20 #

    Parabéns pelo post, o DeltaSpike é realmente muito bacana, esse módulo para trabalhar com Dados quebra um galho.

  3. Felipe Braga 18/11/2014 at 19:17 #

    Realmente bem bacana esse escopo @ViewAccessScope. E definitivamente quanto eu sofri com esse @ConversationScope no JSF2 e logo no início do CDI.

    Flashscope é um lamento, até hoje não consegui aplicar de forma adequada e sempre ocorre problema com o cookies do navegador ao armazenar.

  4. Wesley 18/11/2014 at 20:52 #

    Ótimo Raphael!!!
    Parabéns, esse post era o que eu estava esperando, consegui sanar várias dúvidas.

  5. Francisco Sokol 28/11/2014 at 08:19 #

    Uma coisa legal é que agora que o VRaptor é integrado com o CDI, podemos usar esses módulos do DeltaSpike mesmo fora do JSF ou do JAX-RS!

    Parabéns pelo post!

  6. Valdo 21/12/2014 at 13:55 #

    Estou com uma dúvida sobre scopo ViewAcessScoped. Criei dois beans com o escopo ViewAcessScoped e uma página para cada bean. Com a primeira página aberta, abri a segunda digitando o url no browser, porém, o bean da primeira página não é destruído. Somente depois de um determinado tempo que o bean é destruído. O comportamento é esse mesmo?
    Parabéns pelo post!

  7. Ricardo Johannsen 04/05/2016 at 18:39 #

    Olá Raphael, eu estando em um application server como o wildfly 8, se eu quiser usar o repository do DeltaSpike vou precisar mesmo desse EntityManagerProducer?

Deixe uma resposta