Ein Klassiker im Betrieb: In der application.properties steht der richtige
Wert, die Anwendung verhält sich trotzdem anders. Der Reflex ist, im Code zu
suchen. Meistens ist das verlorene Zeit.
Die Datei im Jar ist die schwächste Quelle
Spring Boot liest Konfiguration nicht aus einer Datei, sondern aus vielen
Quellen — Dateien im Dateisystem, Umgebungsvariablen, Java-Systemeigenschaften,
Kommandozeilenargumente. Diese Quellen stehen in einer festen Rangfolge, und die
application.properties im Jar ist darin die schwächste. Ein Startskript, das
ein Argument übergibt, oder eine Umgebungsvariable im Container übersteuert sie
kommentarlos.
Das ist keine Nachlässigkeit, sondern der Zweck: Ein einmal gebautes Artefakt soll in Test und Produktion unterschiedlich laufen, ohne neu gebaut zu werden.
Je spezifischer, desto stärker
Die Reihenfolge muss man sich nicht merken, wenn man das Prinzip kennt. Je näher eine Quelle am konkreten Lauf ist, desto stärker wiegt sie:
- Die Datei im Jar gilt für alle Läufe überall — am schwächsten.
- Die Umgebungsvariable gilt für diesen einen Container.
- Das Kommandozeilenargument gilt nur für diesen einen Start — am stärksten.
Der Fehler, der still bleibt
Ein Detail überrascht regelmäßig: Umgebungsvariablen schreibt man groß mit
Unterstrichen, Spring Boot übersetzt sie in Kleinschreibung mit Punkten. Wer sie
klein setzt, bekommt keine Warnung — die Variable wird schlicht ignoriert. Aus
demselben Grund lohnt ein Blick auf spring.config.location: Die Eigenschaft
ersetzt die Datei im Jar vollständig, statt sie zu ergänzen. Gemeint ist fast
immer spring.config.additional-location.
Mehr dazu im Seminar
Wie sich das mit Profilen sauber je Umgebung trennen lässt, zeigt das Modul Konfigurationsverwaltung und Profile — mit Video und Kapitelübersicht. Alle sieben Module stehen im Seminar Spring Boot 4 Grundlagen.