Spring Boot — the 66 you've got wrong

Everything is enabled except shutdown; only health is exposed over HTTP

Why the two switches exist: enabled asks whether the endpoint bean is created at all; exposed asks whether a transport publishes it. An endpoint can exist and be unreachable — which is the default state of nearly all of them, and the safe default for production.

# expose more over HTTP
management.endpoints.web.exposure.include=health,info,metrics,loggers
management.endpoints.web.exposure.include=*          # everything

# disable an endpoint entirely (it stops existing)
management.endpoint.env.enabled=false

# enable the one that ships disabled
management.endpoint.shutdown.enabled=true            # still needs exposing separately!

That last line is the point of the distinction: enabling shutdown does not expose it. You need both. And include=* will expose it once enabled — which is why Actuator should sit behind Spring Security or on a separate management.server.port in production.

/actuator, over exactly two transports: HTTP and JMX

The transport rule is self-checking: every Actuator property path contains either web or jmx. If an option names any other transport — TCP/IP, ICMP, named pipes — it is invented. There is no ActuatorController class either; everything about where Actuator lives is a property, never code and never the build file.

Learn the roster well enough to spot a fake — and know the two web-only ones

Why exactly those two: JMX carries structured attributes and operations, not binary streams. heapdump returns an hprof file and logfile returns a text stream — neither fits down a JMX pipe. Everything that returns JSON, including threaddump, works over both.

