Disponibilizando ViewScope para Spring

spring e jsf

Quem trabalha com JSF sabe que existem escopos para seus Managed Beans, e que eles devem ser bem definidos conforme o papel de cada Managed Bean na aplicação. Esse tal de “escopo” define o tempo de vida desse objeto(o Managed Bean) dentro da aplicação.

A partir do JSF 2.0 foi implementado um novo tipo de escopo, chamado de ViewScope. Este novo escopo veio para suprir a necessidade de se ter um tempo de vida dos Managed Beans um pouco maior do que o Request e menor que o Session. O uso do ViewScope é muito recomendado pois evita que um ManagedBean fique instanciado durante a sessão inteira do usuário(caso do SessionScope) mesmo que não esteja mais sendo usado, e possibilita guardar dados enquanto o usuário não troca de página(UIViewRoot), mesmo utilizando requisições ajax(o que não é possível com o RequestScope).

Grande parte das aplicações possuem frameworks, como o Spring, para gerenciar seus Beans. Logicamente, devem ser utilizadas as configurações do framework para o gerenciamento dos mesmos. No caso do Spring, (ainda) não existe um escopo com a mesma lógica do ViewScope do JSF, mas como todo bom framework, pode-se customizar um tipo de escopo e fazer uso dele normalmente na aplicação. É claro que para isso é necessário implementá-lo.

Na empresa onde trabalho utilizamos Spring e tivemos a necessidade de modificar alguns escopos de Session para View. Encontramos um post(em inglês) que fala sobre isso e exemplifica como implementar e disponibilizar um “ViewScope” para o Spring.

Segue aí os passos para implementar seu ViewScope para o Spring.

1. Implementar a classe responsável pelo gerenciamento dos Beans:

import java.util.Map;

import javax.faces.context.FacesContext;

import org.springframework.beans.factory.ObjectFactory;
import org.springframework.beans.factory.config.Scope;
import org.springframework.web.context.request.FacesRequestAttributes;

public class ViewScope implements Scope {

	public static final String VIEW_SCOPE_CALLBACKS = "viewScope.callbacks";

	public synchronized Object get(String name, ObjectFactory<?> objectFactory) {
		Object instance = getViewMap().get(name);
		if (instance == null) {
			instance = objectFactory.getObject();
			getViewMap().put(name, instance);
		}
		return instance;
	}

	public Object remove(String name) {
		Object instance = getViewMap().remove(name);
		if (instance != null) {
			Map<String, Runnable> callbacks = (Map<String, Runnable>) getViewMap().get(VIEW_SCOPE_CALLBACKS);
			if (callbacks != null) {
				callbacks.remove(name);
			}
		}
		return instance;
	}

	public void registerDestructionCallback(String name, Runnable runnable) {
		Map<String, Runnable> callbacks = (Map<String, Runnable>) getViewMap().get(VIEW_SCOPE_CALLBACKS);
		if (callbacks != null) {
			callbacks.put(name, runnable);
		}
	}

	public Object resolveContextualObject(String name) {
		FacesContext facesContext = FacesContext.getCurrentInstance();
		FacesRequestAttributes facesRequestAttributes = new FacesRequestAttributes(facesContext);
		return facesRequestAttributes.resolveReference(name);
	}

	public String getConversationId() {
		FacesContext facesContext = FacesContext.getCurrentInstance();
		FacesRequestAttributes facesRequestAttributes = new FacesRequestAttributes(facesContext);
		return facesRequestAttributes.getSessionId() + "-" + facesContext.getViewRoot().getViewId();
	}

	private Map<String, Object> getViewMap() {
		return FacesContext.getCurrentInstance().getViewRoot().getViewMap();
	}
}

2. Para poder “destruir” o Bean é necessário colocá-lo em algum local em que seja possível recuperá-lo posteriormente. A classe acima implementa o método registerDestructionCallback, responsável por registrar uma chamada de destruição ao Bean. Essa chamada será armazenada no viewMap da ViewRoot(nossa página que será mostrada), dentro de um Map para que possamos acessá-lo através de uma chave que será o nome do Bean. Graças ao mecanismo de Listeners, conseguimos inserir um novo objeto(no nosso caso um novo Map) dentro do viewMap da página.

Com a implementação da classe abaixo estaremos tratando de dois eventos simultaneamente: assim que o viewMap é construído(na inicialização da página ou PostConstructViewMapEvent) inserimos nosso “repositório” de Beans com ViewScope e seus respectivos destrutores, que será utilizado pelo método registerDestructionCallback, e pouco antes dele ser destruído(PreDestroyViewMapEvent) resgatamos os Beans com ViewScope inseridos no nosso “repositório” criado anteriormente e chamamos seus destrutores.

import java.util.HashMap;
import java.util.Map;

import javax.faces.component.UIViewRoot;
import javax.faces.event.AbortProcessingException;
import javax.faces.event.PostConstructViewMapEvent;
import javax.faces.event.PreDestroyViewMapEvent;
import javax.faces.event.SystemEvent;
import javax.faces.event.ViewMapListener;

