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 AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(); |
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 |
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”) |
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); GenericBean otherBean = ctx.getBean(“otherBean”, GenericBean.class); Assert.assertNotNull(otherBean); |
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>
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 |
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); |
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
