# evidence 249 — messaging-startup-profile-validation # revision: a24ece9cf797f7ea647e33bf846b115208ed1ba5 # cwd: /shared/codebase/clean-architecture-backend-template/src/messaging # command: sed -n "1,45p" messaging-spring-boot-starter/src/main/java/dev/caskeleton/messaging/autoconfigure/StartupProfileValidation.java; echo; echo ---StartupProfileValidation bean sites---; grep -rn "StartupProfileValidation" --include=*.java */src/main # ---- raw output ---- package dev.caskeleton.messaging.autoconfigure; import java.util.List; import java.util.Objects; import java.util.function.Consumer; import java.util.function.Supplier; import org.springframework.beans.factory.InitializingBean; /** * Applies one profile validator to every profile of its kind at startup. * *
The Kafka, RabbitMQ and security validators were all beans and none of them was injected * anywhere: the context published a validator per broker and validated nothing. A profile that * promises a guarantee its broker cannot give — an exactly-once claim on a non-transactional * producer, a quorum ack on a single replica, a plaintext credential on a production listener — * then boots cleanly and fails on the first message that depends on it, which is the wrong place to * find out. * *
Validation runs as {@code afterPropertiesSet} rather than on an application event, so the * failure happens while the context is still being built and the profile bean that caused it is * named in the stack. * *
The profiles arrive through a supplier rather than an {@code ObjectProvider} because there are
* now two sources of them — beans an application declares and profiles compiled from {@code
* app.messaging} — and a validator that saw only one of the two would leave the other half of a
* deployment's configuration unchecked. Which half went unchecked would depend on how the
* deployment happened to be written, which is the worst possible rule.
*
* @param > profiles;
private final Consumer
> profiles, Consumer
> profiles, Consumer