SpringApplication & Lifecycle

They are interfaces with a single run() method. Spring Boot calls every such bean once at startup, after the application context is fully built, so you can run one-off initialization code.

SpringApplication.run() bootstraps the app: it creates and configures the Spring ApplicationContext, runs auto-configuration, starts any embedded web server, and returns the running context. It's the one line called from main().

Both run once at startup. CommandLineRunner.run receives the raw String[] arguments. ApplicationRunner.run receives an ApplicationArguments object that has already parsed those strings into --option flags and plain (non-option) arguments.

Boot inspects the classpath. If Spring MVC (servlet) classes are present it picks SERVLET; if only WebFlux is present it picks REACTIVE; if no web classes are present it picks NONE. Override with setWebApplicationType() or spring.main.web-application-type.

Those events fire before the ApplicationContext and its beans exist, so a bean-based @EventListener isn't registered yet. You must register an ApplicationListener before the context is built — via SpringApplication.addListeners(), SpringApplicationBuilder.listeners(), or META-INF/spring.factories.

Extend AbstractFailureAnalyzer<YourException>, override analyze() to return a FailureAnalysis with a description and action, then register the class name in META-INF/spring.factories under the org.springframework.boot.diagnostics.FailureAnalyzer key.

A FailureAnalyzer turns a startup exception into a friendly error with a Description and an Action to fix it. Spring Boot prints these as the "APPLICATION FAILED TO START" banner instead of a raw stack trace.

Roughly: ApplicationStartingEvent, then ApplicationEnvironmentPreparedEvent, then ApplicationContextInitializedEvent, then ApplicationPreparedEvent (context refreshes here), then ApplicationStartedEvent, then ApplicationReadyEvent. On error, ApplicationFailedEvent fires instead.

FailureAnalysis holds three things: a description (what went wrong), an action (how to fix it), and the original cause. The port-in-use analyzer describes the busy port; the missing-bean analyzer names the required bean and suggests defining it.

Primary sources are the classes (or bean-definition sources) you hand to SpringApplication to seed the context — usually your one @SpringBootApplication class. Component scanning then discovers the rest of your beans from that class's package downward.

It makes every bean lazy: beans are created the first time they're needed instead of at startup. Startup gets faster, but startup-time errors and slow bean creation are deferred to first use.

SpringApplicationRunListener is the low-level hook Spring Boot calls during the run sequence (starting, environmentPrepared, contextPrepared, contextLoaded, started, ready, failed). Boot's built-in one publishes the lifecycle events. You register custom ones via META-INF/spring.factories.

Tokens shaped like --name or --name=value become 'option' arguments; everything else is a 'non-option' argument. getOptionValues(name) returns a List of that option's values, getNonOptionArgs() returns the plain tokens, and getSourceArgs() returns the raw array.

Annotate each runner with @Order(n) or implement Ordered. Lower numbers run first. Spring puts all ApplicationRunner and CommandLineRunner beans into one combined list and sorts by that value, so ordering spans both interface types.

SpringApplicationBuilder is a fluent API for configuring and launching a SpringApplication. Its distinctive feature is building a parent/child ApplicationContext hierarchy — a shared parent context whose beans are visible to isolated child contexts.

server.shutdown=graceful makes the embedded web server stop accepting new requests but finish in-flight ones before shutting down. spring.lifecycle.timeout-per-shutdown-phase (default 30s) caps how long it waits for those requests before forcing shutdown.

Before refresh you can set defaults on the SpringApplication instance: default properties, additional profiles, banner mode, web type, lazy initialization, and register ApplicationContextInitializers and ApplicationListeners. These run during the early bootstrap phases, before beans are instantiated.

Put a banner.txt file on the classpath root and Spring Boot prints it at startup. To turn it off, set spring.main.banner-mode=off in application.properties.

They run after startup has already failed — when SpringApplication catches the fatal exception and reports it, before rethrowing. Because the context is dead, you can't autowire beans; you use EnvironmentAware/BeanFactoryAware injection instead.

ApplicationFailedEvent is published when startup throws, carrying the exception and (if it got that far) the context. Because failures can occur before the context exists, listen with an early ApplicationListener registered outside the context so you can log/alert reliably.

Common causes: registered in the wrong file (the AutoConfiguration.imports file instead of spring.factories), declared as a bean, wrong factory key, generic typed to a wrapper instead of the real exception, or analyze() returning null. Also, another analyzer may match first.

The embedded web server starts during context refresh, before runners run, so requests can arrive while a runner is still working. If startup work must gate traffic, use readiness probes plus ApplicationReadyEvent (published after runners) rather than assuming a runner blocks traffic.

Graceful shutdown runs when the ApplicationContext closes — usually because a SIGTERM fires the JVM shutdown hook. The embedded server is a SmartLifecycle bean in the shutdown phase, and timeout-per-shutdown-phase caps how long that phase waits for in-flight requests.