All seven propagation values with runnable proof and transaction-manager logs, the rollback rules, and why catching an inner failure still ends in UnexpectedRollbackException. Plus six ways @Transactional is present, correct, and inert — two of which commit work the code was trying to abandon — and why Propagation.NESTED cannot be used with JpaTransactionManager at all. Spring Boot 4.1.1, JDK 25.
An aspect that does not fire produces no error and no log line. A full reference for the ten pointcut designators Spring AOP supports (generated from real matches) and the fourteen it rejects, the difference between JDK and CGLIB proxies measured side by side, and a gallery of six aspects that silently do nothing. Includes two corrections to the reference documentation. Spring Boot 4.1.1, AspectJ 1.9.25.1, JDK 25.
You set a value in application-prod.yaml, deployed with prod active, and the old value is still in effect. The reason is a single line of the documented precedence list: config data is item 3 and environment variables are item 5. A measured walk through the precedence stack, profile groups and multi-document files, config trees and Kubernetes ConfigMaps, and the spring.config.import ordering that overrides you rather than the other way round.
@Value and @ConfigurationProperties are different mechanisms, not two styles. A measured matrix of which property spellings actually resolve (including the widely repeated claim about @Value and relaxed binding, which is wrong inside Spring Boot), record constructor binding and defaults, validation, and the JDK 23 change that silently stops your IDE metadata being generated. Verified on Spring Boot 4.1.1 and JDK 25.
Spring Boot logs one startup number and hides four phases behind it. This walks through turning on the ApplicationStartup instrumentation that ships switched off, reading the step tree by self time rather than total duration — the mistake that makes people optimise a bean costing 10 ms instead of the one costing 504 — and then puts measured numbers on component scanning (0.11 ms per class inspected, whether or not it is a bean), on the silent truncation a 2048-step buffer performs on your recording, and on the JDK 25 AOT cache, which took 6.93 s to 4.82 s on the companion project without a line of application code changing.
Every Actuator endpoint on Spring Boot 4.1.1, what each one leaks, and how to secure it — measured rather than described. /actuator/env masks every value by default and heapdump is not exposed by include:"*" at all, but turn it on and it hands over 59 MB containing the credentials env just masked. Plus the three gates a request passes, a separate management port, custom indicators for a database, Kafka and an external API — and the naive Kafka health check that blocks for exactly 60.002 seconds because request.timeout.ms is not the property that bounds it.
One Spring Boot 4.1 application serving the same two operations over gRPC, RSocket and a raw WebSocket, benchmarked in a single JVM. Raw WebSocket is the fastest and has the worst tail. protobuf is 35 bytes where JSON is 83. And for a consumer that asked for a hundred messages then went quiet, the three servers produced 100, 1,208,219 and 320,255 — which is the number that decides it.
Server-Sent Events and WebSocket are compared as rivals, but one question separates them: does the client need to send anything back? A beginner-to-advanced guide with everything measured — why your dashboard silently reconnects every 30 seconds, why a dead SSE client is only discovered on the second write, why a STOMP client can publish straight to a topic and skip your controller, and why Spring's 64 KB message limit is never the one that fires.
Three brokers, three questions, one set of measurements. Ordering, replay, consumer scaling and operational footprint measured against real Kafka 4.2.1, RabbitMQ 3.10.25 and Pulsar 4.2.4 brokers, ending in a decision table where every row has a transcript behind it — including the client-side buffer that silently defeats consumer fan-out in two of the three.
Scale a Spring Boot deployment to three replicas and every @Scheduled method runs three times per tick. Measured on Boot 4.1.1 and PostgreSQL: 24 executions where 8 were due, a @SchedulerLock annotation that silently does nothing without @EnableSchedulerLock, a single scheduler thread that fires 35 of 40 executions in a burst rather than skipping them, and a node whose clock is 40 seconds fast taking a lock somebody else is holding.