View source for Spring Dependency Injection and Inversion of Control Container Concepts

=External=

* www.tutorialspoint.com/spring/index.htm

=Internal=

* [[Spring_Framework#Spring_Framework_Core_Technologies_Concepts|Spring Framework]]
* [[Inversion_of_Control_Pattern#Overview|Inversion of Control Pattern]]

=Overview=

Spring is a dependency injection framework. Its main responsibilities are to provide a [[#Configuration_Model|configuration model]] that specifies how components should be defined and what are the dependencies between defined components, [[#Component_Detection|detect]] conforming components in the libraries available on the classpath, [[#Component_Lifecycle|instantiate]] the component graph while transitively honoring the dependency relationships - by instantiating the dependency before the dependent and injecting the appropriate dependency references into dependents - and finally expose the components to the application. Instantiation, dependency injection and component life cycle management take place within the [[#Spring_IoC_Container|Spring IoC container]]. Support for different application architectures, including messaging, transactions and persistence is built in top of the core container.

=<span id='Spring_Dependency_Injection_Framework'></span>Dependency Injection=

Dependency Injection a [[Inversion_of_Control_Pattern#Use_Cases|pattern]] to address object coupling problem. An approach that does not involve dependency injection usually uses the main program to explicitly create dependencies with  <tt>new</tt>, assign them to variables carried by their dependents and proceed to execute methods.  A dependency injection runtime proceeds differently: it first creates the dependencies, which are then injected '''transparently''' into the components who request them and into the main program. Tight coupling is bad when the goal is to build testable, maintenable and scalable systems. Rather than have individual components create and manage the lifecycle of their dependency components, a dependency-injected application relies on container to first create all components, then to inject them into other components that need them. 

<span id='Injection_Types'></span>There are several kinds of '''injection types''', described below. In all cases, it is recommended to always use assertions for mandatory dependencies.

====Constructor Injection====

The dependency reference is injected via a constructor argument. The constructors have the advantage that save us from writing extra setter code. However, a large number of arguments on a constructor is probably a sign that the class takes on too many responsibilities. These are examples how dependency are injected with constructor injection in [[#Constructor_Injection_XML_Example|XML]] and [[#Constructor_Injection_Java_Example|Java]]. Prefer constructor injection to ensure that objects can be instantiate directly. Constructor injection used instead of [[#Member_Variable_Injection|field injection]] makes test easier to write.

====Setter Injection====
The dependency reference is injected via a setter method. These are examples how dependency are injected with setter injection in [[#Setter_Injection_XML_Example|XML]] and [[#Setter_Injection_Java_Example|Java]].

====<span id='Member_Variable_Injection'></span>Member Variable (Field) Injection====

The Spring team recommends avoiding field injection and to always use [[#Constructor_Injection|constructor injection]] in the beans.

=Inversion of Control=

See [[#Dependency_Injection|Dependency Injection]] above.

=Design to Interface=

"Design to Interface" is a development approach where we express the interaction between the components in terms of contracts of interfaces they implement. When we design to interface, concrete classes bind themselves to an interface contract, rather than to a specific implementation. The implementation can be modified transparently, as long as it honors the contract. Spring dependencies can be fully expressed using interface types, leaving to the container binding to concrete implementation at runtime.  However, the concrete classes implementing those interfaces must be declared as components. Spring dependency injection provides a solution to matching appropriate concrete implementation of an interface at runtime.

{{External|[https://github.com/ovidiuf/playground/tree/master/spring/ioc-container/05-design-to-interface Playground Design to Interface Example]}}

=Configuration Model=

This section refers to '''component configuration''', or '''bean wiring'''. Configuration as in external data that is provided to the application in form of properties or environment variables, and which potentially modifies the behavior of the application, is addressed in the "[[Spring Property Injection Concepts|Property Injection Concepts]]" section.

<span id='Configuration_Metadata'></span>Spring runtime expects to receive information about what components it should create and how those components should be wired together either in form of [[#XML_Configuration_Metadata|XML files]] or, since Spring 2.5, as annotation-based metadata embedded within the bytecode of the component classes themselves and referred to as [[#Java-Based_Configuration_Metadata|Java-based configuration]]. This information that tells Spring how to build its components and what other components they depend on is called '''configuration metadata'''. Configuration metadata expressed as [[#XML-based_Configuration_Metadata|XML]] is equivalent with configuration metadata provided in form of [[#Annotation-based_Configuration_with_.40Autowired_and_Stereotype_Annotations|Java annotations]]. Either can be used to the same effect. 

<span id='Using_XML-based_Configuration_Together_with_Java-based_Configuration'></span>XML-based configuration, Java-based configuration and annotation-based configuration can also be '''combined and used together'''. However, when they are used together, annotation injection is performed before XML injection, thus the XML configuration overrides the annotations for properties wired through both approaches.

Configuration metadata includes the definitions of what constitutes a component - the Java fully qualified classname of the component class, the component's dependencies on other components, the component lifecycle details and where to find component classes. Depending on the metadata format, this information is provided in different formats. For example, in case of XML-based configuration, the fully qualified class name is provided in the "class" attribute of the <tt><bean></tt> element. However, for Java-based configuration, a component class is annotated as a [[@Component]] or a similar annotation, so Spring runtime has already the class information when it detects the annotation in the class' bytecode.

==<span id='XML-based_Configuration'></span>XML-based Configuration Metadata==
{{External|[https://github.com/ovidiuf/playground/tree/master/spring/ioc-container/01-xml-based-configuration Playground XML-based Configuration Example]}}

The XML-based configuration historically precedes Java-based configuration. First Spring releases came with only XML configuration support.

<span id='Spring_beans.xml'></span>This is an example of a simple Spring XML configuration file: {{Internal|Spring beans.xml|beans.xml}}

====XML-based Component Definition====

When [[#XML-based_Configuration_Metadata|XML-based metadata]] is used, Spring components are defined using a <bean> element:
<syntaxhighlight lang='xml'>
<beans ...>
    <bean name="red" class="playground.Red"/>
</beans>
</syntaxhighlight>

In this example, the Red class is declared as a recipe to build a bean which has no other bean dependencies:

<syntaxhighlight lang='java'>
public class Red {
  public Red() {
    ...
  }
}
</syntaxhighlight>

One essential element of component definition is the specification of the component's dependencies, using the <tt>ref</tt> attribute. Once the dependencies are specified in the XML configuration metadata, the Spring IoC container automatically injects dependency instances into its managed components. For XML-based metadata, dependencies of a component can be injected via [[#Constructor_Injection|constructor]] or via [[#Setter_Injection|setter]].

<span id='Constructor_Injection_XML_Example'></span>This is an example of [[#Constructor_Injection|constructor injection]]:

<syntaxhighlight lang='xml'>
<bean name="blue" class="playground.Blue">
  <constructor-arg ref = "red"/>
</bean>
</syntaxhighlight>

The corresponding component Java class is:

<syntaxhighlight lang='java'>
public class Blue {
  private Red red;
  ...
  public Blue(Red red) {
    this.red = red;
  }
  ...
}
</syntaxhighlight>

<span id='Setter_Injection_XML_Example'></span>This is an example of [[#Setter_Injection|setter injection]]:

<syntaxhighlight lang='xml'>
<bean name="green" class="playground.Green">
  <property ref = "red"/>
</bean>
</syntaxhighlight>

The corresponding component Java class is:

<syntaxhighlight lang='java'>
public class Green {
  private Red red;
  ...
  public void setRed(Red red) {
    this.red = red;
  }
  ...
}
</syntaxhighlight>

Note that dependencies are injected only into container-managed components. Components created with <tt>new</tt> are not managed by the container, so they will not have their dependencies injected. The transitive dependency injection is triggered when the component is obtained from the container with one of the getBean(...) methods, as in the following example. The application context must be one of the XML-enabled application context implementations, such as [[#ClassPathXmlApplicationContext|ClassPathXmlApplicationContext]] or [[#FileSystemXmlApplicationContext|FileSystemXmlApplicationContext]].
<syntaxhighlight lang='java'>
ApplicationContext context = new ClassPathXmlApplicationContext("red-blue-grean-beans.xml");

// this component will get its "red" dependency injected by the container
Blue blue = (Blue)context.getBean("blue");
</syntaxhighlight>

====<span id='annotation-config'></span><context:annotation-config>====

The <context:annotation-config> element activates detection of [[#@Autowired|@Autowired]] and <span id='@Required'></span>[[@Required]], JSR-250 @PostConstruct, @PostDestroy, @PreDestroy and @Resource, @EJB, @PersistenceContext, etc. It also activate detection of [[#@Configuration|@Configuration]]-annotated classes. Note that by default, annotation configuration detection is not enabled and the element has to be explicitly specified.

<syntaxhighlight lang='xml'>
<context:annotation-config/>
</syntaxhighlight>

====<span id='component-scan'></span><context:component-scan>====

The <context:component-scan> element configures the context to scans the classpath for annotated stereotype components that will be auto-registered Spring beans: [[#@Component|@Component]], [[#@Repository|@Repository]], [[#@Service|@Service]], [[#@Controller|@Controller]], [[#@RestController|@RestController]], @ControllerAdvice, as well as Java-based configuration classes annotated with [[#@Configuration|@Configuration]]:
<syntaxhighlight lang='xml'>
<context:component-scan base-package="io.playground"/>
</syntaxhighlight>

This tag requires [[#.3Ccontext:annotation-config.3E|<context:annotation-config>]] to be active. Once a base package is specified with <context:component-scan/>, Spring will search the base package and all its sub-packages for components. The equivalent annotation-based configuration annotation is [[#@ComponentScan|@ComponentScan]].

==<span id='Java-based_Configuration'></span><span id='Java-based_Configuration_Metadata'></span><span id='.40Configuration.2F.40Bean'></span><span id='@Configuration'></span><span id='@Bean'></span>Java-based Configuration Metadata @Configuration/@Bean==
{{External|[https://github.com/ovidiuf/playground/tree/master/spring/ioc-container/02-java-based-configuration Playground Java-based Configuration Example]}}

Java-based configuration is semantically equivalent with [[#XML-based_Configuration_Metadata|XML-based configuration]] and it is an alternative to it, or it can be used [[#Using_XML-based_Configuration_Together_with_Java-based_Configuration|together]] with it.  The place of the XML bean definition file, whose root is the <beans> element, is taken by a Java class annotated with [[@Configuration]]. Individual XML <bean> definitions are replaced with [[#@Bean|@Bean]]-annotated methods of the configuration class. The application context's constructor accepts configuration class types as argument, instead of XML file names. 

The @Configuration annotation indicates that the class it annotates is a '''configuration class''' (some documentation sources refer to it as a "bootstrap class") that will provide [[#Spring_Components|beans]] to the Spring [[#Application_Context|application context]]. @Configuration triggers the configuration of the Spring infrastructure. A @Configuration-annotated class must expose one or more methods annotated with [[@Bean]]. A @Bean-annotated method is the equivalent of an <bean> element in an Spring XML configuration file. The objects returned by these methods are bean instances, and when the methods are invoked by the Spring container, the corresponding beans are added to the application context. By default, their respective bean IDs will be the same as the names of the methods that define them. The Spring container invokes these methods with the goal of obtaining bean definitions. It is important to point out that even if regular client code, and not the Spring container calls [[@Bean]]-annotated methods, the calls will be intercepted by the container and they will return the bean instance stored in the application context, not a new object instance.

It is possible to extend the application bootstrap configuration to add more configuration. However, it is good practice to create a new configuration class for each kind of configuration (web, data, security, etc.), keeping the application bootstrap configuration clean and simple. Example: [[Java-Based Spring Security Configuration]].

====Java-based Component Definition====

This section presents the equivalent Java-based component definition for the components defined with XML in the [[#XML-based_Component_Definition|previous section]]. Concepts behind Java-based configuration are presented in the [[#Java-based_Configuration_Metadata|Java-based Configuration Metadata]] section.

The bean classes presented in the previous example do not change. The equivalent of the XML file is a @Configuration-annotated class:

<syntaxhighlight lang='java'>
@Configuration
public class ApplicationConfiguration {
  @Bean
  public Red red() {
    return new Red();
  }
  @Bean
  public Blue blue(Red red) {
    // constructor injection
    return new Blue(red);
  }
  @Bean
  public Green green(Red red) {
    Green green = new Green();
    // setting injection
    green.setRed(red);
    return green;
  }
}
</syntaxhighlight>

The application context must be an [[#AnnotationConfigApplicationContext|AnnotationConfigApplicationContext]]:
<syntaxhighlight lang='java'>
ApplicationContext applicationContext = new AnnotationConfigApplicationContext(ApplicationConfiguration.class);
Blue blue = (Blue)applicationContext.getBean("blue");
</syntaxhighlight>

====Mixing @Configuration and @Autowired in the Same Class====

Anecdotal evidence seems to suggest that annotating a class with @Configuration, and then expect it to be injected with @Autowired produces unexpected results. Best to avoid until researched in more detail.

==<span id='Annotation-based_Configuration'></span><span id='Stereotype'></span>Annotation-based Configuration with @Autowired and Stereotype Annotations==

{{External|[https://github.com/ovidiuf/playground/tree/master/spring/ioc-container/03-annotation-based-configuration Playground Annotation-based Configuration Example]}}

Annotation-based configuration refers to the possibility of using annotations in the component class, on the relevant class, method and field declaration, to express the fact that the class is a Spring component, and also other Spring semantics, such as dependency on another component. Annotation-based configuration can be used to provide all metadata that would otherwise be provided with XML-based configuration or Java-based configuration. Components can be declared using <span id='Stereotypes'></span>'''stereotype annotations'''. A stereotype annotation denotes the role of the annotated bean in the overall architecture at a conceptual, rather than implementation, level:
* <span id='@Component'></span>'''[[@Component]]''' designates the annotated class as a generic component and a candidate for [[#Auto-detection|auto-detection]] when using [[#Annotation-based_Configuration|annotation-based configuration]] and [[#Component_Scan|classpath scanning]]. Components are [[#Singleton|singletons]].
* <span id='@Controller'></span>'''[[@Controller]]''' designates the annotated class as a [[Spring_MVC_Concepts#Controller|controller]].
* <span id='@RestController'></span>'''[[@RestController]]'''.
* <span id='@Indexed'></span>'''[[@Indexed]]''' designates the annotated class as a stereotype for the index.
* <span id='@Repository'></span>'''[[@Repository]]''' designates the annotated class as a persistence [[Spring_Persistence_Concepts#Repository|repository]].
* <span id='@Service'></span>'''[[@Service]]''' designates the annotated class as a "service", as defined by [[Domain-Driven_Design#Service|Domain-Driven Design service]].

====@Autowired====

Dependency between components can be declared with the [[@Autowired]] annotation. When a member variable, method or constructor is annotated with @Autowired, the framework will look for the relevant dependency in the container and inject it. From this perspective, @Autowired is analogous to a "ref=" declaration in an XML metadata file. Note that the injected components must also be managed by the application context. An instance created with <tt>new</tt> cannot be autowired into a Spring component, as the application context does not know about it. 

Spring-specific @Autowired is equivalent with [[JSR-330]] [[@Inject]] annotation. 

If a class has just one constructor, it will be considered automatically an autowiring target, even if [[#@Autowired|@Autowired]] is not declared. 

When a constructor used for autowiring also contains non-component arguments, default values for those can be specified with the <span id='@Value'></span>[[@Value]] annotation. A detailed example of how to configure components is available [[#Annotation-based_Component_Definition|below]].

====@ComponentScan====
[[@ComponentScan]] is the annotation-based configuration equivalent of the XML [[#component-scan|<context:component-scan>]]. It allows specifying a base package, or multiple base packages to use for [[#Component_Scanning|component scanning]]:
<syntaxhighlight lang='java'>
@ComponentScan("playground")
...
</syntaxhighlight>

<span id='@ComponentScans'></span>[[@ComponentScans]] is available If we need to specify more than one base packages:
<syntaxhighlight lang='java'>
@ComponentScans(@ComponentScan(basePackages = "some.experimental.dependency"))
</syntaxhighlight>

Once one or more base packages are specified with @ComponentScan, Spring will search the base package and all its sub-packages for components.

The [[#component-scan|<context:component-scan>]] element requires the [[#annotation-config|<context:annotation-config>]] element; however, @ComponentScan annotation does not. This is because in almost all cases when using @ComponentScan, default annotation config processing (e.g. processing  @Autowired) is assumed. Furthermore, when using [[#AnnotationConfigApplicationContext|AnnotationConfigApplicationContext]], annotation config processors are always registered, meaning that any attempt to disable them at the @ComponentScan level would be ignored.

====Annotation-based Component Definition====

This section presents the equivalent annotation-based component definition for components defined with XML in the [[#XML-based_Component_Definition|XML-based Component Definition]] section or with Java-based configuration in the [[#Java-based Component Definition|Java-based Component Definition]] section. Concepts behind annotation-based configuration are presented in the [[#Annotation-based_Configuration|Annotation-based Configuration]] section.

First off, there is no [[#@Configuration|@Configuration]]-annotated class, nor an XML file. The components are detected dynamically in the classpath, being singled out by their stereotype annotations. The dependency relationships are not expressed in the @Bean-annotated methods, or <bean> XML elements. They are expressed with [[#@Autowired|@Autowired]] annotations instead. Aside from getting extra annotations, the bean classes presented in the previous example do not change. The application context must be an [[#AnnotationConfigApplicationContext|AnnotationConfigApplicationContext]] configured with the name of the base package that contains the annotated classes; this is how the component are actually identified:
<syntaxhighlight lang='java'>
ApplicationContext applicationContext = new AnnotationConfigApplicationContext("io.playground.spring");
Blue blue = (Blue)applicationContext.getBean(Blue.class);
</syntaxhighlight>

The component classes used in the previous examples will stay almost unchanged, with the exception of stereotype, [[#@Autowired|@Autowired]] and [[#@Value|@Value]] annotations:

<syntaxhighlight lang='java'>
@Component
public class Red {
  private String payload;
  public Red(@Value("bright") String payload) {
    this.payload = payload;
  }
  ...
}
</syntaxhighlight>

<span id='Constructor_Injection_Java_Example'></span>This is an example of [[#Constructor_Injection|constructor injection]].
<syntaxhighlight lang='java'>
@Component
public class Blue {
  private Red red;
  private String payload;
  @Autowired
  public Blue(Red red, @Value("some default value") String payload) {
    this.red = red;
    this.payload = payload;
  }
  ...
}
</syntaxhighlight>
<span id='Setter_Injection_Java_Example'></span>This is an example of [[#Setter_Injection|setter injection]].
<syntaxhighlight lang='java'>
@Component
public class Green {
  private Red red;
  private String payload;
  public Green(@Value("fresh") String payload) {
    this.payload = payload;
  }
  @Autowired
  public void setRed(Red red) {
    this.red = red;
  }
  ...
}
</syntaxhighlight>

==XML-based, Java-based and Annotation-based Configuration Combinations==

<span id='Using_XML-based_Configuration_from_a_Java-based_Configuration_Application_Context'></span>Metadata specified in an XML file can be used by an application that instantiates a Java-based-configuration application context if the XML metadata is exposed via a special @Configuration class:

<span id='SupplementalXmlConfiguration'></span><syntaxhighlight lang='java'>
@Configuration
@ImportResource({"classpath*:extra-beans.xml"})
public class SupplementalXmlConfiguration {}
</syntaxhighlight>

This configuration class should be registered with the application context alongside the proper Java-based @Configuration classes:

<syntaxhighlight lang='java'>
ApplicationContext applicationContext = new AnnotationConfigApplicationContext(
  ApplicationConfiguration.class, SupplementalXmlConfiguration.class);
</syntaxhighlight>

Beans specified in the extra-beans.xml XML metadata file and those specified in the ApplicationConfiguration class can interoperate with each other and can be declared dependencies of each other. 

{{External|[https://github.com/ovidiuf/playground/tree/master/spring/ioc-container/02.1-xml-with-java-based-configuration Playground XML-based Configuration from a Java-based Configuration Application Context]}}

<span id='Using_Java-based_Configuration_from_an_XML-based-configuration_Application_Context'></span>Symmetrically, an XML-based application context detects [[@Configuration]]-annotated classes, as well as [[#Stereotypes|stereotype annotations]] and [[#@Autowired|@Autowired]] injection, and allows beans declared by them to interoperate with beans declared in the XML metadata and declare dependencies on each other. The detection is configured by specifying [[#annotation-config|<context:annotation-config>]] and  [[#component-scan|<context:component-scan>]] tags in the XML file. 

{{External|[https://github.com/ovidiuf/playground/tree/master/spring/ioc-container/01.1-java-based-configuration-with-xml-configuration Playground Java-based Configuration from an XML-based-configuration Application Context]}}

<span id='AnnotationConfigApplicationContext_with_BasePackage'></span>All three types of configuration can be mixed together:

<syntaxhighlight lang='java'>
ApplicationContext applicationContext = new AnnotationConfigApplicationContext("io.playground");
applicationContext.register(JavaBasedApplicationConfiguration.class);
applicationContext.register(SupplementalXmlConfiguration.class);
</syntaxhighlight>
where JavaBasedApplicationConfiguration.class is a regular [[#@Configuration|@Configuration]]-annotated configuration class, and SupplementalXmlConfiguration.class is also a configuration class that exposes XML metadata read from files, as described [[#SupplementalXmlConfiguration|above]].

{{External|[https://github.com/ovidiuf/playground/tree/master/spring/ioc-container/04-xml-java-based-annotation-based-together Playground Annotation-based and Java-based Configuration from an XML-based-configuration Application Context]}}

=<span id='Container'></span><span id='IoC_Container'></span><span id='Inversion_of_Control_Container'></span>Spring IoC Container=

The Spring IoC container is alo referred to as the '''core container'''. The container is a pool of beans created in a memory space by the framework when the application starts up. Some of the beans, such as the [[#Singleton|singletons]], are instantiated right away, when the container is created and started. Other beans are lazily loaded: unless the bean is requested by the application or some other beans as part of their dependency graph, the framework will not instantiate the bean. The container exposes an API that has methods to query these beans.

If the dependency graph cannot be fulfilled during initialization, Spring '''fails fast'''. When the framework encounters any issues in initializing a bean, it quits. No half-configured beans are ever created. 

==Bean Factory==

The simplest type of container is a '''bean factory''', described by the [https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/BeanFactory.html BeanFactory] interface. A bean factory provided dependency injection to its beans, initialization and destroy callback invocations.

==Application Context==

An '''application context''', described by the [https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/ApplicationContext.html ApplicationContext] interface, extends a bean factory, so anything a bean factory can do, the application context can do too. Additionally, an application context provides ability to load file resources, inherited from ResourceLoader, ability to publish application events to registered listeners, inherited from ApplicationEventPublisher,  ability to resolve messages, inherited from MessageSource, inheritance from a parent context and aspects support. The Spring Framework comes with several types of application context implementations:
* <span id='ClassPathXmlApplicationContext'></span>'''[https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/support/ClassPathXmlApplicationContext.html ClassPathXmlApplicationContext]''' is a standalone XML application context that reads the the configuration metadata from XML files from the classpath.
* <span id='FileSystemXmlApplicationContext'></span>'''[https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/support/FileSystemXmlApplicationContext.html FileSystemXmlApplicationContext]''' is a standalone application context that reads the the configuration metadata from XML files loaded from the file system or from URLs, interpreting plain paths as relative file system location.
* '''[https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/context/support/XmlWebApplicationContext.html XmlWebApplicationContext]'''.
* <span id='AnnotationConfigApplicationContext'></span>'''[[AnnotationConfigApplicationContext]]''' is a standalone application context that can instantiate beans whose metadata is expressed as annotations. This application context is used by the [[Spring_Boot_Concepts#Spring_Boot_Application_Context|Spring Boot applications]]. More details available here:
{{Internal|AnnotationConfigApplicationContext|AnnotationConfigApplicationContext}}

===Who Creates the Application Context?===

A "classic" Spring Framework application explicitly creates its own application context, usually in its own main class. In the example provided below, the application statically creates an [[#ClassPathXmlApplicationContext|ClassPathXmlApplicationContext]], which takes the bean definitions to be created and the dependency relationships between them from an XML file found in the classpath.

<syntaxhighlight lang='java'>
public class Main {
    static ApplicationContext APPLICATION_CONTEXT = 
      new ClassPathXmlApplicationContext("some-beans.xml");
    public static void main(String[] args) {
        ...
    }
}
</syntaxhighlight>

Alternatively, an AnnotationConfigApplicationContext can be used:
<syntaxhighlight lang='java'>
public class Main {
    private static ApplicationContext APPLICATION_CONTEXT = 
      new AnnotationConfigApplicationContext("playground.spring");
    public static void main(String[] args) {
      AComponent c = APPLICATION_CONTEXT.getBean(AComponent.class);
    }
}
</syntaxhighlight>

One improvement brought forward by Spring Boot is that Spring Boot applications are not required to do that. The Spring Boot runtime [[Spring_Boot_Concepts#Spring_Boot_Application_Context|transparently creates the application context]].

<font color=darkgray>How to I find an application context that already exists? </font>

===<span id='Application_Context_Initializer'></span>Application Context Initializer===

===<span id='Application_Listener'></span>Application Listeners===

{{Internal|Spring_Framework_Event_Handling#Application_Event_Listener|Spring Framework Event Handling}}

===Application Context Customization===

<font color=darkgray>TODO: https://docs.spring.io/spring-boot/docs/current/reference/html/howto-spring-boot-application.html#howto-customize-the-environment-or-application-context</font>

===Application Context Refresh===

Refreshing an application context means loading the persistent bean configuration representation from XML, annotations, database. etc. The method destroys already created singletons. It consists of the following sequence:
* Preparation: record startup date, initialize property sources and validate all required properties.
* Refresh and obtain a refreshed bean factory.
* Prepare the bean factory for use in this application context: set the context's class loader into the factory, set the bean expression resolver, add ApplicationContextAwareProcessor as bean post-processor, registers the bean factory with the context as "BeanFactory.class", register the default environment beans ("environment", "systemProperties", "systemEnvironment").
* Post-process bean factory.
* Invoke factory processors registered as beans in the context.
* Register bean processors that intercept bean creation.
* Initialize the message source.
* Initialize the event multicaster.
* Initialize special beans (onRegister())
* Check for listener beans and register them.
* Instantiate all remaining (non-lazy-init) singletons.
* Publish the refresh event.

=Spring Components=

A Spring component is a Java object that is created and managed by the Spring Framework. It is also known as '''Spring bean'''. Any non-trivial application consists of many components, each responsible for its own piece of the overall application functionality. These components coordinate with each other. The Spring container creates and introduces the beans to each other.

==Component Detection==

Spring needs to know which are the components to work with, and where their classes are; it does not know about a bean unless it knows where to search for it. As it has been described in the "[[#Configuration_Model|Configuration Model]]" section, Spring gets this information in form of [[#Configuration_Metadata|configuration metadata]], from XML files, [[#@Configuration|@Configuration]]-annotated Java classes and directly from the JARs in its classpath, in case of classes annotated with [[#Stereotypes|stereotype annotations]] and [[#@Autowired|@Autowired]]. In the case of beans defined in the XML file, Spring runtime learns how to find the components from the fully qualified class name specified in the <bean> definition, expecting to find the class in the classpath. However, there is an alternative component detection mechanism, named [[#Component_Scanning|component scanning]]:

===<span id='Component_Scan'></span>Component Scanning===
Component scanning is the process of inspecting JARs on the classpath in an attempt to find relevant annotations: [[#Stereotypes|stereotype annotations]], [[#@Autowired|@Autowired]] and [[#@Configuration|@Configuration]]. Component scanning is enabled with [[#.3Ccontext:component-scan.3E|<context:component-scan>]], [[#@ComponentScan|@ComponentScan]] or [[#@ComponentScans|@ComponentScans]] annotations.  When component scanning is on, the Spring runtime is given a list of base packages to scan, and it looks for [[#Stereotypes|stereotype]]-annotated classes in those package and in their sub-packages. The base packages are specified with the [[#.3Ccontext:component-scan.3E|<context:component-scan>]] XML configuration element, the [[#AnnotationConfigApplicationContext_with_BasePackage|AnnotationConfigApplicationContext constructor that gets the base package]] or as annotation-based configuration, in form of [[#@ComponentScan|@ComponentScan]]/[[#@ComponentScans|@ComponentScans]] annotations.

===Component Scanning and Spring Boot===

{{Internal|Spring_Boot_Concepts#Component_Scanning|Spring Boot Component Scanning}}

==Component Definition==

See [[#XML-based_Component_Definition|XML-based component definition]], [[#Java-based_Component_Definition|Java-based Component Definition]] and [[#Annotation-based_Component_Definition|Annotation-based Component Definition]] above.

==Component Attributes==

===Bean Name===

The bean name is specified in the "name" XML attribute.

<font color=darkgray>[[@Qualifier]] does not seem to work. Clarify.</font>

===Bean ID===

The name and ID fields both serve the same purpose, except that the ID is specified by the XML specification for IDs – no special characters.

===Bean Alias===

<syntaxhighlight lang='xml'>
<alias name=”original-name” alias=”something-else”>
</syntaxhighlight>

===Anonymous (Inner) Beans===

An anonymous bean does not have a [[#Bean_Name|name]] or an [[#Bean_ID|ID]]. Its existence is associated with the referencing bean only. Because they do not have a name, the anonymous bean are not available to the program to query them.

==Component Lifecycle==

Spring framework leans about each component definition and creates a "plan" (a [[Graph_Concepts#Directed_Acyclic_Graph|DAG]]) for how the component should be instantiated. This graph of beans, defined by the [[#Configuration_Metadata|configuration metadata]], is instantiated and placed under [[#Container|container]] management. Beans are fully initialized with their transitively also fully-initialized dependencies before being placed in the container, and a bean obtained from the container is guaranteed to be fully initialized. Beans can be obtained from the container via an <tt>ApplicationContext.getBean(...)</tt> call, or they can be injected into another component via an [[#@Autowired|@Autowired]] annotation. 

{{Warn|If a component class is instantiated with the <tt>new</tt> operator, that results in an un-managed instance that won't have its dependencies injected into it, as the container does not know about it.}}

A component's life cycle consists of:

* The framework factory loads the bean definition and instantiates the class.
* The instance is populated with the properties declared in the bean definition. If a property is a reference to another bean, the other bean will be created and populated, recursively, then its reference is injected into the bean.
* The bean instance is initialized (the code doing that is available for review in [https://github.com/spring-projects/spring-framework/blob/master/spring-beans/src/main/java/org/springframework/beans/factory/support/AbstractAutowireCapableBeanFactory.java AutowireCapableBeanFactory.java initializeBean() method]):
** If the bean implements <tt>BeanNameAware</tt> or <tt>BeanFactoryAware</tt>, the appropriate callbacks will be invoked.
** The framework invokes any <tt>BeanPostProcessor</tt> associated with the bean.
** The [[#init-method|init-metod]], if specified, is invoked on the bean.
** The post-initialization is performed.

<font color=darkgrey>Where does the constructor execution fit in here? It seems that when the constructor is executed, the dependencies are NOT present yet.</font>

==Component Instantiation==

A bean can be instantiated:
* Via reflection.
* Via static methods. 
* Via factory (non-static) methods.

==Component Initialization==

===Eager Initialization===

===Lazy Initialization===

Lazy instantiation can be configured using the [[@Lazy]] annotation. The annotation can be applied on stereotype-annotated components or on [[@Configuration]] classes.

<font color=darkgray>TO PROCESS https://www.baeldung.com/spring-lazy-annotation</font>.

==Component Destroy==

<font color=darkgray>
TODO:

<syntaxhighlight lang='java'>
((AbstractApplicationContext)applicationContext).getBeanFactory().destroySingletons();
</syntaxhighlight>
</font>

==Obtaining Components==

Aside from [[#Dependency_Injection|injection]], one way to get components from the container is to use:

<syntaxhighlight lang='java'>
BeanFactory.getBean(...)
</syntaxhighlight>

The bean can be looked up as follows:
* '''byType'''. If the type of the field is an interface, and the bean is obviously a concrete class, wiring byType still works. If more than one bean with the same type, an exception is thrown. Also see [[#Design_to_Interface|Design to Interface]] section.
* '''byName'''. The framework tries injecting the dependencies by matching bean names to the property field names. The name match has to be exact.
* '''byConstructor'''. The bean’s constructor arguments will be satisfied by searching for those types in the context.

==Component Scope==

===Singleton===

Singleton is the default scope. There is just one singleton per container.

<syntaxhighlight lang='java'>
@Component
@Scope(value = ConfigurableBeanFactory.SCOPE_SINGLETON)
public class MySingletonComponent {
...
}
</syntaxhighlight>
<syntaxhighlight lang='java'>
@Configuration
public class MyConfiguration {
  @Bean("mySingletonComponent")
  @Scope(value = ConfigurableBeanFactory.SCOPE_SINGLETON)
  public MySingletonComponent getMySingletonComponent() {
    return new MySingletonComponent();
 }
}
</syntaxhighlight>

Singletons are [[#Eager_Initialization|eagerly initialized]] by default: the application context will create and initialize all singleton instances during its initialization process. The reason behind this behavior is to detect all possible errors immediately at startup rather than at runtime.

===Prototype===

A new instance is created every time a call is made to fetch the bean instance. Prototype components are implicitly [[#Lazy_Initialization|lazily initialized]].

==Component Callbacks==

===init-method===

An init-method is a method that is called immediately after bean creation, after all the injection has been done.

The init-method can be declared in XML, as shown below, or it can be annotated with [[@PostConstruct]].

<syntaxhighlight lang='xml'>
<bean id="example" class="com.Example" init-method="init" ...>...</bean>
</syntaxhighlight>

There is also a default-init-method that is attempted to be invoked on all beans. Can be declared in XML in the <beans …> element.

It is recommended to use init-method in bean configuration file or annotations, instead of implement the InitializingBean and DisposableBean interfaces, which cause unnecessarily coupling to Spring.

===destroy-method===

A destroy-method is a method that is called right before the instance is destroyed.

The destroy-method  can be declared in XML, as shown below, or it can be annotated with [[@PreDestroy]].

<syntaxhighlight lang='xml'>
<bean id="example" class="com.Example" ... destroy-method="clean">...</bean>
</syntaxhighlight>

There is also a default-destroy-method  that is attempted to be invoked on all beans. Can be declared in XML in the <beans …> element.

It is recommended to usedestroy-method  in bean configuration file or annotations, instead of implement the InitializingBean and DisposableBean interfaces, which cause unnecessarily coupling to Spring.

=Spring Boot=

==Spring Boot Autoconfiguration==

{{Internal|Spring_Boot_Concepts#Autoconfiguration|Spring Boot Autoconfiguration}}

=Organizatorium=

* [[@Conditional]]