Last time we find that in the DefaultListableBeanFactory it provides map to save bean definitions. But when getting bean instance, we need to step into DefaultSingletonBeanRegistry. First let’s see the document:

Generic registry for shared bean instances, implementing the SingletonBeanRegistry. Allows for registering singleton instances that should be shared for all callers of the registry, to be obtained via bean name.

Also supports registration of DisposableBean instances, (which might or might not correspond to registered singletons), to be destroyed on shutdown of the registry. Dependencies between beans can be registered to enforce an appropriate shutdown order.

This class mainly serves as base class for BeanFactory implementations, factoring out the common management of singleton bean instances. Note that the ConfigurableBeanFactory interface extends the SingletonBeanRegistry interface.

Note that this class assumes neither a bean definition concept nor a specific creation process for bean instances, in contrast to AbstractBeanFactory and DefaultListableBeanFactory (which inherit from it). Can alternatively also be used as a nested helper to delegate to.

In the class, it has private variable to cache the bean instance:

/** Cache of singleton objects: bean name --> bean instance */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(256);

AbstractBeanFactory

Again AbstractBeanFactory is very important BeanFactory implementation to get beans, and it is also a SingletonBeanRegistry interface implementation to save beans.

protected <T> T doGetBean(String name,
                          Class<T> requiredType,
                          Object[] args,
                          boolean typeCheckOnly)

When ApplicationContext calls doGetBean(...), it will call getSingleton(...) which is declared in SingletonBeanRegistry interface and implements in DefaultSingletonBeanRegistry.

Return the (raw) singleton object registered under the given name. Only checks already instantiated singletons; does not return an Object for singleton bean definitions which have not been instantiated yet.

The main purpose of this method is to access manually registered singletons (see registerSingleton(java.lang.String, java.lang.Object)). Can also be used to access a singleton defined by a bean definition that already been created, in a raw fashion.

NOTE: This lookup method is not aware of FactoryBean prefixes or aliases. You need to resolve the canonical bean name first before obtaining the singleton instance.

In this method, if the bean exists in concurrent map singletonObjects<String, Object> of DefaultSingletonBeanRegistry, it will call getSingleton(...) and return the bean object; Else the bean isn’t defined, the method will also call getSingleton(...), if the singleton bean is null then it will generate the object of bean.

Create Object of Bean

How does spring create object from bean definition file? In AbstractBeanFactory, it provide an abstract bean creation method:

protected abstract Object createBean(String beanName, RootBeanDefinition mbd, Object[] args)
			throws BeanCreationException;

Also see the document:

Create a bean instance for the given merged bean definition (and arguments). The bean definition will already have been merged with the parent definition in case of a child definition.

All bean retrieval methods delegate to this method for actual bean creation.

This method is implemented in AbstractAutowireCapableBeanFactory:

Abstract bean factory superclass that implements default bean creation, with the full capabilities specified by the RootBeanDefinition class. Implements the AutowireCapableBeanFactory interface in addition to AbstractBeanFactory’s createBean(java.lang.Class<T>) method.

Provides bean creation (with constructor resolution), property population, wiring (including autowiring), and initialization. Handles runtime bean references, resolves managed collections, calls initialization methods, etc. Supports autowiring constructors, properties by name, and properties by type.

The main template method to be implemented by subclasses is AutowireCapableBeanFactory.resolveDependency(DependencyDescriptor, String, Set, TypeConverter), used for autowiring by type. In case of a factory which is capable of searching its bean definitions, matching beans will typically be implemented through such a search. For other factory styles, simplified matching algorithms can be implemented.

Note that this class does not assume or implement bean definition registry capabilities. See DefaultListableBeanFactory for an implementation of the ListableBeanFactory and BeanDefinitionRegistry interfaces, which represent the API and SPI view of such a factory, respectively.

Now we just move to createBean(...) method and its main method is doCreateBean(...):

Actually create the specified bean. Pre-creation processing has already happened at this point, e.g. checking postProcessBeforeInstantiation callbacks.

Differentiates between default bean instantiation, use of a factory method, and autowiring a constructor.

So we can know from the document that the method just create the specified bean which means it should get class reference in the definition file.

In this method, we find BeanWrapper class which is the central interface of Spring’s low-level JavaBeans infrastructure. The wrapper is initialized with createBeanInstance(...) method which can create a new instance for the specified bean, using an appropriate instantiation strategy: factory method, constructor autowiring, or simple instantiation. Then it call the core instantiation method instantiateBean(...) and it will step into InstantiationStrategy interface.

InstantiationStrategy

Interface responsible for creating instances corresponding to a root bean definition.

This is pulled out into a strategy as various approaches are possible, including using CGLIB to create subclasses on the fly to support Method Injection.

Here we just talk about its SimpleInstantiationStrategy implement class. it has instantiate(...) which can return an instance of the bean with the given name in this factory. First it get the Class<?> clazz of the bean, and call clazz.getDeclaredConstructor(...) to get the Constructor<?> of the bean, then step into BeanUtils class and call instantiateClass(...) method which can call constructor.newInstance(args) and return a new object created by calling the constructor this object represents.

Finally, the object will be saved in the singletonObjects<String, Object> for getBean(...) method to get the object.

What’s Next?

After reading the source code of Spring’s IoC, I find some TODO list.

• ThreadLocal<?>, ConcurrentMap<K, V> and volatile are often appeared in the source, so I need to deal with something about Java Threads;
• Spring Reference is very useful document to read thus I need to focus more with it.

When using Spring framework, we must use Apache Common Logging to print log in console or binary files. As we known, Spring log configuration can change in the web.xml when it works on server. But in these series of articles, we try to analyze the Spring core techniques without works on server. So there should have another way to configure log without web.xml because we want to see the debug informations.

Spring gives Log4jConfigurer.initLogging() method (has been deprecated in Spring 4.2.1) to initialize log4j from the given file location. Note that we always use Maven to build project, but maven might mash src and resources folders to one. Thus we should use classpath: ,without slash, to represent resources folder in the project.

Now Apache Commons Logging (JCL) provides thin-wrapper Log implementations for other logging tools, including Log4J. But Log4jConfigurer.initLogging() calls methods from log4j 1.x. It means that we should add log4j 1.x dependency to make sure that our log configuration file works smoothly.

Here is the configure file log4j.properties, and just opening debug function in org.springframework.beans because we want to know the IOC process:

log4j.rootCategory=INFO, stdout

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %t %c:%L - %m%n

log4j.category.org.springframework.beans=DEBUG

As last article, we run the same code but add our log configuration before:

Log4jConfigurer.initLogging("classpath:log4j.properties");
ApplicationContext context = new ClassPathXmlApplicationContext("services.xml");
PetStoreServiceImpl petStoreService = context.getBean("petStore", PetStoreServiceImpl.class);

Now we can follow the log information to know the IOC clearly.

ClassPathXmlApplicationContext

17:23:15,265  INFO main ClassPathXmlApplicationContext org.springframework.context.support.AbstractApplicationContext.prepareRefresh:581 - Refreshing org.springframework.context.support.ClassPathXmlApplicationContext@42dafa95: startup date [Fri Oct 21 17:23:15 EDT 2016]; root of context hierarchy

First we step into ClassPathXmlApplicationContext constructor and it calls refresh(). This method is declared in the interface ConfigurableApplicationContext, implements in AbstractApplicationContext, finally called in ClassPathXmlApplicationContext which is a subclass of AbstractApplicationContext.

This method can load or refresh the persistent representation of the configuration, which might an XML file, properties file, or relational database schema. As this is a startup method, it should destroy already created singletons if it fails, to avoid dangling resources. In other words, after invocation of that method, either all or no singletons at all should be instantiated.

As we see in the document, refresh() is used to load and refresh persistent representation configuration. It should be done first of all.

XmlBeanDefinitionReader

17:23:15,555  INFO main XmlBeanDefinitionReader org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions:317 - Loading XML bean definitions from class path resource [services.xml]

The refresh() method calls obtainFreshBeanFactory() in which can tell the subclass to refresh the internal bean factory. So how to let a class to call the method (in this case it is refreshBeanFactory()) in its subclass? It is a very classical design pattern.

