GEDOPLAN

MicroProfile 4 ist releast (Aktuelle Version 4.1 vom Juli 2021). In einer lockeren Folge von Blog Posts möchte ich die Änderungen zur Vorversion darstellen.

Der letzte Post befasste sich mit MP Config (https://javaeeblog.wordpress.com/2021/08/10/microprofile-4-config/).

Nun geht es um MP Health. Auch über diese Teilspezifikation habe ich hier bereits berichtet (https://javaeeblog.wordpress.com/2019/11/05/immer-noch-gesund-aenderungen-von-microprofile-health-2-0-vs-1-0/ und https://javaeeblog.wordpress.com/2019/01/27/alles-gesund-health-checking-mit-microprofile-health/). In der nun vorliegenden Version 3 gibt es u. a. die folgenden Änderungen:

Breaking Change in HealthCheckResponse

Die JSON-Form eines HealthCheckResponse enthält das Attribut status:

GET /health/live
200 OK
{
"status": "UP",

In der Klasse hieß die Property dagegen bisher state, was zu Problemen bei der Serialisierung geführt hat. Die Property wurde in status umbenannt, was aber auch bedeutet, dass die entsprechende Methode in HealthCheckResponseBuilder nun auch so heißt.

Property für „leere“ Readiness

Mit der Config Property mp.health.default.readiness.empty.response kann eingestellt werden, welchen Status der Server während des Hochfahrens der Anwendung für den Readiness-Check liefern soll, also in dem Zeitfenster, in dem die Anwendung zwar schon teilweise läuft, aber die darin enthaltenen Checks noch nicht deployt sind. Der Default-Wert ist DOWN.

Startup Checks

Mit der Version 3.1 kommen noch Startup Checks hinzu. Sie dienen der Unterstützung der Startup Probes in Kubernetes. Der Status wird über den Endpoint health/started veröffentlicht. Custom Checks können mit dem Qualifier @Startup programmiert werden (analog zu @Liveness und @Readiness) und es gibt auch hier eine Config Property für die Antwort während der Anwendungsinitialisierung: mp.health.default.startup.empty.response.

Weitere Informationen

Wir versorgen Sie gerne mit weiterem Input:

Dirk Weil, GEDOPLAN GmbH