Spring 5 Framework Certification 2019

Página 1

Container, Dependency and IoC

What is dependency injection and what are the advantages?

This chapter covers the Spring Framework implementation of the Inversion of Control (IoC) [1] principle. IoC is also known as dependency injection (DI). It is a process whereby objects define their dependencies, that is, the other objects they work with, only through constructor arguments, arguments to a factory method, or properties that are set on the object instance after it is constructed or returned from a factory method. The container then injects those dependencies when it creates the bean. This process is fundamentally the inverse, hence the name Inversion of Control (IoC), of the bean itself controlling the instantiation or location of its dependencies by using direct construction of classes, or a mechanism such as the Service Locator pattern.

The org.springframework.beans and org.springframework.context packages are the basis for Spring Framework’s IoC container. The BeanFactory interface provides an advanced configuration mechanism capable of managing any type of object. ApplicationContext is a sub-interface of BeanFactory. It adds easier integration with Spring’s AOP features; message resource handling (for use in internationalization), event publication; and application-layer specific contexts such as the WebApplicationContext for use in web applications.

In short, the BeanFactory provides the configuration framework and basic functionality, and the ApplicationContext adds more enterprise-specific functionality. The ApplicationContext is a complete superset of the BeanFactory, and is used exclusively in this chapter in descriptions of Spring’s IoC container. For more information on using the BeanFactory instead of the ApplicationContext, refer to The BeanFactory.

When using the Spring framework for Java development, some of the advantages of dependency

injection are:

• Reduced coupling between the parts of an application.

• Increased cohesion of the parts of an application.

• Increased testability.

• Better design of applications when using dependency injection.

• Increased reusability.

• Increased maintainability.

• Standardizes parts of application development.

• Reduces boilerplate code.

No code needs to be written to establish relationships in domain classes. Such code or

configuration is separated into XML or Java configuration classes.

BeanFactory

The root interface for accessing a Spring bean container. This is the basic client view of a bean container; further interfaces such as ListableBeanFactory and ConfigurableBeanFactory are available for specific purposes.

This interface is implemented by objects that hold a number of bean definitions, each uniquely identified by a String name. Depending on the bean definition, the factory will return either an independent instance of a contained object (the Prototype design pattern), or a single shared instance (a superior alternative to the Singleton design pattern, in which the instance is a singleton in the scope of the factory). Which type of instance will be returned depends on the bean factory configuration: the API is the same. Since Spring 2.0, further scopes are available depending on the concrete application context (e.g. "request" and "session" scopes in a web environment).

The point of this approach is that the BeanFactory is a central registry of application components, and centralizes configuration of application components (no more do individual objects need to read properties files, for example). See chapters 4 and 11 of "Expert One-on-One J2EE Design and Development" for a discussion of the benefits of this approach.

Note that it is generally better to rely on Dependency Injection ("push" configuration) to configure application objects through setters or constructors, rather than use any form of "pull" configuration like a BeanFactory lookup. Spring's Dependency Injection functionality is implemented using this BeanFactory interface and its subinterfaces.

Normally a BeanFactory will load bean definitions stored in a configuration source (such as an XML document), and use the org.springframework.beans package to configure the beans. However, an implementation could simply return Java objects it creates as necessary directly in Java code. There are no constraints on how the definitions could be stored: LDAP, RDBMS, XML, properties file, etc. Implementations are encouraged to support references amongst beans (Dependency Injection).

In contrast to the methods in ListableBeanFactory, all of the operations in this interface will also check parent factories if this is a HierarchicalBeanFactory. If a bean is not found in this factory instance, the immediate parent factory will be asked. Beans in this factory instance are supposed to override beans of the same name in any parent factory.

Bean factory implementations should support the standard bean lifecycle interfaces as far as possible. The full set of initialization methods and their standard order is:

BeanNameAware's setBeanName

BeanClassLoaderAware's setBeanClassLoader

BeanFactoryAware's setBeanFactory

EnvironmentAware's setEnvironment

EmbeddedValueResolverAware's setEmbeddedValueResolver

ResourceLoaderAware's setResourceLoader (only applicable when running in an application context)

ApplicationEventPublisherAware's setApplicationEventPublisher (only applicable when running in an application context)

MessageSourceAware's setMessageSource (only applicable when running in an application context)

ApplicationContextAware's setApplicationContext (only applicable when running in an application context)

ServletContextAware's setServletContext (only applicable when running in a web application context)

postProcessBeforeInitialization methods of BeanPostProcessors

InitializingBean's afterPropertiesSet

a custom init-method definition

postProcessAfterInitialization methods of BeanPostProcessors

On shutdown of a bean factory, the following lifecycle methods apply:

postProcessBeforeDestruction methods of DestructionAwareBeanPostProcessors

DisposableBean's destroy

a custom destroy-method definition

ApplicationContext

Central interface to provide configuration for an application. This is read-only while the application is running, but may be reloaded if the implementation supports this.

An ApplicationContext provides:

Bean factory methods for accessing application components. Inherited from ListableBeanFactory.

The ability to load file resources in a generic fashion. Inherited from the ResourceLoader interface.

The ability to publish events to registered listeners. Inherited from the ApplicationEventPublisher interface.

The ability to resolve messages, supporting internationalization. Inherited from the MessageSource interface.

Inheritance from a parent context. Definitions in a descendant context will always take priority. This means, for example, that a single parent context can be used by an entire web application, while each servlet has its own child context that is independent of that of any other servlet.

In addition to standard BeanFactory lifecycle capabilities, ApplicationContext implementations detect and invoke ApplicationContextAware beans as well as ResourceLoaderAware, ApplicationEventPublisherAware and MessageSourceAware beans.

There can be more than one application context in a single Spring application. Multiple application

contexts can be arranged in a parent-child hierarchy where the relation is directional from child

context to parent context. Many child contexts can have one and the same parent context.

Some commonly used implementations of the ApplicationContext interface are:

AnnotationConfigApplicationContext: Standalone application context used with configuration in the form of annotated classes.

AnnotationConfigWebApplicationContext: Same as AnnotationConfigApplicationContext but for web applications.

ClassPathXmlApplicationContext: Standalone application context used with XML configuration located on the classpath of the application.

FileSystemXmlApplicationContext: Standalone application context used with XML configuration located as one or more files in the file system.

XmlWebApplicationContext: Web application context used with XML configuration.

Container

A container provides an environment in which there are a number of services made available and

that perhaps manages objects. In the case of Spring, the Spring container provides an environment

for Spring beans, managing their lifecycle and supplying the services that the ApplicationContext

provides as described in the previous section.

This is the typical life-cycle of a Spring container:

Spring container is created as the application is started.

The container reads configuration data.

Bean definitions are created from the configuration data.

Bean factory post-processors processes the bean definitions. See API documentation for the BeanFactoryPostProcessor interface for more details.

Spring beans are instantiated by the container using the bean definitions.

Spring beans are configured and assembled. Property values and dependencies are injected into the beans by the container.

Bean post-processors processes the beans in the container and any initialization callbacks are invoked on the beans. Bean post-processors are called both before and after any initialization callbacks are invoked on the bean. See API documentation for the BeanPostProcessor interface for more information.

The application runs.

Application shut down is initialized.

The Spring container is closed.

Destruction callbacks are invoked on the singleton Spring beans in the container.

In Spring, an object implementing the ApplicationContext interface is a container.