Actuator stellt diverse Metriken der Anwendung zur Verfügung. Waren die Endpoints vor Spring Boot 2.0 im Wurzelverzeichnis eingehangen, so werden diese nun zentral unterhalb des Prefixes /actuator bereitgestellt. Dieses verhindert Kollisionen mit der Anwendung.

Neu ist das per default nicht alles angezeigt wird. Das verhindert das versehendlich unnötig viele Details der Anwendung exposed werden.

Standard Metriken

Folgende Endpoints werden per default angezeigt.

  • /actuator
  • /actuator/health
  • /actuator/info

Security

Weitere Endpoints können über eine Property (z.B. application.properties) exposed werden. Welche Endpoints exposed werden, wird über den management.endpoints.web.expose Wert gesteuert.

management.endpoints.web.expose=*

Stellt alle Endpoints unter /actuator zur Verfügung.

Conditions

Unter /conditions stellt actuator alle Konditionen zur Verfügung. Über diese Konditionen kann man Rückschlüsse ziehen warum sich Spring so verhält. Es werden alle AutoConfigure Optionen angezeigt.

/actuator/configuration

ConfigProps

Spring Boot erreicht mit dem Release des RC1 einen weiteren wichtigen Meilenstein.

Spring Boot 2.0.0.RC1

Portierung auf 2.0

Wenn eine Anwendung von einem älteren Releasestand auf 2.0.0 portiert werden soll, so haben sich wahrscheinlich einige der Properties geändert. D.h. sie sind zum Beispiel entfallen oder wurden durch andere ersetzt. Ja alle Änderungen sind in den Milestones dokumentiert oder man kann den Migrationcheck verwenden, aber trotzdem wird es vorkommen nicht alles berücksichtig wird.

Abhilfe schafft das neue Modul deprecated properties support.

org.springframework.boot:spring-boot-deprecated-properties-support

Wird dieses als Abhängikeit in den Classpath mit aufgenommen, so kann es teileweise Ersetzungen vornehmen und veraltete Properties in dem Log ausgeben.

Änderungen PatternMatching bei RequestMappings

Eine Anfrage „GET /projects/spring-boot.json“ wird nicht mehr automatisch auf @GetMapping(„/projects/spring-boot“) gemappt, da es in der Vergangenheit oft Probleme mit der Zuordnung gegeben hat und es dadurch ggf. Sicherheitslücken auftreten können. Aus diesem Grunde wurde im RC1 das Feature abgeschaltet und darauf verwiesen den Best Practiceses zu folgen.

Beispiel

/pets.json

@GetMapping(path = "/pets/{petId}", produces = "application/json;charset=UTF-8")
@ResponseBody
public Pet getPet(@PathVariable String petId) {
// ...
}

@PostMapping(path = "/pets", consumes = "application/json")
public void addPet(@RequestBody Pet pet) {
// ...
}

Actuator

Actuator mappings

Der Endpoint /actuator/mappings wurde komplett überarbeitet und das JSON angepasst, sodass die Context Hierachie abgebildet werden kann.

Endpunkt /actuator/trace wurde umbenannt

Der Endpunkt /actuator/trace wurde in /actuactor/httptrace umbenannt. Es wurden auch einige Änderungen vorgnommen, um den HTTP Request Austausch besser abzubilden (siehe).

Konfiguration

Die Konfigurationsschlüssel wurden weiter harmoniesiert.

  • spring.banner
  • spring.metrics –> management.metrics

Ab dem Milestone 2.0.0.M7 ist es möglich sämtliche Durations aus dem JSR 310 anzugeben. Das Properties die vorher eine Angabe is Sekunden oder sogar in Millisekunden benötigten, können jetzt Werte wie z.B.

  • 2d
  • 1w

enthalten. Spring Boot konvertiert diese intern, so dass hier keine Umrechnung mehr stattfinden muss.

Die Konfiguration von

server.session.cookie.max-age=2d

ist somit valide.

Spring DevTools