First, the AbstractApplicationContext declares:

protected abstract void refreshBeanFactory()

This method is implemented in AbstractRefreshableApplicationContext which is a subclass of AbstractApplicationContext:

@Override
protected final void refreshBeanFactory()

Therefore the father class can call the method which implemented in its subclass.

Here is XmlBeanDefinitionReader:

Bean definition reader for XML bean definitions. Delegates the actual XML document reading to an implementation of the BeanDefinitionDocumentReader interface. Typically applied to a DefaultListableBeanFactory or a GenericApplicationContext.

This class loads a DOM document and applies the BeanDefinitionDocumentReader to it.

The document reader will register each bean definition with the given bean factory, talking to the latter’s implementation of the BeanDefinitionRegistry interface.

loadBeanDefinition() method is used to load bean definitions from the specified XML file.

DefaultDocumentLoader

XmlBeanDefinitionReader calls doLoadDocument() and it has local variable DocumentLoader documentLoader which calls loadDocument().

19:38:23,603 DEBUG main DefaultDocumentLoader org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocument:73 - Using JAXP provider [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl]

Here is DefaultDocumentLoader:

Spring’s default {@link DocumentLoader} implementation. Simply loads Document documents using the standard JAXP-configured XML parser. If you want to change the DocumentBuilder that is used to load documents, then one strategy is to define a corresponding Java system property when starting your JVM. For example, to use the Oracle DocumentBuilder, might start your application like as follows:

java -Djavax.xml.parsers.DocumentBuilderFactory=oracle.xml.jaxp.JXDocumentBuilderFactory MyMainClass

DefaultBeanDefinitionDocumentReader

Here is DefaultBeanDefinitionDocumentReader which is used to read bean definitions:

Default implementation of the BeanDefinitionDocumentReader interface that reads bean definitions according to the “spring-beans” DTD and XSD format (Spring’s default XML bean definition format).

The structure, elements, and attribute names of the required XML document are hard-coded in this class. (Of course a transform could be run if necessary to produce this format). <beans> does not need to be the root element of the XML document: this class will parse all bean definition elements in the XML file, regardless of the actual root element.

And registerBeanDefinitions(doc, readerContext):

Read bean definitions from the given DOM document and register them with the registry in the given reader context.

doc the DOM document readerContext the current context of the reader (includes the target registry and the resource being parsed)

DefaultListableBeanFactory

Default implementation of the ListableBeanFactory and BeanDefinitionRegistry interfaces: a full-fledged bean factory based on bean definition objects. Typical usage is registering all bean definitions first (possibly read from a bean definition file), before accessing beans. Bean definition lookup is therefore an inexpensive operation in a local bean definition table, operating on pre-built bean definition metadata objects.

Can be used as a standalone bean factory, or as a superclass for custom bean factories. Note that readers for specific bean definition formats are typically implemented separately rather than as bean factory subclasses: see for example PropertiesBeanDefinitionReader and XmlBeanDefinitionReader.

For an alternative implementation of the ListableBeanFactory interface, have a look at StaticListableBeanFactory, which manages existing bean instances rather than creating new ones based on bean definitions.

It implements the bean register method registerBeanDefinition() which is declared in interface BeanDefinitionRegistry.

Register a new bean definition with this registry. Must support RootBeanDefinition and ChildBeanDefinition.

Now we look at DefaultListableBeanFactory and find that it has some private variables.

/** Map of bean definition objects, keyed by bean name */
private final Map<String, BeanDefinition> beanDefinitionMap = new ConcurrentHashMap<String, BeanDefinition>(256);

/** List of bean definition names, in registration order */
private volatile List<String> beanDefinitionNames = new ArrayList<String>(256);

Note that beanDefinitionMap is a java.util.concurrent.ConcurrentHashMap and beanDefinitionNames is a volatile variable.

this.beanDefinitionMap.put(beanName, beanDefinition);
this.beanDefinitionNames.add(beanName);

TODO: java.util.concurrent.ConcurrentHashMap and volatile variable.

 // create and configure beans
