@Target(value=TYPE) @Retention(value=RUNTIME) @Documented @Component public @interface Configuration
@Bean methods and
may be processed by the Spring container to generate bean definitions and
service requests for those beans at runtime, for example:
@Configuration
public class AppConfig {
@Bean
public MyBean myBean() {
// instantiate, configure and return bean ...
}
}
@Configuration classesAnnotationConfigApplicationContext@Configuration classes are typically bootstrapped using either
AnnotationConfigApplicationContext or its web-capable variant,
AnnotationConfigWebApplicationContext. A simple example with the former follows:
AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(); ctx.register(AppConfig.class); ctx.refresh(); MyBean myBean = ctx.getBean(MyBean.class); // use myBean ...See
AnnotationConfigApplicationContext Javadoc for further details and see
AnnotationConfigWebApplicationContext for web.xml configuration instructions.
<beans> XMLAs an alternative to registering @Configuration classes directly against an
AnnotationConfigApplicationContext, @Configuration classes may be
declared as normal <bean> definitions within Spring XML files:
<beans>
<context:annotation-config/>
<bean class="com.acme.AppConfig"/>
</beans>
In the example above, <context:annotation-config/> is required in order to
enable ConfigurationClassPostProcessor and other annotation-related
post processors that facilitate handling @Configuration classes.
@Configuration is meta-annotated with @Component, therefore
@Configuration classes are candidates for component scanning (typically using
Spring XML's <context:component-scan/> element) and therefore may also take
advantage of @Autowired/@Inject
at the field and method level (but not at the constructor level).
@Configuration classes may not only be bootstrapped using
component scanning, but may also themselves configure component scanning using
the @ComponentScan annotation:
@Configuration
@ComponentScan("com.acme.app.services")
public class AppConfig {
// various @Bean definitions ...
}
See the @ComponentScan javadoc for details.
Environment APIEnvironment into a @Configuration
class using the @Autowired or the @Inject annotation:
@Configuration
public class AppConfig {
@Inject Environment env;
@Bean
public MyBean myBean() {
MyBean myBean = new MyBean();
myBean.setName(env.getProperty("bean.name"));
return myBean;
}
}
Properties resolved through the Environment reside in one or more "property
source" objects, and @Configuration classes may contribute property sources to
the Environment object using
the @PropertySources annotation:
@Configuration
@PropertySource("classpath:/com/acme/app.properties")
public class AppConfig {
@Inject Environment env;
@Bean
public MyBean myBean() {
return new MyBean(env.getProperty("bean.name"));
}
}
See Environment
and @PropertySource Javadoc for further details.
@Value annotation@Configuration classes using
the @Value annotation:
@Configuration
@PropertySource("classpath:/com/acme/app.properties")
public class AppConfig {
@Value("${bean.name}") String beanName;
@Bean
public MyBean myBean() {
return new MyBean(beanName);
}
}
This approach is most useful when using Spring's
PropertySourcesPlaceholderConfigurer, usually enabled via XML with
<context:property-placeholder/>. See the section below on composing
@Configuration classes with Spring XML using @ImportResource,
see @Value Javadoc, and see @Bean Javadoc for details on working with
BeanFactoryPostProcessor types such as
PropertySourcesPlaceholderConfigurer.
@Configuration classes@Import annotation@Configuration classes may be composed using the @Import annotation,
not unlike the way that <import> works in Spring XML. Because
@Configuration objects are managed as Spring beans within the container,
imported configurations may be injected using @Autowired or @Inject:
@Configuration
public class DatabaseConfig {
@Bean
public DataSource dataSource() {
// instantiate, configure and return DataSource
}
}
@Configuration
@Import(DatabaseConfig.class)
public class AppConfig {
@Inject DatabaseConfig dataConfig;
@Bean
public MyBean myBean() {
// reference the dataSource() bean method
return new MyBean(dataConfig.dataSource());
}
}
Now both AppConfig and the imported DatabaseConfig can be bootstrapped
by registering only AppConfig against the Spring context:
new AnnotationConfigApplicationContext(AppConfig.class);
@Profile annotation@Configuration classes may be marked with the @Profile annotation to
indicate they should be processed only if a given profile or profiles are active:
@Profile("embedded")
@Configuration
public class EmbeddedDatabaseConfig {
@Bean
public DataSource dataSource() {
// instantiate, configure and return embedded DataSource
}
}
@Profile("production")
@Configuration
public class ProductionDatabaseConfig {
@Bean
public DataSource dataSource() {
// instantiate, configure and return production DataSource
}
}
See the @Profile and Environment
javadocs for further details.
@ImportResource annotation@Configuration classes may be declared as regular Spring
<bean> definitions within Spring XML files. It is also possible to
import Spring XML configuration files into @Configuration classes using
the @ImportResource annotation. Bean definitions imported from XML can be
injected using @Autowired or @Inject:
@Configuration
@ImportResource("classpath:/com/acme/database-config.xml")
public class AppConfig {
@Inject DataSource dataSource; // from XML
@Bean
public MyBean myBean() {
// inject the XML-defined dataSource bean
return new MyBean(this.dataSource);
}
}
@Configuration classes@Configuration classes may be nested within one another as follows:
@Configuration
public class AppConfig {
@Inject DataSource dataSource;
@Bean
public MyBean myBean() {
return new MyBean(dataSource);
}
@Configuration
static class DatabaseConfig {
@Bean
DataSource dataSource() {
return new EmbeddedDatabaseBuilder().build();
}
}
}
When bootstrapping such an arrangement, only AppConfig need be registered
against the application context. By virtue of being a nested @Configuration
class, DatabaseConfig will be registered automatically. This avoids
the need to use an @Import annotation when the relationship between
AppConfig DatabaseConfig is already implicitly clear.
Note also that nested @Configuration classes can be used to good effect
with the @Profile annotation to provide two options of the same bean to the
enclosing @Configuration class.
By default, @Bean methods will be eagerly instantiated at container
bootstrap time. To avoid this, @Configuration may be used in conjunction with
the @Lazy annotation to indicate that all @Bean methods declared within
the class are by default lazily initialized. Note that @Lazy may be used on
individual @Bean methods as well.
@Configuration classesspring-test module
provides the @ContextConfiguration annotation, which as of Spring 3.1 can
accept an array of @Configuration Class objects:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes={AppConfig.class, DatabaseConfig.class})
public class MyTests {
@Autowired MyBean myBean;
@Autowired DataSource dataSource;
@Test
public void test() {
// assertions against myBean ...
}
}
See TestContext framework reference documentation for details.
@Enable annotations@Configuration
classes using their respective "@Enable" annotations. See
@EnableAsync,
@EnableScheduling,
@EnableTransactionManagement,
@EnableAspectJAutoProxy,
and @EnableWebMvc
for details.
@Configuration classes@Autowired constructor parameters. Any nested configuration classes
must be static.
Bean,
Profile,
Import,
ImportResource,
ComponentScan,
Lazy,
PropertySource,
AnnotationConfigApplicationContext,
ConfigurationClassPostProcessor,
Environment,
org.springframework.test.context.ContextConfigurationpublic abstract String value
The custom name applies only if the Configuration class is picked up via
component scanning or supplied directly to a AnnotationConfigApplicationContext.
If the Configuration class is registered as a traditional XML bean definition,
the name/id of the bean element will take precedence.
DefaultBeanNameGenerator