Flávio W. Brasil Blog Blog pessoal a respeito de tecnologia e desenvolvimento de sistemas.

Obtendo o beans do Spring em qualquer classe

É possível obter o BeanFactory de forma estática, permitindo manipular beans do Spring em qualquer trecho de código da aplicação, mesmo em instâncias não gerenciadas pelo Spring. Usei essa funcionalidade de forma parecida na integração do Spring com o GWT, permitindo obter a implementação de um serviço a partir de um servlet que não é um bean do Spring e que portanto não podemos utilizar um @Autowired.

Segue o código:

package br.com.fwb.desktop.util.spring;

import java.util.List;

import org.springframework.beans.*;
import org.springframework.beans.factory.*;
import org.springframework.beans.factory.config.*;
import org.springframework.core.*;

public class SpringBeanFactoryUtil implements PriorityOrdered, BeanFactoryPostProcessor {

    private enum SpringBeanFactoryUtilMode {
        staticMode, threadLocalMode, inheritableThreadLocalMode
    }

    private static ListableBeanFactory beanFactoryStatic = null;
    private static ThreadLocal<ListableBeanFactory> beanFactoryThreadLocal = new ThreadLocal<ListableBeanFactory>();
    private static InheritableThreadLocal<ListableBeanFactory> beanFactoryInheritableThreadLocal = new InheritableThreadLocal<ListableBeanFactory>();

    private SpringBeanFactoryUtilMode mode = SpringBeanFactoryUtilMode.inheritableThreadLocalMode;

    public int getOrder() {
        return Ordered.HIGHEST_PRECEDENCE;
    }

    @Override
    public void postProcessBeanFactory(
            ConfigurableListableBeanFactory beanFactory)
            throws BeansException {
        ListableBeanFactory currentBeanFactory = getBeanFactoryOrNull();
        if (currentBeanFactory != null && currentBeanFactory != beanFactory) {
            throw new IllegalStateException("SpringBeanFactoryUtil nao suporta multiplos contextos");
        } else {
            setBeanFactory(beanFactory);
        }
    }

    public void setMode(
            String mode) {
        this.mode = SpringBeanFactoryUtilMode.valueOf(mode);
    }

    private void setBeanFactory(
            ListableBeanFactory beanFactory) {
        switch (mode) {
            case staticMode:
                beanFactoryStatic = beanFactory;
                break;
            case threadLocalMode:
                beanFactoryThreadLocal.set(beanFactory);
                break;
            case inheritableThreadLocalMode:
                beanFactoryInheritableThreadLocal.set(beanFactory);
                break;
        }
    }

    public static <T> T getBean(
            Class<T> clazz) {
        return BeanFactoryUtils.beanOfTypeIncludingAncestors(getBeanFactory(), clazz);
    }

    @SuppressWarnings("unchecked")
    public static <T> T getBean(
            String name) {
        return (T) getBeanFactory().getBean(name);
    }

    public static ListableBeanFactory getBeanFactory() {
        ListableBeanFactory beanFactory = getBeanFactoryOrNull();
        if (beanFactory == null) {
            throw new IllegalStateException("Bean factory ainda nao inicializada");
        }
        return beanFactory;
    }

    public static ListableBeanFactory getBeanFactoryOrNull() {
        ListableBeanFactory retorno = null;
        if (beanFactoryStatic != null) {
            retorno = beanFactoryStatic;
        } else if (beanFactoryThreadLocal.get() != null) {
            retorno = beanFactoryThreadLocal.get();
        } else if (beanFactoryInheritableThreadLocal.get() != null) {
            retorno = beanFactoryInheritableThreadLocal.get();
        }
        return retorno;
    }

    public static <T> List<T> getBeans(
            Class<T> clazz) {
        return (List<T>) BeanFactoryUtils.beansOfTypeIncludingAncestors(getBeanFactory(), clazz).values();
    }

}

Desta forma, basta chamar no código em que você precisa utilizar um bean do spring:

SpringBeanFactoryUtil.getBean(ClasseDoBean.class)

Um import static do SpringBeanFactoryUtil.getBean deixa o código ainda mais limpo.

Registre o seguinte em seu applicationContext.xml:

<bean class="br.com.fwb.desktop.util.spring.SpringBeanFactoryUtil">
	<property name="mode" value="inheritableThreadLocalMode" />
</bean>

Existem três modos disponíveis para operação do SpringBeanFactoryUtil. Eles definem de que forma é guardada a referência para o BeanFactory, determinando assim em que contexto é possível acessar o BeanFactory e por outro lado restringindo que no respectivo contexto só é possível possuir um contexto do Spring.

1. staticMode

A referência é guardada em uma propriedade static, limitando o contexto às classes carregadas no mesmo classloader.