ApplicationContext context =
    new ClassPathXmlApplicationContext(new String[] {"services.xml", "daos.xml"});

// retrieve configured instance
PetStoreService service = context.getBean("petStore", PetStoreService.class);

// use configured instance
List<String> userList = service.getUsernameList();

First of all, we should know the class hierarchy in org.springframework.context.support:

ClassPathXmlApplicationContext implements ApplicationContext and calls its constructor as below:

 /**
 * Create a new ClassPathXmlApplicationContext, loading the definitions
 * from the given XML file and automatically refreshing the context.
 * @param configLocation resource location
 * @throws BeansException if context creation failed
 **/
public ClassPathXmlApplicationContext(String configLocation) throws BeansException {
	this(new String[] {configLocation}, true, null);
}

Step into ClassPathXmlApplicationContext(String[], boolean, ApplicationContext)：

/**
 * Create a new ClassPathXmlApplicationContext with the given parent,
 * loading the definitions from the given XML files.
 * @param configLocations array of resource locations
 * @param refresh whether to automatically refresh the context,
 * loading all bean definitions and creating all singletons.
 * Alternatively, call refresh manually after further configuring the context.
 * @param parent the parent context
 * @throws BeansException if context creation failed
 * @see #refresh()
 **/
public ClassPathXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
		throws BeansException {

	super(parent);
	setConfigLocations(configLocations);
	if (refresh) {
		refresh();
	}
}

In this method, it first call super(parent), which is AbstractXmlApplicationContext(parent) –> AbstractRefreshableConfigApplicationContext(parent) –> AbstractRefreshableApplicationContext(parent) –> AbstractApplicationContext(parent).

Then, for the setConfigLocations(configLocations), we need move to AbstractRefreshableConfigApplicationContext, the superclass of ClassPathXmlApplicationContext. It has setConfigLocations(configLocations) that deals with the locations String and save to its private value String[] configLocations.

Now, we get to the refresh() method belong to AbstractApplicationContext that implements the method in the interface ConfigurableApplicationContext

/**
 * Load or refresh the persistent representation of the configuration,
 * which might an XML file, properties file, or relational database schema.
 * <p>As this is a startup method, it should destroy already created singletons
 * if it fails, to avoid dangling resources. In other words, after invocation
 * of that method, either all or no singletons at all should be instantiated.
 * @throws BeansException if the bean factory could not be initialized
 * @throws IllegalStateException if already initialized and multiple refresh
 * attempts are not supported
 */
 @Override
public void refresh() throws BeansException, IllegalStateException {
		synchronized (this.startupShutdownMonitor) {
		// Prepare this context for refreshing.
		prepareRefresh();

		// Tell the subclass to refresh the internal bean factory.
		ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

		// Prepare the bean factory for use in this context.
		prepareBeanFactory(beanFactory);
		// remainder...
		}
}

For this line call obtainFreshBeanFactory() that then calls refreshBeanFactory(), subclass AbstractXmlApplicationContext to refresh bean factory and load bean definitions by calling loadBeanDefinitions(beanFactory), and then it calls loadBeanDefinitions(reader), in which reader is XmlBeanDefinitionReader implements BeanDefinitionReader. This class loads a DOM document and applies the reader to it. The document reader will register each bean definition with the given bean factory, talking to the latter’s implementation of the BeanDefinitionRegistry interface.

// Tell the subclass to refresh the internal bean factory.
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

The reader has the loadBeanDefinitions(configLocations) method and the inner method of XmlBeanDefinitionReader provides a loadBeanDefinitions(encodedResource) where EncodedResource is the resource descriptor for the XML file, allowing to specify an encoding to use for parsing the file.

Method doLoadDocument(inputSource, resource) actually load bean definitions from the specified XML file. DefaultDocumentLoader that implements DocumentLoader loads a Document document from the supplied InputSource source by calling method loadDocument(InputSource, EntityResolver, ...) (that is a classical design pattern).

Further topics: InputSource of Spring Resource,ThreadLocal of Java SE concurrency, context.getBean(...) of how to get instantialization of service.