Arquivos de sites

Integrando JSF 2 e Spring

É muito fácil encontrar material sobre JSF 2 de qualidade na internet, mas não se encontra uma forma fácil de realizar a integração com Spring, e quando encontrada, geralmente a integração é feita via xml. Nesse post será mostrado como fazer a integração entre essas duas ferramentas de uma maneira simples usando anotações e um mínimo de xml.

Para trabalhar com o JSF são necessários dois jars:

compile 'com.sun.faces:jsf-api:2.2.0-m04'
compile 'com.sun.faces:jsf-impl:2.2.0-m04'

Por parte do Spring, são os mesmos jars usados para integração com Struts:

compile 'org.springframework:spring-asm:3.1.1.RELEASE'
compile 'org.springframework:spring-beans:3.1.1.RELEASE'
compile 'org.springframework:spring-context:3.1.1.RELEASE' 
compile 'org.springframework:spring-core:3.1.1.RELEASE'
compile 'org.springframework:spring-expression:3.1.0.RELEASE'
compile 'org.springframework:spring-web:3.1.1.RELEASE'

A configuração no web.xml fica assim:

<web-app version=”2.5″ xmlns=”http://java.sun.com/xml/ns/j2ee&#8221;
<servlet>
<servlet-name>faces</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>faces</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<listener>
<listener-class>
org.springframework.web.context.request.RequestContextListener
</listener-class>
</listener>
</web-app>
view raw web.xml This Gist brought to you by GitHub.

As tags servlet e servlet-name são para o uso “padrão” do JSF. A classe ContextLoaderListener é quem vai subir o contexto do Spring, também uma configuração comum. O que merece atenção aqui é o RequestContextListener, o qual vai expor o request para que o Spring possa manipulá-lo, permitindo assim que ele faça as injeções no momento adequado.

Por fim, há mais uma alteração que deve ser colocada no faces-config.xml:

<application>
<el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
</application>

JSF utiliza Expression Language (EL) para determinar a qual classe a página xhtml se refere. Fazendo uso de uma classe chamada ELResolver ele pega a String passada, a interpreta e faz a referência adequada. A classe SpringBeanFacesELResolver proporciona a integração entre os dois frameworks interceptando a requisição e passando-a para o contexto do Spring, o qual a manipula para prover as dependências requeridas pelos ManagedBeans, devolvendo-a em seguida para o ELResolver do próprio JSF.

Para ficar mais claro, vamos ao código. Abaixo, um Dao gerenciado pelo Spring:

@Repository("carroDao")
public class JdbcCarroDao implements CarroDao {

    // métodos aqui
}

Ao utilizar a anotação @Repository, se houver apenas uma implementação para CarroDao, geralmente para o Spring não é necessário que um nome seja especificado, mas ele se faz necessário ao trabalhar com JSF:

@ManagedBean
public class CarroBean {

    @ManagedProperty(name = "dao", value = "#{carroDao}")
    private CarroDao dao;

    public void setDao(final CarroDao dao) {
        this.dao = dao;
    }
}

Agora a anotação @ManagedProperty será usada não apenas para se referir ao que está no escopo web, mas também para lidar com os beans do Spring. A propriedade name é usada para indicar o nome do campo do managedBean, para que o JSF chame o setter adequado, enquanto a propriedade value vai ser usada para referenciar o nome do bean, no caso o carroDao anteriormente especificado.

E é só isso. Fazendo uso do fluxo do próprio JSF, e com algumas poucas configurações, o Spring proporciona uma integração simples e natural, que não altera em nada a forma de trabalhar com JSF.

Fonte: SimpleDev – Juliano Alves

Quando usar o fetch.LAZY e o fetch.EAGER

Alguns conceitos básicos:

  • EAGER – Tradução ->
  1. Ansioso
  2. Impaciente
  3. Ardente
  class NotaFiscal {
  ...
  @OneToMany(fetch=FetchType.EAGER)
  List items;
  }

Imagine que quando você usa o EAGER e dá um get num objeto, ele traz tudo que está dentro do objeto, ou seja, se há um relacionamento 1 para N, no objeto será carregado todas as referências(N) dele. Se sua aplicação depende de performance, este pode ser um problema, pois isto ocupará um grande espaço de memória carregando todas as listas/dependências do objeto.

  • LAZY – Tradução:
  1. Preguiçoso
  2. Indolente
  3. Lento
  4. Ocioso
  5. Vadio
  @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "tabela_despesas", nullable = false)
    public Despesa getRelatorioDespesa() {
        return this.relatorioDespesa;
    }

Desse modo, quando acessamos o objeto ele não traz instantaneamente todas as dependências. Somente quando precisamos do atributo dependente é que a pesquisa (select ou JOIN) é feito, economizando memória. Para que o LAZY faça este select/JOIN é necessário declarar o fetch, dizer como será a pesquisa, se via Selec ou JOIN e você gera então a consulta.

O Hibernate tira proveito de proxies dinâmicas: ele te devolve objetos que fingem ser listas nesse caso, e quando você invoca algum método deles, o Hibernate então faz a respectiva query para carregar o relacionamento. Caelum

Lazy diz QUANDO trazer.lazy=”true” – Traga quando eu precisar ( ou seja. Quando eu acessar ) lazy = “false” – Traga junto com o objeto principal

  • Fetch – Tradução->
  1. buscar
  2. ir buscar
  3. trazer

Fetch diz COMO trazer.fetch = “select” – Faça um select pra pegar esse atributo fetch=”join” – Faça um join com o objeto principal e traga junto com ele. Essa opção ANULA a opção lazy = “true” EAGER, seria equivalente lazy = false.

  1. @Fetch( FetchMode.SELECT )
  2. @Fetch( FetchMode.JOIN )

Todos os relacionamentos *ToOne sãoEAGER, e os *ToMany são LAZY, isso porque relações *toMany são provavelmente mais custosas, trazendo mais objetos para a memória. Caelum

————————————————————————-
Problemas com lazy init (LazyInitializationException)?

Session session = sessionFactory.openSession();
NotaFiscal nf = (NotaFiscal) session.load(NotaFiscal.class, 42);
session.close();

List items = nf.getItems();
System.out.println("numero de pedidos dessa nota:" + items.size());

Esse código tem o seguinte resultado:

org.hibernate.LazyInitializationException: failed to lazily initialize a collection - no session or session was closed.

Utilize o open session in view: Sempre fechar a sessão ao término do trabalho. Mas e quando estamos trabalhando na Web? Após pegarmos os dados necessários no nosso controlador, fechamos a sessão e passamos os objetos ao JSP através de atributos. O JSP, ao acessar um getter do seu objeto para fazer um loop, como ${notaFiscal.items}, recebeLazyInitializationException da mesma forma. Em um primeiro momento o desenvolvedor muda o relacionamento para EAGER, mas isso gera uma enorme sobrecarga, pois provavelmente em muitos lugares não era necessário carregar todos os itens da compra sempre que uma determinada nota fiscal é requisitada. Como então evitar a LazyInitializationException sem modificar o relacionamento paraEAGER? Open Session In View A solução é manter a session aberta durante a renderização da camada de visualização, ou como o Hibernate chama esse pequeno padrão: open session in view. A idéia é bastante simples: a sessão deve ser mantida aberta até o fim da renderização do JSP (ou de qualquer outra camada de apresentação). Isso pode ser obtido através da implementação de um Servlet Filter, algum tipo de interceptador do seu framework preferido ou até mesmo aspectos. O Spring foi sem dúvida um dos primeiros frameworks a já trazer classes para isso embutidas (assim como também foi o primeiro a fazer o wrap da HibernateException dentro de uma exceçãounchecked, pois até o Hibernate 2.x essa exceção era checked). Há as classesOpenSessionInViewInterceptor e sua análoga OpenEntityManagerInViewInterceptor. No VRaptor, além de você pode usar os componentes embutidos do Spring, já existem componentes que fazem o mesmo trabalho (ver componentes embutidos). Leia a matéria completa no blog da CAELUM: http://blog.caelum.com.br/2009/10/13/enfrentando-a-lazyinitializationexception-no-hibernate/  Outro problema:

Hibernate – could not initialize proxy – no Session
  1. 09:15:11,883 ERROR LazyInitializationException:19 – could not initialize proxy – no Session
  2. org.hibernate.LazyInitializationException: could not initialize proxy – no Session
  3.     at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:57)
  4.     at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
  5.     at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:150)
  6.     at org.iprogramming.model.persistence.dto.Person$$EnhancerByCGLIB$$4dfa7473.getName(<generated>)

Essa exception ocorre porque voce fechou a sessão do hibernate (ou entitymanager do JPA usando hibernate). Provavelmente voces estao fechando a sessao/entityManager antes de renderizar a pagina, isso é, antes de fazer o dispatch!

————————————————————————-
Leia a discussão sobre este problema e outras soluções no GUJ:
http://www.guj.com.br/java/60474-hibernate—could-not-initialize-proxy—no-session
http://www.guj.com.br/java/23319-hibernate-3—-orghibernatelazyinitializationexception-could-not-initialize-proxy—the-owning-se

Fonte: Jardelmorais