LiveReload ist ein kleines Plugin für den Browser welches über Änderungen an dem Quelltext mitgeteilt bekommt und dafür sorgt, dass die Seite neu im Browser geladen wird. Somit lassen sich Änderungen der Seite sofort erkennen und verkürzt die turn-around Zeiten.

LiveReload benötigt einen Server welcher über ein einfaches Protokoll dem Plugin Änderungen anzeigt. Fügt man die Devtools als Dependency in dem Spring Projekt ein, so wird dieser automatisch beim Starten der Application gestartet. Es ist keine weitere Konfiguration nötig.

Installation des Browser Plugins

Plugin Chrome Plugin Firefox

Spring Dependency

Im Gradle Buildskript muss nur zur Runtime DevTools eingebunden werden.

dependencies {
    runtimeOnly('org.springframework.boot:spring-boot-devtools')
}

Sinnvolle Properties werden automatisch gesetzt

Wenn DevTools geladen werden, dann werden auch gleich einige Properties automatisch angepasst. Dieses geschied in der Klasse https://github.com/spring-projects/spring-boot/blob/v2.0.6.RELEASE/spring-boot-project/spring-boot-devtools/src/main/java/org/springframework/boot/devtools/env/DevToolsPropertyDefaultsPostProcessor.java. Die Klasse implementiert einen EnvironmentPostProcessor. Hier wird über die @Order Annotation die niedrigste Ordered.LOWEST_PRECEDENCE gewählt, so dass die Properties Vorrang haben und andere Defaultwerte überschreiben.

spring.thymeleaf.cache=false
spring.freemarker.cache=false
spring.groovy.template.cache=false
spring.mustache.cache=false
server.servlet.session.persistent=true
spring.h2.console.enabled=true
spring.resources.cache.period=0
spring.resources.chain.cache=false
spring.template.provider.cache=false
spring.mvc.log-resolved-exception=true
server.servlet.jsp.init-parameters.development=true
spring.reactor.stacktrace-mode.enabled=true

Das heißt für die oben gelisteten sinnvollen Properties muss man keine gesonderte Properties Datei anlegen, die nur in der Entwicklungsumgebung eingebunden wird.

DevTools remote benutzen

Per Default kann man die DevTools nicht remote verwenden. Die DevTools sollten auch nicht in Produktiv Umgebungen genutzt werden, aber es kann hilfreich sein sie in PreProduction Environments zur Fehlersuche zu nutzen.

bootWar {
    excludeDevtools = false
}   

