@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("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 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
,
Profile
,
Import
,
ImportResource
,
ComponentScan
,
Lazy
,
PropertySource
,
AnnotationConfigApplicationContext
,
ConfigurationClassPostProcessor
,
Environment
,
ContextConfiguration
Modifier and Type | Optional Element and Description |
---|---|
java.lang.String |
value
Explicitly specify the name of the Spring bean definition associated
with this Configuration class.
|
public abstract java.lang.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