Projektkonfiguration mit Spring

Die Konfiguration muss umgebungsspezifisch sein - das ist nur eine Tatsache des Lebens. Wenn dies nicht der Fall wäre, wäre es keine Konfiguration und wir würden nur Werte im Code fest codieren.

For a Spring application there are several solutions you can use - von einfachen Lösungen bis hin zu überflexiblen, hochkomplexen Alternativen.

Eine der gebräuchlichsten und einfachsten Lösungen ist die flexible Verwendung vonproperties files undfirst class property support provided by Spring.

Als Proof of Concept werden wir uns für die Zwecke dieses Artikels einen bestimmten Eigenschaftstyp ansehen - die Datenbankkonfiguration. Es ist absolut sinnvoll, eine Art von Datenbankkonfiguration für die Produktion, eine andere zum Testen und eine weitere für eine Entwicklungsumgebung zu verwenden.

Beginnen wir mit unserem Proof of Concept - indem wir die Umgebungen definieren, auf die wir abzielen möchten:

Als Nächstes erstellen wir drei Eigenschaftendateien - eine für jede dieser Umgebungen:

In einer typischen Maven-Anwendung können sich diese insrc/main/resources befinden, aber wo immer sie sich befinden, müssen sieavailable on the classpath sein, wenn die Anwendung bereitgestellt wird.

Eine wichtige Nebenbemerkung -having all properties files under version control makes configuration much more transparent und reproduzierbar. Dies steht im Gegensatz dazu, dass die Configs irgendwo auf der Festplatte gespeichert sind und Spring einfach auf sie zeigt.

Im Frühjahr werden wir die richtige Datei basierend auf der Umgebung einfügen:

Das gleiche kann natürlich auch mit der Java-Konfiguration gemacht werden:

Dieser Ansatz ermöglicht die Flexibilität, mehrere*.properties-Dateien fürspecific, focused purposes zu haben. Zum Beispiel - in unserem Fall importiert die Persistenz-Spring-Konfiguration die Persistenz-Eigenschaften - was durchaus Sinn macht. Die Sicherheitskonfiguration importiert sicherheitsrelevante Eigenschaften usw.

Der endgültige, einsetzbare Kriegwill contain all properties files - für die Persistenz die drei Varianten vonpersistence-.properties. Da die Dateien tatsächlich einen anderen Namen haben, besteht keine Gefahr, dass versehentlich die falsche eingeschlossen wird. Wir setzen * die VariableenvTarget und wählen so die gewünschte Instanz aus den mehreren vorhandenen Varianten aus.

Die VariableenvTarget kann im Betriebssystem / in der Umgebung oder als Parameter für die JVM-Befehlszeile festgelegt werden:

Für Integrationstests, für die die Persistenz aktiviert werden muss, legen wir einfach die EigenschaftenvTargetin der Datei pom.xml fest:

Die entsprechendepersistence-h2_test.properties-Datei kann insrc/test/resources abgelegt werden, so dass sieonly be used for testing enthält und zur Laufzeit nicht unnötig in den Krieg aufgenommen und bereitgestellt wird.

Es gibt verschiedene Möglichkeiten, diese Lösung bei Bedarf flexibler zu gestalten.

Eine Möglichkeit besteht darin,more complex encoding for the names der Eigenschaftendateien zu verwenden und dabei nicht nur die Umgebung anzugeben, in der sie verwendet werden sollen, sondern auch weitere Informationen (z. B. den Persistenzanbieter). Beispielsweise könnten wir die folgenden Arten von Eigenschaften verwenden:persistence-h2.properties,persistence-mysql.properties oder noch genauer:persistence-dev_h2.properties,persistence-staging_mysql.properties,persistence-production_amazonRDS.properties.

Der Vorteil einer solchen Namenskonvention - und es istjust a convention, da sich am Gesamtansatz nichts ändert - ist einfach Transparenz. Es wird jetzt viel klarer, was die Konfiguration nur macht, wenn man sich die Namen ansieht:

Dieser Artikel beschreibt eine flexible Lösung für die umgebungsspezifische Konfiguration in Spring. Eine alternative Lösung mit Profilencan be found here.

Die Implementierung der Lösung kann inthe GitHub project angegeben werden - dies ist ein Maven-basiertes Projekt, daher sollte es einfach zu importieren und auszuführen sein, wie es ist.