Siehe Beschreibung [https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/html/#packaging-executable-configuring-excluding-devtools](Excluding DevTools in Packaging).

Zusätzlich lässt sich über

spring.devtools.remote.secret=meingeheimnis

ein Passwort setzen.

Disable Live-Reload Server

Das Starten des Live-Relaod Servers kann auch gesteuert werden. Hierfür wird die Property

spring.devtools.livereload.enabled=false

genutzt.

Kommerzielle Variante

JRebel von zerroturnaround kann nicht nur die Änderungen am Quelltext deployen, sondern zusätzlich auch z.B. externe Jars, die als Abhängigkeiten vom Projekt eingefügt sind. Diese Funktionalität bietet das Duo nicht, dafür ist es eine einfache und kostenlose Alternative.

Ascii Art sind auch heute noch nett anzusehen. Auch in der Dokumentation im Quelltext oder der Banner von Spring Boot werden sie noch verwendet.

Installation unter Arch Linux

yaourt --noconfirm -S figlet figlet-fonts ascii-design

Fonts Pfad anpassen

Die Fonts für figlet befinden sich unterhalb des Verzeichnisses /usr/share/figlet/fonts/. Dieses muss beim ersten Start der Anwendung Ascii Design angegeben werden.

Font

Für Quelltexte finde ich den Font Banner3 cool.

Damit Systemd Änderungen in den Unitfiles erkennt (z.B. durch Programmupdate), müssen diese mit dem Befehl

systemctl daemon-reload

dem System bekannt gemacht werden. Arch Linux besitz seit geraumer Zeit die Möglichkeit Hooks in Pacman zu integrieren. Hooks ermögichen Aktionen bei eintreten eines Events durchzuführen. Hier also wenn eine Änderung an den Unitfiles von Systemd durchgeführt wird.

Dieses Funktionalität wird von dem Paket systemd-daemon-reload-hook bereitgestellt.

Installation

yaourt -S systemd-daemon-reload-hook

Nach pacman -Syu

:: Running post-transaction hooks...
(1/2) Reloading Systemd Daemon...

Jetzt wird die Konfiguration von Systemd automatisch neu geladen, wenn sich Änderungen ergeben.

Der Banner ist das Ascii GFX Logo mit Informationen welches beim Start von Spring Boot auf der Konsole ausgegeben wird.

Abschalten

Mit der Option hide banner in der IDE kann der Banner verbannt werden.

Anpassen des Banner

In der application.properties kann spring.main.banner-mode die Werte off, log, console annehmen.

  • off –> keine Ausgabe
  • log –> Ausgabe in den Logger
  • console –> (default) Ausgabe auf der Konsole

Logo und Informationen anpassen

Ab Spring Boot 1.4 kann über die Testdatei banner.txt das Aussehen des Banners angepasst werden. Hierzu muss die Datei nur vorhanden sein, dann wird sie automatisch von Spring verwendet. Die Grafiken können mit einem beliebigen AsciiArt Generator erstellt werden.

In der AsciiArt lassen sich auch ColorCode verwenden, so dass sich das Logo auch farblich gestalten lässt. Die Angabe des ColorCode erfolgt nach dem Schema:

${AnsiColor.RED}

Die AsciiArt kann z.B. auch aus einem vorhandenen Bild erzeugt werden. AsciiArt Generator

PNG als Logo

Ist die Datei banner.png vorhanden, dann konvertiert Spring Boot dieses automatisch in AsciiArt.

Animierte GIFs

Mit Spring Boot 2.0 werden auch animierte GIFs unterstützt. Diese blockieren aber die Ausführung des Programms.

Allgemein

KDEConnect ist eine zweiteilige Anwendung. Sie besteht aus einer Desktop (KDE) Komponente und einer Android App. Diese kann über den Play Store installiert werden. Sind 2 Geräte miteinander gekoppelt, dann können Nachtrichten angezeigt, per copy & paste Texte kopiert, Dateien ausgetauscht, Dateisysteme gemounten werden und vieles mehr.

Dateiübetragung

Damit die Dateiübertraung zwischen 2 Geräten funktioniert, so muss sshfs installiert sein. Sonst schlägt KDE beim Mounten des Gerätes fehl.

pacman -S sshfs

Die Modularisierung und die damit tief eingreifenden Änderungen in das Java System führen dazu das nicht alle Java Programme auf anhieb unter Java 9 einwandfrei laufen. Unter Archlinux ist eine Paralellinstallation von verschiedenen Java Versionen gleichzeit möglich.

Installation Java 9

pacman -S jdk9-openjdk

Verwaltung der Java Versionen

Die verschiedenen Versionen verwaltet Arch Linux über eine kleines Skript (/usr/bin/archlinux-java). Die aktuell vorhandenen Versionen und aktivierte Version kann man über status anzeigen lassen.

[sascha@Laptop ~]$ archlinux-java status
Available Java environments:
java-8-jdk (default)
java-9-jdk
java-9-openjdk

Das Skript passt die Links /usr/lib/jvm/default und /usr/lib/jvm/default-runtime. Die Links sollten nur über das Hilfsskript aktualisiert werden.

Programme mit einer anderen Java Version starten

Programme die nur mit einer bestimmten Version starten können weiterhin mit Hilfe der Umgebungsvariablen gestartet werden. Hierzu kann wiederum ein kleines Skript genutzt werden.

#!/bin/sh
export PATH=/usr/lib/jvm/java-8-openjdk/jre/bin/:$PATH
exec "$@"

Auruf mit ~/bin/jre8 Pfad_zur_Anwendung Parameter