Application Initializer and Listener Sorting

The framework begins by ordering implementations of ApplicationContextInitializer and ApplicationListener according to their priority or defined order. This ensures predictable behavior when several extensions modify the context.

Assembling Run Listeners

A SpringApplicationRunListener instance is created to monitor lifecycle events. The first event, starting(), is published immediately to indicate the launch phase, followed by construction of ApplicationArguments from command-line inputs.

Building and Refining the Environment

The prepareEnvironment step gathers initial property sources, which include:

• StubPropertySource for servlet config and context init parameters
• PropertiesPropertySource wrapping system properties
• SystemEnvironmentPropertySource with OS environment variables

After publishing the environmentPrepared event, additional contributors augment the property source list. The final environment typically holds:

• configurationProperties
• bootstrap map entries
• system properties and environment variables
• random value source
• springCloudClientHostInfo
• externalized configuration from bootstrap.yml

Creating the Application Context

A ConfigurableApplicationContext object is instanitated via its constructor. At this point, no beans are loaded—only the base structure exists.

Context Preparation (prepareContext)

This stage wires the environment, enhances the context, and broadcasts events. The method accepts the context, environment, listeners, arguments, and a banner instance.

1. Environment injection: context.setEnvironment(environment) binds the assembled environment.
2. Context augmentation: postProcessApplicationContext customizes the bean factory by setting:
   • beanNameGenerator for naming strategies
   • resourceLoader for file resolution
   • a type conversion service for data transformation
3. Initializer execution: All registered ApplicationContextInitializer instances are applied, allowing programmatic modification of the context.
4. Event publication: listeners.contextPrepared(context) broadcasts an ApplicationContextInitializedEvent.
5. Bean factory retrieval: The ConfigurableListableBeanFactory is obtained from the context.
6. Singleton registration: springApplicationArguments is registered as a singleton bean.
7. Configuration flags: Bean definition overriding is explicitly allowed.
8. Post-processor registration: A LazyInitializationBeanFactoryPostProcessor is added as a BeanFactoryPostProcessor.

Source Aggregation and Loading

All configured source classes are collected, with special handling for BootstrapImportSelectorConfiguration. This selector merges BootstrapConfiguration entries from spring.factories with the property spring.cloud.bootstrap.sources, sorts them, and returns the combined list as bean definitions.

The loading process dispatches based on source type. A BeanDefinitionLoader is created, configured with the bean name generator, resource loader, and environment, then executed.

The internal loader handles each source polymorphically: registering classes, scanning packages, or loading bean definitions from resources.

// Type-based loading dispatch
int loadOne(Object candidate) {
    Objects.requireNonNull(candidate, "Source must not be null");
    if (candidate instanceof Class) {
        return register((Class<?>) candidate);
    }
    if (candidate instanceof Resource) {
        return loadFromResource((Resource) candidate);
    }
    if (candidate instanceof Package) {
        return scanPackage((Package) candidate);
    }
    if (candidate instanceof CharSequence) {
        return loadFromName(candidate.toString());
    }
    throw new IllegalArgumentException("Unsupported source type: " + candidate.getClass());
}

After all sources are processed, listeners.contextLoaded(context) signals that the context preparation is complete.

Bean Definition Registry

The central registry for bean definitions is the DefaultListableBeanFactory, which manages metadata and relationships before instantiation.