Registrando um bean no Spring dinamicamente

Este blog deixou de ser mantido, mas o autor continua escrevendo aqui. Não deixe de assinar o novo feed!

72334626_0a5684b37c_m.jpgHoje, pleno carnaval e tal… nada melhor do que disperdiçar um tempo com projetos Open Source, não? Lógico que não. Eu devo sofrer de algum distúrbio mental mesmo, só pode…

Enfim, estava mexendo no código do Surf, melhorando o suporte ao Spring. Era algo que julgava fácil de ser resolvido, mas passei umas boas horas em cima até que uma solução apareceu.

Para utilizar o Spring em conjunto com o Surf, era preciso adicionar manualmente alguns beans do Surf para que tudo funcionasse. Um exemplo:

  1.  
  2. <beans>
  3.     <!– faz a integração com o Spring –>
  4.     <bean id="presenterSetup" class="net.sf.surfframework.integration.ioc.spring.SpringPresenterSetup" />
  5.  
  6.     <!– beans da aplicação –>
  7.     <bean id="mainPresenter" class="surfdemo.presenter.MainPresenterImpl" />
  8.  
  9.     <bean id="aboutPresenter" class="surfdemo.presenter.AboutPresenterImpl">
  10.         <property name="parentPresenter" ref="mainPresenter" />
  11.     </bean>
  12. <beans>
  13.  

Veja o bean declarado na linha 9. Em todo santo projeto era necessário declarar esse bean para que a integração entre o Surf e o Spring fosse acionada.

Mas então, o que essa classe SpringPresenterSetup tem de especial? Não muita coisa… segue um trecho do código:

  1.  
  2. package net.sf.surfframework.integration.ioc.spring;
  3.  
  4. public class SpringPresenterSetup implements InitializingBean, ApplicationContextAware {
  5.  
  6.    // …
  7.  
  8.    public void afterPropertiesSet() throws Exception {
  9.       setupConfiguration();
  10.    }
  11.  
  12.    private void setupConfiguration() throws InstantiationException {
  13.       // Faz a integração entre o Surf e o Spring
  14.    }
  15.  
  16.    // …
  17. }
  18.  
  19.  

Esta classe implementa a interface InitializingBean, fazendo com que o Spring invoque o método afterPropertiesSet após a criação e configuração do bean, sendo este um momento ideal para disparar o código de integração entre o Surf e o Spring.

Como o bom desenvolvedor vagabundo que sou, eu deixei que a vagabundice me orientasse. A pergunta que me veio foi:

Porque declarar toda vez o mesmo bean se existe a possibilidade de adicioná-lo automaticamente?

Depois de algumas horas de pesquisa e palpites (em vão, lógico), descobri como isso podia ser feito:

  1.  
  2. package net.sf.surfframework.integration.ioc.spring;
  3.  
  4. public class SpringPresenterSetup implements InitializingBean, ApplicationContextAware {
  5.  
  6.    // …
  7.  
  8.    public static void registerPresenterSetupBean(AbstractApplicationContext context) {
  9.       DefaultListableBeanFactory bf = (DefaultListableBeanFactory) context.getBeanFactory();
  10.       RootBeanDefinition bd = new RootBeanDefinition(SpringPresenterSetup.class);
  11.       bf.registerBeanDefinition("springSetup", bd);
  12.       bf.getBean("springSetup");
  13.    }
  14.  
  15.    // …
  16. }
  17.  

Basicamente o que este código faz é criar um BeanDefinition com os dados do bean a ser instanciado e adicionar esse BeanDefinition no ApplicationContext recebido por parâmetro. O getBean() na linha 11 serve para que o Spring faça a criação e configuração do bean recém-adicionado e, conseqüentemente, dispare o código de integração.

Para que não seja preciso chamar este método toda vez que criarmos um BeanFactory, eu criei duas classes, que herdam de ClassPathXmlApplicationContext e FileSystemXmlApplicationContext e que chamam o método registerPresenterSetupBean em seus construtores. Segue um trecho de uma das classes:

  1.  
  2. package net.sf.surfframework.integration.ioc.spring;
  3.  
  4. // …
  5. public class SurfClassPathXmlApplicationContext extends ClassPathXmlApplicationContext {
  6.  
  7.    public SurfClassPathXmlApplicationContext(String filename) throws BeansException {
  8.       super(filename);
  9.       SpringPresenterSetup.registerPresenterSetupBean(this);
  10.    }
  11.  
  12.    public SurfClassPathXmlApplicationContext(String[] filenames) {
  13.       super(filenames);
  14.       SpringPresenterSetup.registerPresenterSetupBean(this);
  15.    }
  16.  
  17.    // outros construtores…
  18. }
  19.  

Talvez não seja a solução mais elegante para resolver esse “problema”, mas ainda assim esta solução se mostrou razoável para o meu caso. A criação de sub-classes só para chamar o tal do método não parece certo, mas, no carnaval meu amigo.. vale tudo. Depois do feriadão eu arrumo isso! :D

Fazendo as alterações mostradas, agora não é mais necessário declarar o bean SpringPresenterSetup, como mostrado na primeira listagem. O único trabalho que temos é trocar

  1.  
  2. public class MinhaClasse {
  3.    public static void main(String[] args) {
  4.       // Trocar a classe do Spring…
  5.       BeanFactory beanFactory = new ClassPathXmlApplicationContext("application-context.xml");
  6.    }
  7. }
  8.  

por

  1.  
  2. public class MinhaClasse {
  3.    public static void main(String[] args) {
  4.       // … pela nossa classe
  5.       BeanFactory beanFactory = new SurfClassPathXmlApplicationContext("application-context.xml");
  6.    }
  7. }
  8.  

Esse tipo de procedimento costuma ser chamado vulgarmente de gambiware. Mas tudo bem, facilidade de uso em primeiro lugar!

UPDATE

A decisão de incluir o código de integração em sub-classes realmente foi péssima. Só estou aqui para avisar que a coisa foi separada em uma outra classe cujo uso é parecido com a listagem abaixo:

  1.  
  2. public class MinhaClasse {
  3.    public static void main(String[] args) {
  4.       AbstractApplicationContext context = new ClassPathXmlApplicationContext("application-context.xml");
  5.       new SurfSpringIntegration(context).performIntegration(); // Feito!
  6.    }
  7. }
  8.  

Dessa forma, fica fácil para modificar ou estender o código de integração.

Tags: , ,
19 de fevereiro de 2007 | programação