GEDOPLAN
Cloud ComputingJakarta EE (Java EE)Spring

MicroProfile 4: Config

Cloud ComputingJakarta EE (Java EE)Spring

Seit den vergangenen Posts zum Thema MicroProfile ist einiges passiert. MicroProfile 4 ist releast (Aktuelle Version 4.1 vom Juli 2021). Das umfasst auch MP Config 2.0 mit einigen Änderungen zu damals beschriebenen Version 1.4.

Die Grundlagen aus Welche Einstellung haben Sie? Anwendungskonfiguration mit MicroProfile Config sind natürlich immer noch gültig. Zwei neue Features möchte ich im Folgenden kurz beschreiben.

Configuration Profiles

In verschiedenen Stages haben Anwendungen i. A. unterschiedliche Einstellungen. MP Config bietet dazu Configuration Profiles an, von denen eines mit der Property mp.config.profile aktiviert werden kann. Die davon betroffenen Config Properties können entweder mit einem Präfix benannt werden (z. B. %dev.database) oder in separaten Properties-Dateien eingetragen werden (z. B. META-INF/microprofile-config-test.properties).

Nehmen wir an, wir hätten diese beiden Konfigurationsdateien:

# META-INF/microprofile-config.properties
database: postgres
%dev.database: h2
# META-INF/microprofile-config-test.properties
database: derby

Dazu denken wir uns noch eine Variable, die per Injektion den Konfigurationswert namens database zugewiesen bekommt:

@Inject
@ConfigProperty(name = "database")
String database;

Normalerweise wäre der Wert nun postgres, im Profil dev jedoch h2 und im Profil test derby. Das Profil kann bspw. beim Start der Anwendung durch Angabe der System Property mp.config.profile ausgewählt werden:

java -Dmp.config.profile=test -jar …

Property Expressions

In den Konfigurationdateien META-INF/microprofile-config[-profile].properties
dürfen nun Properties im Wert einer anderen Property verwendet werden, und zwar mehrfach, eingeschachtelt oder auch mit Default-Wert. Auch dazu ein kleines Beispiel:

META-INF/microprofile-config.properties
server.url=http://${server.host:example.org}:${server.port}/${server.endpoint}
server.port=8080
server.endpoint=${server.endpoint.path.${server.endpoint.name:foo}}
server.endpoint.path.foo=api/foo
server.endpoint.path.bar=api/bar

Unter der Annahme, dass keine der aufgeführten Properties durch andere Config Sources mit Werten belegt wird, hätte die Property server.url den Wert http://example.org:8080/api/foo.

Weitere Informationen

Wir versorgen Sie gerne mit weiterem Input:

Dirk Weil, GEDOPLAN GmbH

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Bitte füllen Sie dieses Feld aus.
Bitte füllen Sie dieses Feld aus.
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren.

Autor

Diesen Artikel teilen

LinkedIn
Xing

Gibt es noch Fragen?

Fragen beantworten wir sehr gerne! Schreibe uns einfach per Kontaktformular.

Kurse

weitere Blogbeiträge

automobile 8078415 640 jpg
Webprogrammierung

OpenAPI- ein eigenes Model

OpenAPI ist eine fantastische Möglichkeit, die eigenen Schnittstellen technisch zu beschreiben und Anwendungsteile zu generieren. Ein Generator ist allerdings immer…

Work Life Balance. Jobs bei Gedoplan

We are looking for you!

Lust bei GEDOPLAN mitzuarbeiten? Wir suchen immer Verstärkung – egal ob Entwickler, Dozent, Trainerberater oder für unser IT-Marketing! Schau doch einfach mal auf unsere Jobseiten! Wir freuen uns auf Dich!

Work Life Balance. Jobs bei Gedoplan

We are looking for you!

Lust bei GEDOPLAN mitzuarbeiten? Wir suchen immer Verstärkung – egal ob Entwickler, Dozent, Trainerberater oder für unser IT-Marketing! Schau doch einfach mal auf unsere Jobseiten! Wir freuen uns auf Dich!