Ankur Mhatre
86246dc860
configuration-properties/ @ConfigurationProperties vs @Value on Spring Boot 4.1.1. The relaxed-binding matrix is generated by binding each spelling rather than transcribed, and re-checked against real processes -- the in-process probe was wrong twice before it was right. Records the three findings that came out of it: @Value does get relaxed resolution inside Spring Boot (Boot attaches ConfigurationPropertySources), the configuration processor silently stops generating metadata on JDK 23+ when declared as a plain dependency, and @Valid is not what makes nested constraints run. profiles-and-config/ Precedence, profiles, spring.config.import and config trees. /precedence reports every source holding a property in rank order with file and line, which turns "my profile file had no effect" into a two-line answer. Also pins the counterintuitive one: an imported file outranks the file that imported it. spring-aop/ Designators, proxy types, and aspects that do not fire. One advice per supported designator so the reference table is generated from real matches; all fourteen unsupported designators fed to the parser. Two corrections to the reference documentation: unsupported designators throw UnsupportedPointcutPrimitiveException (extends RuntimeException, not IllegalArgumentException), and spring-boot-starter-aop was renamed to spring-boot-starter-aspectj in Boot 4. 19 contract tests across the three modules, 15 captured transcripts, all regenerated by scripts/run-all.sh. Verified on Spring Boot 4.1.1, Spring Framework 7.0.9, JDK 25.0.4.1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Gip4srpzMwjgoba6uEfbr5
29 lines
1.1 KiB
Bash
Executable File
29 lines
1.1 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# Stop the demo application.
|
|
#
|
|
# This uses a PID file rather than a pattern match, deliberately. `pkill -f spring-boot`
|
|
# matches the shell that is running the script and takes the terminal with it. Even a
|
|
# careful-looking `ps | grep '[c]onfiguration-properties'` matches the shell's own command
|
|
# line whenever that string appears in the command you just typed -- which it does, because
|
|
# you typed the jar name. Killing a recorded PID cannot misfire.
|
|
set -u
|
|
cd "$(dirname "$0")/.."
|
|
PIDFILE="${PIDFILE:-target/app.pid}"
|
|
|
|
if [ -f "$PIDFILE" ]; then
|
|
pid=$(cat "$PIDFILE")
|
|
# Confirm the PID is still ours before signalling it: PIDs are reused.
|
|
if [ -n "$pid" ] && grep -qa "profiles-and-config" "/proc/$pid/cmdline" 2>/dev/null; then
|
|
kill -9 "$pid" 2>/dev/null || true
|
|
fi
|
|
rm -f "$PIDFILE"
|
|
fi
|
|
|
|
# Killing the process is not the same as the socket closing, and a stale listener looks
|
|
# exactly like your configuration change having had no effect.
|
|
for _ in $(seq 1 40); do
|
|
if ! (exec 3<>/dev/tcp/127.0.0.1/"${APP_PORT:-8080}") 2>/dev/null; then break; fi
|
|
sleep 0.25
|
|
done
|
|
exec 3<&- 2>/dev/null || true
|