Du kommst von Spring Boot, hast deinen Dienst nach Quarkus übertragen, setzt im Deployment eine Umgebungsvariable — und es passiert nichts. Kein Fehler, kein Log-Eintrag, kein Hinweis. Die Anwendung startet fröhlich mit dem alten Wert.
Ein Teil der Konfiguration ist nach dem Build in Stein
Quarkus verlagert Arbeit vom Start in den Build. Das ist der Grund für die kurzen Startzeiten — und es hat eine Konsequenz, die aus der Spring-Boot-Welt niemand mitbringt: Ein Teil der Schlüssel wird zur Bauzeit ausgewertet und ist danach festgeschrieben. Wer sie zur Laufzeit ändert, ändert nichts.
In der Quarkus-Referenz tragen diese Einträge ein Schloss. Das ist kein Schmuck, sondern die Antwort auf genau diese Frage — und es lohnt sich, beim Nachschlagen eines Schlüssels kurz hinzusehen.
Aus stillem Nichts einen lauten Abbruch machen
Dafür gibt es einen Schalter:
quarkus.config.build-time-mismatch-at-runtime auf fail. Dann startet die
Anwendung nicht mehr kommentarlos mit dem falschen Wert, sondern bricht ab.
Bevor du ihn setzt, sollte allerdings die Pipeline darauf vorbereitet sein.
Verwandte Fallen aus derselben Ecke
- Ein Wert steht in zwei Profilen, und welches im Container aktiv ist, weiß niemand genau.
application-prod.propertiessticht die%prod.-Einträge — unbemerkt.- Ein Vorgabewert mit Doppelpunkt verdeckt, dass die eigentliche Quelle gar nicht greift.
Mehr dazu im Seminar
Wie sich Schlüssel, Profile und Secrets von Spring Boot nach Quarkus übertragen lassen, zeigt das Modul Konfiguration und Profile übertragen aus dem Seminar Quarkus für Spring-Boot-Teams — mit Video und Kapitelübersicht.