• (={
       ,}) (=) public @interface Bean

  Indicates that a method produces a bean to be managed by the Spring container.

  Overview

  The names and semantics of the attributes to this annotation are intentionally similar to those of the <bean/> element in the Spring XML schema. For example:

  @Bean     public MyBean myBean() {         // instantiate and configure MyBean obj         return obj;     }

  Bean Names

  While a  attribute is available, the default strategy for determining the name of a bean is to use the name of the @Bean method. This is convenient and intuitive, but if explicit naming is desired, the nameattribute may be used. Also note that name accepts an array of Strings. This is in order to allow for specifying multiple names (i.e., aliases) for a single bean.

  @Bean(name={"b1","b2"}) // bean available as 'b1' and 'b2', but not 'myBean'     public MyBean myBean() {         // instantiate and configure MyBean obj         return obj;     }

  Scope, DependsOn, Primary, and Lazy

  Note that the @Bean annotation does not provide attributes for scope, depends-on, primary, or lazy. Rather, it should be used in conjunction with , , , and  annotations to achieve those semantics. For example:

  @Bean     @Scope("prototype")     public MyBean myBean() {         // instantiate and configure MyBean obj         return obj;     }

  @Bean Methods in @Configuration Classes

  Typically, @Bean methods are declared within @Configuration classes. In this case, bean methods may reference other @Bean methods in the same class by calling them directly. This ensures that references between beans are strongly typed and navigable. Such so-called 'inter-bean references' are guaranteed to respect scoping and AOP semantics, just like getBean() lookups would. These are the semantics known from the original 'Spring JavaConfig' project which require CGLIB subclassing of each such configuration class at runtime. As a consequence, @Configuration classes and their factory methods must not be marked as final or private in this mode. For example:

  @Configuration public class AppConfig {     @Bean     public FooService fooService() {         return new FooService(fooRepository());     }     @Bean     public FooRepository fooRepository() {         return new JdbcFooRepository(dataSource());     }     // ... }

  @Bean Lite Mode

  @Bean methods may also be declared within classes that are not annotated with @Configuration. For example, bean methods may be declared in a @Component class or even in a plain old class. In such cases, a@Bean method will get processed in a so-called 'lite' mode.

  Bean methods in lite mode will be treated as plain factory methods by the container (similar to factory-method declarations in XML), with scoping and lifecycle callbacks properly applied. The containing class remains unmodified in this case, and there are no unusual constraints for the containing class or the factory methods.

  In contrast to the semantics for bean methods in @Configuration classes, 'inter-bean references' are not supported in lite mode. Instead, when one @Bean-method invokes another @Bean-method in lite mode, the invocation is a standard Java method invocation; Spring does not intercept the invocation via a CGLIB proxy. This is analogous to inter-@Transactional method calls where in proxy mode, Spring does not intercept the invocation — Spring does so only in AspectJ mode.

  For example:

  @Component public class Calculator {     public int sum(int a, int b) {         return a+b;     }     @Bean     public MyBean myBean() {         return new MyBean();     } }

  Bootstrapping

  See @ Javadoc for further details including how to bootstrap the container using  and friends.

  BeanFactoryPostProcessor-returning @Bean methods

  Special consideration must be taken for @Bean methods that return Spring  (BFPP) types. Because BFPP objects must be instantiated very early in the container lifecycle, they can interfere with processing of annotations such as @Autowired, @Value, and @PostConstruct within @Configuration classes. To avoid these lifecycle issues, mark BFPP-returning @Bean methods as static. For example:

  @Bean     public static PropertyPlaceholderConfigurer ppc() {         // instantiate, configure and return ppc ...     }

  By marking this method as 

  static, it can be invoked without causing instantiation of its declaring 

  @Configuration class, thus avoiding the above-mentioned lifecycle conflicts. Note however that 

  static 

  @Beanmethods will not be enhanced for scoping and AOP semantics as mentioned above. This works out in 

  BFPP cases, as they are not typically referenced by other 

  @Bean methods. As a reminder, a WARN-level log message will be issued for any non-static 

  @Bean methods having a return type assignable to 

  BeanFactoryPostProcessor.

  Since:

  3.0

  Author:

  Rod Johnson, Costin Leau, Chris Beams, Juergen Hoeller, Sam Brannen

  See Also:

  ,  ,  ,  ,  ,  ,  , 

• • Optional Element Summary

    Optional Elements

    Modifier and Type	Optional Element and Description
    	Are dependencies to be injected via convention-based autowiring by name or type?
    	The optional name of a method to call on the bean instance upon closing the application context, for example a  close() method on a JDBC  DataSourceimplementation, or a Hibernate  SessionFactory object.
    	The optional name of a method to call on the bean instance during initialization.
    []	The name of this bean, or if plural, aliases for this bean.

• • Element Detail

    • name

      public abstract [] name

      The name of this bean, or if plural, aliases for this bean. If left unspecified the name of the bean is the name of the annotated method. If specified, the method name is ignored.

      Default:

      {}
  • • autowire

      public abstract  autowire

      Are dependencies to be injected via convention-based autowiring by name or type?

      Default:

      org.springframework.beans.factory.annotation.Autowire.NO
  • • initMethod

      public abstract  initMethod

      The optional name of a method to call on the bean instance during initialization. Not commonly used, given that the method may be called programmatically directly within the body of a Bean-annotated method.

      The default value is "", indicating no init method to be called.

      Default:

      ""
  • • destroyMethod

      public abstract  destroyMethod

      The optional name of a method to call on the bean instance upon closing the application context, for example a 

      close() method on a JDBC 

      DataSource implementation, or a Hibernate 

      SessionFactoryobject. The method must have no arguments but may throw any exception.

      As a convenience to the user, the container will attempt to infer a destroy method against an object returned from the @Bean method. For example, given an @Bean method returning an Apache Commons DBCP BasicDataSource, the container will notice the close() method available on that object and automatically register it as the destroyMethod. This 'destroy method inference' is currently limited to detecting only public, no-arg methods named 'close' or 'shutdown'. The method may be declared at any level of the inheritance hierarchy and will be detected regardless of the return type of the @Beanmethod (i.e., detection occurs reflectively against the bean instance itself at creation time).

      To disable destroy method inference for a particular @Bean, specify an empty string as the value, e.g. @Bean(destroyMethod=""). Note that the  and the / interfaces will nevertheless get detected and the corresponding destroy/close method invoked.

      Note: Only invoked on beans whose lifecycle is under the full control of the factory, which is always the case for singletons but not guaranteed for any other scope.

      See Also:

      Default:

      "(inferred)

官方地址：

http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/annotation/Bean.html

http://docs.spring.io/spring-javaconfig/docs/1.0.0.M4/reference/html/ch02s02.html

Annotation Type Import

• (=) (=) public @interface Import

  Indicates one or more   classes to import.

  Provides functionality equivalent to the <import/> element in Spring XML. Only supported for classes annotated with @Configuration or declaring at least one  method, as well as  and implementations.

  @Bean definitions declared in imported @Configuration classes should be accessed by using  injection. Either the bean itself can be autowired, or the configuration class instance declaring the bean can be autowired. The latter approach allows for explicit, IDE-friendly navigation between @Configuration class methods.

  May be declared at the class level or as a meta-annotation.

  If XML or other non-@Configuration bean definition resources need to be imported, use 

  官方地址：http://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/annotation/Import.html

  Annotation Type Configuration

  • (=) (=)  public @interface Configuration

    Indicates that a class declares one or more   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 ...     } }

    Bootstrapping @Configuration classes

    Via AnnotationConfigApplicationContext

    @Configuration classes are typically bootstrapped using either   or its web-capable variant,  . 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   Javadoc for further details and see   for 

    web.xml configuration instructions.

    Via Spring <beans> XML

    As an alternative to registering @Configuration classes directly against an AnnotationConfigApplicationContext, @Configuration classes may be declared as normal <bean> definitions within Spring XML files:

    In the example above, 

    <context:annotation-config/> is required in order to enable   and other annotation-related post processors that facilitate handling 

    @Configurationclasses.

    Via component scanning

    @Configuration is meta-annotated with , therefore @Configuration classes are candidates for component scanning (typically using Spring XML's <context:component-scan/> element) and therefore may also take advantage of / 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  annotation:

    @Configuration @ComponentScan("com.acme.app.services") public class AppConfig {     // various @Bean definitions ... }

    See   Javadoc for details.

    Working with externalized values

    Using the Environment API

    Externalized values may be looked up by injecting the Spring   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  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   and   Javadoc for further details.

    Using the @Value annotation

    Externalized values may be 'wired into' 

    @Configuration classes using the   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  , usually enabled via XML with 

    <context:property-placeholder/>. See the section below on composing 

    @Configurationclasses with Spring XML using 

    @ImportResource, see   Javadoc, and see   Javadoc for details on working with 

    BeanFactoryPostProcessor types such as 

    PropertySourcesPlaceholderConfigurer.

    Composing @Configuration classes

    With the @Import annotation

    @Configuration classes may be composed using the  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);

    With the @Profile annotation

    @Configuration classes may be marked with the   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   and   Javadoc for further details.

    With Spring XML using the @ImportResource annotation

    As mentioned above, 

    @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   annotation. Bean definitions imported from XML can be injected using 

    @Autowired or 

    @Import:

    @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);     } }

    With nested @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.

    Configuring lazy initialization

    By default, @Bean methods will be eagerly instantiated at container bootstrap time. To avoid this, @Configuration may be used in conjunction with the  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.

    Testing support for @Configuration classes

    The Spring 

    TestContext framework available in the 

    spring-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.

    Enabling built-in Spring features using @Enable annotations

    Spring features such as asynchronous method execution, scheduled task execution, annotation driven transaction management, and even Spring MVC can be enabled and configured from 

    @Configurationclasses using their respective "

    @Enable" annotations. See  ,  ,  ,  , and   for details.

    Constraints when authoring @Configuration classes

    • @Configuration classes must be non-final
    • @Configuration classes must be non-local (may not be declared within a method)
    • @Configuration classes must have a default/no-arg constructor and may not use  constructor parameters. Any nested configuration classes must be static.

  官方地址：http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/annotation/Configuration.html