Spring 3.1 RC1 – @Configuration

Colocado por DClick Team na(s) categoria(s): 1, 2.0, 4, 6, action, app, AR, auto, bar, BI, blog, busca, C#, case, class, classe, classes, código, components, configuração, err, erro, error, exemplo, for, framework, Google, IE, if, int, Java, lite, map, mudanças, mvc, NaN, O, on, Plugin, refresh, rest, RIA, Ria’s Geral, RoR, S+S, Sem categoria, Spring, SpringFramework, string, Sun, super(), tag, TAT, Teste, Twitter, UI, uint, web, XML em 11 16th, 2011 | Sem comentários

Twitter!

Spring @Configuration

O que há de novo

Para habilitar certas funcionalidades do Spring que envolvem AOP, era preciso escrever tags XML como por exemplo context:component-scan para especificar os pacotes em que o Spring pode buscar por beans anotados com @Component, @Repository ou @Service.
Na versão 3.1 foram disponibilizadas as mesmas funcionalidades via anotação. São elas:

1
2
3
4
5
6
7
8

org.springframework.context.annotation.Configuration
org.springframework.context.annotation.ComponentScan
org.springframework.context.annotation.EnableLoadTimeWeaving
org.springframework.context.annotation.EnableAspectJAutoProxy
org.springframework.scheduling.annotation.EnableScheduling
org.springframework.scheduling.annotation.EnableAsync
org.springframework.transaction.annotation.EnableTransactionManagement
org.springframework.web.servlet.config.annotation.EnableWebMvc

Vamos abordar o caso básico, pois o resto é bem similar.

@ComponentScan

Caso você ainda não esteja familiarizado com as configurações por anotaçãoo, vamos ao básico.
Comece criando uma classe que representará seu container de beans, e a anote com @configuration:

1
2
3
4

@Configuration
public class TestConfiguration

Nesta classe estarão os beans que o container irá instanciar e deixar a nossa disposição.
Para iniciar o container vamos criar um test (JUnit 4) que instancia o contexto:

1
2
3
4
5
6
7
8
9
10
11

public class ConfigurationTestCase

@Test
public void testConfigurationBeans()

AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
ctx.register(TestConfiguration.class);
ctx.refresh();

}

Aqui criamos um container do tipo AnnotationConfigApplicationContext e registramos nossa classe de configuração nele. Repare que é possível registrar mais classes, e portanto disponibilizar mais beans no container.
Agora vamos criar nosso bean de teste:

1
2
3
4
5
6
7
8
9
10
11
12
13

public class GenericBean

private String testProperty;

public GenericBean(String testProperty)
super();
this.testProperty = testProperty;

public String getTestProperty()
return testProperty;

}

Vamos criar os métodos em nossa classe de configuração que instanciam nosso bean de duas maneiras diferentes:

1
2
3
4
5
6
7
8
9

@Bean(name = “testBean”)
public GenericBean genericTestBean()
return new GenericBean(“test”);

@Bean(name = “otherBean”)
public GenericBean genericOtherBean()
return new GenericBean(“other”);

Repare que a única diferença entre os dois é a String que passamos como parâmetro.
Agora que temos 2 beans diferentes em nosso container, vamos criar os testes para verificar o comportamento do Spring. Abaixo da inicialização do contexto, vamos adicionar as seguintes linhas:

1
2
3
4
5
6
7
8
9

GenericBean testBean = ctx.getBean(“testBean”, GenericBean.class);

Assert.assertNotNull(testBean);
Assert.assertEquals(“test”, testBean.getTestProperty());

GenericBean otherBean = ctx.getBean(“otherBean”, GenericBean.class);

Assert.assertNotNull(otherBean);
Assert.assertEquals(“other”, otherBean.getTestProperty());

Aqui estamos garantindo que nossos dois beans diferentes estarão no contexto como esperado.
Antes de rodar o teste, será necessário adicionar a dependência do CGLib ao seu projeto. Caso você esteja usando o maven, basta adicionar a seguinte dependência>

GeSHi Error: GeSHi could not find the language text (using path C:Program Fileswampwwwblogwp-contentpluginsig_syntax_hilitegeshi) (code 2)

Pronto, com isso temos o suficiente pra deixar a barra do JUnit verde. Vamos agora adicionar o @ComponentScan.
Em nossa classe de configuração (poderia ser qualquer outra registrada no contexto) adiciona a seguinte anotação:

1
2
3

@Configuration
@ComponentScan(“br.com.dclick.tentativas.configuration.beans”)
public class TestConfiguration

No meu caso meu bean está dentro do pacote br.com.dclick.tentativas.configuration.beans e portanto basta eu alterá-lo adicionando o seguinte código:

1
2
3
4
5
6
7
8

@Component(“componentBean”)
public class GenericBean

private String testProperty;

public GenericBean()
this.testProperty = “component”;

Dessa forma posso criar mais um teste e verificar que o bean está vindo corretamente:

1
2
3
4

GenericBean componentBean = ctx.getBean(“componentBean”, GenericBean.class);

Assert.assertNotNull(componentBean);
Assert.assertEquals(“component”, componentBean.getTestProperty());

Rode o teste e deixa o JUnit feliz.
A única coisa a se ter cuidado aqui, é que com @ComponentScan, você não pode mapear o diretório da própria classe de configuração.

Demais Configurações

Daqui em diante basta anotar suas classes de configuração com as configurações que você deseja ativar, como por exemplo @EnableAsync que permite que os beans rodem de maneira assíncrona com a anotação @Async.

Brinque um pouco com as outras anotações. Acredito que vale o esforço, pois esse tipo de configuração permite abandonar um pouco os arquivos XML e tornam mais fácil o refactor dos beans, afinal teremos erros de compilação com as mudanças de código.

Por enquanto é isso, qualquer dúvida mande nos comentários que responderei assim que possível.

Por @Gust4v0_H4xx0r

Veja o post original no blog do autor aqui!