@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
like any regular @Component. In particular, if a single constructor is present
autowiring semantics will be applied transparently:
@Configuration
public class AppConfig {
private final SomeBean someBean;
public AppConfig(SomeBean someBean) {
this.someBean = someBean;
}
// @Bean definition using "SomeBean"
}
@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 the usual (e.g. using the @Autowired annotation):
@Configuration
public class AppConfig {
@Autowired 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 the usual way (e.g. via constructor injection):
@Configuration
public class DatabaseConfig {
@Bean
public DataSource dataSource() {
// instantiate, configure and return DataSource
}
}
@Configuration
@Import(DatabaseConfig.class)
public class AppConfig {
private final DatabaseConfig dataConfig;
public AppConfig(DatabaseConfig dataConfig) {
this.dataConfig = 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("development")
@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
}
}
Alternatively, you may also declare profile conditions at the @Bean method level,
e.g. for alternative bean variants within the same configuration class:
@Configuration
public class ProfileDatabaseConfig {
@Bean("dataSource")
@Profile("development")
public DataSource embeddedDatabase() { ... }
@Bean("dataSource")
@Profile("production")
public DataSource productionDatabase() { ... }
}
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 the usual way (e.g. using the Inject annotation):
@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 classesstatic.
@Bean methods may not in turn create further configuration classes
(any such instances will be treated as regular beans, with their configuration
annotations remaining undetected).
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