2. threadLocalMode

A referência é guardada em um threadLocal, limitando o contexto a uma única thread.

3. inheritableThreadLocalMode

A referência é guardada em um inheritableThreadLocal, limitando o contexto a thread que iniciou o Spring e as threads criadas por ela. Considero ser esta a abordagem que serve para a maioria dos casos.

Desenvolvi esta funcionalidade a princípio somente para obter beans em classes que não são gerenciadas pelo Spring, porém tenho utilizado praticamente em substituição ao @Autowired. Segue alguns motivos que me levaram a evitar a injeção de dependência através de anotações que custumava utilizar:

1. Lazy de verdade

Mesmo que você declare que os beans devem ser inicializados de forma lazy, de acordo com a necessidade, o lazy na verdade não é completo. O Spring espera a primeira utilização do bean para instancia-lo no seu devido escopo. Porém, ao inicializa-lo, ele injeta todas as dependências daquela instância e por consequencia carrega também as "subdependencias" dessas dependências. Ou seja, ao se criar um bean, mesmo que esteja no modo lazy, ele instancia todo o grafo de dependências daquele bean. Ao utilizar esta nova abordagem, é possível um lazy completo. A classe é instanciada somente no momento em que se precisa dela.

2. Referências circulares

Referências circulares geralmente são um problema que surgem e indicam má modelagem dos beans. Porém, existem casos em que a dependência circular é realmente necessária e benéfica. Com a abordagem sugerida, pode-se ter referencias circulares sem os erros ao subir o Spring, dado que as dependências são carregadas somente quando requisitadas.

3. Problemas de escopo

Esse é um erro muito comum e que quebra a cabeça de muita gente que trabalha com o Spring. Ao se injetar um bean de um escopo menor em um bean de escopo maior, o bean de escopo menor adere ao mesmo escopo do bean de escopo maior. Isso ocorre porque o Spring instancia todas as dependências de um bean e então o bean guarda a referência a todas as suas dependências. Após esse passo, o Spring não realiza qualquer tipo de gerenciamento sobre esse bean e suas dependências até o destroy. Desta forma, ao se injetar um bean de escopo "prototype" em um bean de escopo "session", a instância da dependência injetada (bean de escopo "prototype") adere ao escopo "session". Com a abordagem sugerida, esse erro é evitado porque a cada vez que for necessária uma dependência ela será solicitada ao container.

É claro que essa abordagem também traz alguns pontos negativos, é uma questão de pesar os pontos positivos e negativos da perspectiva de seu projeto. Os pontos negativos que vejo são:

1. Abordagem não padrão

O Spring possui uma abordagem padrão para acessar seus beans em classes não gerenciadas por ele. Porém esta abordagem inicializa um novo contexto, não considero uma boa solução. Este post mostra uma utilização interessante desta fucionalidade.

Ao não utilizar a abordagem padrão é possível que novas versões do Spring não funcionem corretamente com esta abordagem. É um risco pequeno, mas existe.

2. Limitação de múltiplos contextos

Como falado acima, esta abordagem permite a existência de somente um contexto do Spring em um determinado contexto configurado. Para projetos que utilizam vários contextos isso pode ser um problema impeditivo.

É isso, espero que possa ajudar alguém!

Closures no Java 7?

Estão surgindo rumores de que o Java 7 irá incluir closures. Mark Reinhold, engenheiro-chefe da Sun que trabalha no OpenJDK, anunciou na conferência de java Devoxx, na Bélgica, que a Sun pretende implementar closures no Java 7!

Os engenheiros chegaram à conclusão que sem closures a implementação do Fork Join framework seria muito complexa e ficaria muito deselegante para o OpenJDK.

Stephen Colebourne postou em seu blog com mais detalhes como foi esta apresentação.

A sintaxe apresentada foi a seguinte:

  // function expressions
  #(int i, String s) {
    System.println.out(s);
    return i + s.length();
  }

  // function expressions
  #(int i, String s) (i + s.length())

  // function types
  #int(int, String)

Esta proposta de closures não é baseada nas propostas anteriormente apresentadas: BGGA, CICE e FCM.  BGGA é a proposta mais completa e a CICE mais simples, ficando a FCM "no meio" das duas.

A sintaxe apresentada é parecida com a FCM, porém a implementação é mais limitada porque não será possível declarar as exeções lançadas pela closure (control-invocation) e não terá retorno não local, não sendo possível a closure dar um "return" no contexto do método em que ela está sendo utilizada (non-local return).

Estou torcendo para que realmente a Sun coloque closures no Java 7. Sem dúvida essa é uma grande deficiência e pode dar um novo fôlego para a linguagem.

Detalhe: Parece que o Java 7 está previsto somente para o final de 2010!