public class ViewScopeCallbackRegistrer implements ViewMapListener {

	public void processEvent(SystemEvent event) throws AbortProcessingException {
		if (event instanceof PostConstructViewMapEvent) {
			PostConstructViewMapEvent viewMapEvent = (PostConstructViewMapEvent) event;
			UIViewRoot viewRoot = (UIViewRoot) viewMapEvent.getComponent();
			viewRoot.getViewMap().put(ViewScope.VIEW_SCOPE_CALLBACKS, new HashMap<String, Runnable>());
		} else if (event instanceof PreDestroyViewMapEvent) {
			PreDestroyViewMapEvent viewMapEvent = (PreDestroyViewMapEvent) event;
			UIViewRoot viewRoot = (UIViewRoot) viewMapEvent.getComponent();
			Map<String, Runnable> callbacks = (Map<String, Runnable>) viewRoot.getViewMap().get(ViewScope.VIEW_SCOPE_CALLBACKS);
			if (callbacks != null) {
				for (Runnable c : callbacks.values()) {
					c.run();
				}
				callbacks.clear();
			}
		}
	}

	public boolean isListenerForSource(Object source) {
		return source instanceof UIViewRoot;
	}
}

3. Disponibilizar a nossa classe ViewScope para o Spring, inserindo o código abaixo no seu applicationContext.xml:

<bean class="org.springframework.beans.factory.config.CustomScopeConfigurer">
    <property name="scopes">
        <map>
            <entry key="view">
                <bean class="seupackage.ViewScope"/>
            </entry>
        </map>
    </property>
</bean>

4. Registrar nossa classe ViewScopeCallbackRegistrer nos listeners do Faces, inserindo o código abaixo no faces-config.xml:

<system-event-listener>
    <system-event-listener-class>seuPackage.ViewScopeCallbackRegistrer</system-event-listener-class>
    <system-event-class>javax.faces.event.PostConstructViewMapEvent</system-event-class>
    <source-class>javax.faces.component.UIViewRoot</source-class>
</system-event-listener>

<system-event-listener>
    <system-event-listener-class>seuPackage.ViewScopeCallbackRegistrer</system-event-listener-class>
    <system-event-class>javax.faces.event.PreDestroyViewMapEvent</system-event-class>
    <source-class>javax.faces.component.UIViewRoot</source-class>
</system-event-listener>

Basta agora utilizar a anotação @Scope(“view”) sobre seus Managed Beans e eles passarão a ter o comportamento do @ViewScope, mas agora gerenciados pelo Spring.

Bons códigos!!!

Fonte: http://www.harezmi.com.tr/spring-view-scope-for-jsf-2-users/

6 comentários sobre “Disponibilizando ViewScope para Spring

  1. Vitor,

    Agradeço muito a solução.

    Estou desenvolvendo um sistema com jsf 2., hibernate 3., spring 3. e richfaces 4.

    No richfaces 3.3 havia o keepAlive to ajax que foi retirado na versão 4 me deixando na encruzilhada pois o RequestScope é curto e o Session longo demais. o ViewScope do JSF 2.0 não havia funcionado até esta implementação.

    Vou tomar uma cerveja em sua homenagem (talvez 6 duzia para compensar os dias perdidos XD)

    Grato novamente!

  2. Esta de parabéns pelo post…

    Estou testando e me deparei com dois problema, o 1ª é que o Felipe falou de serializar tudo e o 2º é que quando uso ele da seguinte mensagem quando comunica com o banco de dados javax.persistence.TransactionRequiredException: no transaction is in progress.

    Desde já agradeço.

  3. Felipe, quanto à serialização, creio que seja normal pedir que serialize, pois andei lendo que os conteiners(tipo o tomcat) às vezes serializam objetos(tipo managedBeans), para equilibrar a carga de requisições e outros processos relativos à performance.

    Marcos, creio que o problema de transação seja relativo à bibliotecas(alguma faltando ou alguma sobrando). Um amigo meu passou por este problema também.
    Pra tentar contornar esses problemas com dependências, eu uso o Maven. Disponibilizei um “miniprojeto” que fiz pra testar esse problema que vc relatou e, por sorte, não ocorreu.

    O projeto pode ser baixado no link
    http://www.esseconhece.com.br/wp-content/uploads/2012/01/cloudcar.zip
    e é um projeto do eclipse.

    A princípio funcionou com spring 3.0.6 tranquilo. Espero que ajude.

  4. Um dos grandes problemas do ViewScope do JSF e do CDI é o fato de pro exemplo eu estar em uma página e clicar em um ou que disparam um “GET” para realizar a navegação, nestes casos o managed bean simplesmente não é destruido, podendo gerar até mesmo out of memory no servidor, o viewscope do jsf até a versão 2.1 os beans em view scope não eram destruidos mesmo quando a sessão do usuário era destruida. Eu testei essa implementação de view scope com spring e na navegação com “GET” nunca está chamando o método que remove o bean do view map. Como realemnte garantir que eeese bean vai ser destruido no unload da página?

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *