Read the Resource location of 3-IOC container BeanDefinition for Spring source code

Later, I will follow up the container startup process step by step according to a specific demo.

First build a Main to start the container.

public class Main {
    public static void main(String[]arg){
        ApplicationContext applicationContext = new ClassPathXmlApplicationContext("classpath:spring-context.xml");

        ((ClassPathXmlApplicationContext) applicationContext).start();
        while (true){}

Let's start debugging, step by step, and uncover its mystery.

Through a series of calls, we finally reached the following methods in ClassPathXmlApplicationContext class:

public ClassPathXmlApplicationContext(
			String[] configLocations, boolean refresh, @Nullable ApplicationContext parent)
			throws BeansException {
        // Set configuration path and other information
		if (refresh) {

Here, the key is the refresh() method. Let's look at the contents:

public void refresh() throws BeansException, IllegalStateException {
		synchronized (this.startupShutdownMonitor) {
			// Prepare this context for refreshing.

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

			// Prepare the bean factory for use in this context.

			try {
				// Allows post-processing of the bean factory in context subclasses.

				// Invoke factory processors registered as beans in the context.

				// Register bean processors that intercept bean creation.

				// Initialize message source for this context.

				// Initialize event multicaster for this context.

				// Initialize other special beans in specific context subclasses.

				// Check for listener beans and register them.

				// Instantiate all remaining (non-lazy-init) singletons.

				// Last step: publish corresponding event.

			catch (BeansException ex) {
				if (logger.isWarnEnabled()) {
					logger.warn("Exception encountered during context initialization - " +
							"cancelling refresh attempt: " + ex);

				// Destroy already created singletons to avoid dangling resources.

				// Reset 'active' flag.

				// Propagate exception to caller.
				throw ex;

			finally {
				// Reset common introspection caches in Spring's core, since we
				// might not ever need metadata for singleton beans anymore...

The refresh() method has a lot of content. Let's first look at the content that needs to be analyzed and the location of the asset. Next, we enter the obtainFreshBeanFactory method. Finally, it will enter the AbstractRefreshableApplicationContext:

protected final void refreshBeanFactory() throws BeansException {
	// If Beanfactory already exists, destroy and close	
    if (hasBeanFactory()) {
		try {
            // Create beanFactory and set some properties
			DefaultListableBeanFactory beanFactory = createBeanFactory();
            // Load BeanDefinition, which includes the location of Resource, resolution and registration of BeanDefinition
            // So we should focus on this method
			synchronized (this.beanFactoryMonitor) {
				this.beanFactory = beanFactory;
		catch (IOException ex) {
			throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex);

After entering the loadBeanDefinitions method, we find the following code snippet in the abstractxmlapplicationcontext:

protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
		// Create a new XmlBeanDefinitionReader for the given BeanFactory.
        // Create a beanDefinitionReader class for the beanFactory built in the previous step, and the subsequent loading of BeanDefinition is completed by this class
		XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);

		// Configure the bean definition reader with this context's
		// resource loading environment.
		beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));

		// Allow a subclass to provide custom initialization of the reader,
		// then proceed with actually loading the bean definitions.
        //Load BeanDefinitions through beanDefinitonReader

Continue to follow up, we found that there is a specific loading process in AbstractBeanDefinitionReader:

public int loadBeanDefinitions(String location, @Nullable Set<Resource> actualResources) throws BeanDefinitionStoreException {
		ResourceLoader resourceLoader = getResourceLoader();
		if (resourceLoader == null) {
			throw new BeanDefinitionStoreException(
					"Cannot load bean definitions from location [" + location + "]: no ResourceLoader available");

		if (resourceLoader instanceof ResourcePatternResolver) {
			// Resource pattern matching available.
			try {
                // Get the Resource, and finally find out the key point of our section, Resource positioning Let's go in and see how it loads
				Resource[] resources = ((ResourcePatternResolver) resourceLoader).getResources(location);
				int count = loadBeanDefinitions(resources);
				if (actualResources != null) {
					Collections.addAll(actualResources, resources);
				if (logger.isTraceEnabled()) {
					logger.trace("Loaded " + count + " bean definitions from location pattern [" + location + "]");
				return count;
			catch (IOException ex) {
				throw new BeanDefinitionStoreException(
						"Could not resolve bean definition resource pattern [" + location + "]", ex);
		else {
			// Can only load single resources by absolute URL.
			Resource resource = resourceLoader.getResource(location);
			int count = loadBeanDefinitions(resource);
			if (actualResources != null) {
			if (logger.isTraceEnabled()) {
				logger.trace("Loaded " + count + " bean definitions from location [" + location + "]");
			return count;

After that, we went to the following in the DefaultResourceLoader class:

public Resource getResource(String location) {
		Assert.notNull(location, "Location must not be null");

		for (ProtocolResolver protocolResolver : this.protocolResolvers) {
			Resource resource = protocolResolver.resolve(location, this);
			if (resource != null) {
				return resource;

		if (location.startsWith("/")) {
			return getResourceByPath(location);
		else if (location.startsWith(CLASSPATH_URL_PREFIX)) {
            // When processing the Resource with classpath representation, our Demo will take this branch and return this Resource
			return new ClassPathResource(location.substring(CLASSPATH_URL_PREFIX.length()), getClassLoader());
		else {
			try {
				// Try to parse the location as a URL...
                // Resource handling URL identity
				URL url = new URL(location);
				return (ResourceUtils.isFileURL(url) ? new FileUrlResource(url) : new UrlResource(url));
			catch (MalformedURLException ex) {
				// No URL -> resolve as resource path.
				return getResourceByPath(location);

Since then, the Resource positioning process has been completed In a word, in the process of container startup, find the corresponding Resource according to the path configured by the user. The following is the specific call chain diagram implemented in Spring.

Next, the data in the resource file will be read and the bean definition will be loaded.

Tags: Spring xml

Posted on Sun, 10 Nov 2019 14:08:00 -0500 by mikemike