Two extra facts on the roster: logfile 404s unless logging.file.name or logging.file.path is set — "provided" is not the same as "available"; and there is no /off endpoint — shutting down is /shutdown (paper #3).

shutdown is the only disabled endpoint · include=* needs the web

Read the key segment by segment. The two valid keys differ in exactly the place the two invalid ones get wrong — which is the entire question.

DOWN and OUT_OF_SERVICE both map to 503

The logic is binary, which makes it easy: is the app able to serve traffic? If yes → 200; if no → 503. OUT_OF_SERVICE means "deliberately withdrawn", which is still *not serving*, hence 503 — the same code as DOWN. UNKNOWN means "can't tell", and Actuator errs toward available → 200.

# override if you really want to
management.endpoint.health.status.http-mapping.DOWN=500
management.endpoint.health.status.http-mapping.OUT_OF_SERVICE=404

Worst wins: DOWN > OUT_OF_SERVICE > UP > UNKNOWN

The endpoint's top-level status is computed by StatusAggregator from every registered indicator. One DOWN anywhere takes the whole endpoint down — which is exactly what you want a load balancer to see.

{
  "status": "DOWN",                                    ← the aggregate: worst wins
  "components": {
    "db":        { "status": "UP" },
    "diskSpace": { "status": "UP" },
    "redis":     { "status": "DOWN" }                  ← one bad apple
  }
}

Customise the precedence with management.endpoint.health.status.order. And note the overall status is not an indicator — there is no ApplicationHealthIndicator; it's the aggregate.

Counter · Gauge · Timer · DistributionSummary

The Gauge subtlety that caught you: a gauge holds a weak reference to an object it samples. It doesn't accumulate and it doesn't push — Micrometer reads the current value when the registry is scraped. That's why gauges suit queue depth or cache size, and are wrong for counting events.

Counter c = registry.counter("orders.placed");           c.increment();
Gauge.builder("queue.depth", queue, Queue::size).register(registry);   // polled
Timer t  = registry.timer("db.query");                   t.record(() -> repo.findAll());

Two more from these questions: tags are optional, not mandatory; and Actuator does not require an external monitoring system — Prometheus/Grafana are optional integrations via a Micrometer registry.

?tag=KEY:VALUE — one =, then a :

GET /actuator/metrics                                   # list metric NAMES
GET /actuator/metrics/http.server.requests              # one metric + its available tags
GET /actuator/metrics/http.server.requests?tag=uri:/api/users&tag=status:200

It's an ordinary query parameter whose value is a colon-joined pair; repeat the parameter to AND several filters. Hitting the metric without tags is how you discover which tag keys exist.

Registered candidates, each gated by @Conditional — and it backs off, it never merges

The pipeline, end to end:

Why order matters (and why step 3 exists): conditions are evaluated against the beans registered so far, not the final context. So an auto-config running early is more likely to win its @ConditionalOnMissingBean. User beans are always registered before any auto-configuration, which is what makes back-off work at all.

And the fact that ties it together: @Profile is itself a @Conditional — @Conditional(ProfileCondition.class). So "environment-based loading" is one use of the mechanism, not its definition.

Your bean wins; the auto-configured one is simply never created

This is the single most important behaviour in Spring Boot, and it's worth stating precisely: Boot does not merge or override — it steps aside. The condition is checked, fails, and the bean definition is never registered. There is no conflict to resolve, no @Primary, no exception.

@Bean
@ConditionalOnMissingBean(CacheManager.class)
public CacheManager cacheManager() { return new ConcurrentMapCacheManager("default"); }
// user defines their own CacheManager  →  this method is never called

You've now seen the same mechanism in three guises: declaring a DataSource disables DataSourceAutoConfiguration; declaring a SecurityFilterChain disables Boot's default chain (review #7); declaring a CacheManager disables this one. Same rule every time.

Four mechanisms, and the right one depends on where you are

The test-slice row is its own trap: slices are meta-annotated with @ImportAutoConfiguration, so exclusions on your application class — and spring.autoconfigure.exclude — have no effect on them. There is no @DisableAutoConfiguration.

And the ordering annotations, from paper #8: @AutoConfigureBefore/@AutoConfigureAfter are hints, silently ignored if the referenced class is absent — which is why the name = "…" String form exists at all. Contrast @DependsOn, which orders beans and throws on a missing reference.

Two more from the bank: don't subclass Boot's auto-configuration classes (write your own conditional config instead), and auto-configuration classes should not component-scan — they declare beans explicitly so that library consumers get predictable behaviour.

Executable, bigger, nested dependencies, Main-Class + Start-Class

Why the custom launcher exists: the JDK's class loader cannot read a jar nested inside another jar. So Boot ships its own LaunchedURLClassLoader inside the archive, points Main-Class at JarLauncher, and records your real main class under the custom Start-Class header. JarLauncher builds the class loader, reads Start-Class, and invokes it.

Consequence worth knowing: a fat jar can't be put on another app's classpath with -cp, because those nested jars are invisible to a normal class loader. That's what the *-original.jar beside it is for. And a fat jar is not a shaded/uber jar — dependencies aren't merged, so signatures and META-INF/services files survive intact.

Three real ways — and in Boot you normally do nothing

The practical upshot: in a Boot app, @PreDestroy and DisposableBean callbacks fire on Ctrl-C or SIGTERM without you writing anything, because SpringApplication.run() registers the hook. In plain Spring you'd call registerShutdownHook() yourself.

Starters, auto-configuration, embedded servers, Actuator — but no code generation and no database drivers

The four embedded containers are worth memorising as a set: Tomcat (default), Jetty, Undertow for servlet stacks, and Netty for reactive (WebFlux). Switching means excluding spring-boot-starter-tomcat and adding the replacement — and note that swapping Tomcat for Jetty still gives you an embedded server. To use an external container you package a WAR and extend SpringBootServletInitializer.

Four locations, external beating packaged — and never XML

The four default locations, lowest precedence first — the rule is external beats packaged, and /config beats the directory above it:

At each location Boot loads application.{properties,yml} first, then application-{profile}.{properties,yml} for every active profile — profile-specific always beats plain at the same location.

The wider precedence chain, which is the other half of these questions:

Supported formats: .properties, .yml/.yaml, and properties-format .xml. Not .conf, not .ini, not .txt. And "XML" as a general config source is wrong — XML configures beans in legacy Spring; it is not a property source. Anything else needs a custom PropertySourceLoader.

Two properties worth distinguishing: spring.config.location replaces the search path; spring.config.additional-location adds to it. Use the second unless you really mean to lose the defaults.

Both go at class level; @PropertySource takes a file, @ConfigurationProperties takes a prefix

@Component
@ConfigurationProperties(prefix = "foo")          // a PREFIX, not a file
@PropertySource("classpath:foo.properties")       // a FILE, not a prefix
public class FooProperties {
    private String name;      // binds foo.name
    private int timeout;      // binds foo.timeout
    // getters + setters
}

Two facts that follow: @PropertySource does not support YAML, which is a stock question; and you don't need it for application.yml/application.properties at all — those are loaded by Boot's config-data machinery before any annotation is processed.

If the class isn't component-scanned, register it with @EnableConfigurationProperties(FooProperties.class) or @ConfigurationPropertiesScan. @ConfigurationProperties also gives you relaxed binding (foo.my-name, FOO_MYNAME, foo.myName all bind) and validation with @Validated — neither of which @Value offers.

Each backend has its own file — and a Spring-aware -spring variant

Why the -spring variants matter: a plain logback.xml is read by Logback before the Spring Environment exists, so <springProfile> and <springProperty> tags silently don't work. The -spring file is loaded by Boot afterwards, so they do. JUL has no Spring variant at all — it has no notion of profiles.

Switching backends means excluding spring-boot-starter-logging and adding spring-boot-starter-log4j2. Without the exclusion both SLF4J bindings are on the classpath and Logback silently wins.

Seven levels · six configurable aspects · Commons Logging internally

Invented levels to recognise: EXCEPTION, CRITICAL, VERBOSE, NOTICE. (SEVERE is real but belongs to java.util.logging, not SLF4J.)

The two-layer architecture, which is #9's question: Spring's own code logs through Commons Logging (JCL) — the API it compiles against — while Logback is the default implementation that produces output. Since Spring 5, spring-jcl reimplements the JCL API and delegates to SLF4J/Log4j2. In your code, use SLF4J.

One rotation trap: logging.logback.rollingpolicy.* is silently ignored unless logging.file.name is set — no file means no rolling appender.

META-INF/spring.factories — anything that must exist before the ApplicationContext does

The organising idea: everything registered here runs before there is a container to look things up in. That's why it's a file and not a bean — and why "regular Spring beans" is always the wrong answer.

# META-INF/spring.factories   ← root of META-INF, no sub-folder
org.springframework.boot.diagnostics.FailureAnalyzer=\
com.acme.MissingApiKeyFailureAnalyzer,\
com.acme.OtherAnalyzer

SpringFactoriesLoader scans every JAR for that exact path and merges the entries — which is how a third-party starter contributes behaviour simply by being on the classpath. Missing a trailing \ silently truncates the list.

The version change: Boot 2.7 moved auto-configuration registration only to META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports (one FQN per line, no key, no backslashes), and Boot 3 removed the legacy key entirely. Every other key stayed in spring.factories.

The base package is wherever you put the main class — there is no magic package name

@SpringBootApplication is three annotations, and the scan root comes from the class's own package:

com/example/myapp/
├── MyApplication.java      @SpringBootApplication   ← the scan root
├── web/UserController.java                          ← found
├── service/UserService.java                         ← found
└── repository/UserRepository.java                   ← found
com/other/Thing.java                                 ← NOT found (sibling package)

The same package is also registered as the auto-configuration package, which is what @EntityScan, @EnableJpaRepositories and friends fall back on when their own basePackages are absent. So the main class's location silently drives several mechanisms at once.

Two traps: putting the main class in the default package makes it scan the entire classpath (including libraries) and usually fails or crawls; and @SpringBootTest without classes walks up from the test's package looking for @SpringBootConfiguration — so a misplaced test finds the wrong config, or none.

Override with @SpringBootApplication(scanBasePackages = "…"), which adjusts both the component scan and the auto-configuration package.