Hat man Änderungen an dem Buildskript vorgenommen, dann muss man dieses manuell Eclipse mitteilen. Dazu wird im Projekt View wird ein Gradle Projekt über Gradle –> Update Gradle manuell geupdatet. D.h. das Modell wird neu geladen und somit Änderungen an den Dependencies in Eclipse propagiert.
In den Einstellungen (Preferences –> Gradle –> Automatic Project synchronization) kann der Vorgang automatisch bei Änderungen am Buildskript angestoßen werden.
Der KDE Dateimanager Dolphin unterstützt die SplitView Ansicht. Das Fenster kann über die Funktionstaste F3 geteilt und auch wieder vereint werden.
Wird das Fenster geteilt, dann wird das aktuelle Verzeichnis dupliziert. Beim Schließen wird das aktivierte Fenster gescchlossen.
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.
Folgende Endpoints werden per default angezeigt.
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.
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
Spring Boot erreicht mit dem Release des RC1 einen weiteren wichtigen Meilenstein.
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.
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.
/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) {
// ...
}
Der Endpoint /actuator/mappings wurde komplett überarbeitet und das JSON angepasst, sodass die Context Hierachie abgebildet werden kann.
Der Endpunkt /actuator/trace wurde in /actuactor/httptrace umbenannt. Es wurden auch einige Änderungen vorgnommen, um den HTTP Request Austausch besser abzubilden (siehe).
Die Konfigurationsschlüssel wurden weiter harmoniesiert.
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.
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.
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.
Im Gradle Buildskript muss nur zur Runtime DevTools eingebunden werden.
dependencies {
runtimeOnly('org.springframework.boot:spring-boot-devtools')
}
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.
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.
Das Starten des Live-Relaod Servers kann auch gesteuert werden. Hierfür wird die Property
spring.devtools.livereload.enabled=false
genutzt.
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.
yaourt --noconfirm -S figlet figlet-fonts ascii-design
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.
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.
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.
Mit der Option hide banner in der IDE kann der Banner verbannt werden.
In der application.properties kann spring.main.banner-mode die Werte off, log, console annehmen.
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
Ist die Datei banner.png vorhanden, dann konvertiert Spring Boot dieses automatisch in AsciiArt.
Mit Spring Boot 2.0 werden auch animierte GIFs unterstützt. Diese blockieren aber die Ausführung des Programms.
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.
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