Spring Framework 6.2 bzw. Spring Boot 3.4 bringt eine interessante Neuerung für Entwickler, die ihre Unit- und Integrationstests mit AssertJ schreiben: MockMvc Tests können nun auch mit AssertJ formuliert werden (GitHub Issue). Bisher musste für Controller-Tests mit MockMvc auf die Hamcrest-Syntax zurückgegriffen werden, was zu uneinheitlichen Test-Code führen konnte. Mit dem Release von Spring Boot 3.4 im November 2024 kann die vertraute AssertJ assertThat() API auch in Verbindung mit MockMvc verwendet werden, was das Testen von Web-Controllern eleganter und konsistenter macht. In diesem Artikel zeigen wir, welche Anpassungen am Code notwendig sind, um diese neue Möglichkeit nutzen zu können.

Dokumentation ist ein Thema, dass gerne hinten angestellt wird.
Quasi "wenn noch Zeit ist". Vergleichbar mit Tests wird Dokumentation von manchen Personen als schlecht investierte Zeit angesehen. Erschwerend kommt hinzu, dass die Pflege aufwendig ist: Wird die Software weiterentwickelt, so müssen oft auch Tests und Dokumentation nachgezogen werden.

Wir haben gute Erfahrungen damit gemacht, Dokumentation - wo möglich - zu generieren. Dabei kann sowohl der Java Quellcode als Quelle dienen, als auch Ergebnisse von automatisiert ausgeführten Tests.
Auf diese Weise kann die Dokumentation nah am Quellcode mitgepflegt werden, die Wahrscheinlichkeit sinkt, dass dies nicht bedacht oder vergessen wird.

In diesem Beitrag geht es darum, auch die Dokumentation der verwendeten Datenbankschemata zu dokumentieren. Dazu werden die Werkzeuge Testcontainers, Schemacrawler und JUnit miteinander verknüpft.

In vielen modernen Anwendungen nutzen wir Keycloak zur Authentifizierung für den Zugriff auf Spring Boot Anwendungen. Dabei werden Benutzer und ihre Rollen in Keycloak gespeichert bzw. von Keycloak bereitgestellt. In einer Spring-Anwendung möchten wir diese Rollen nun nutzen, um den Zugriff auf Ressourcen zu autorisieren. In einem weiteren Blogpost betrachten wir Fall in dem unsere Anwendung als OAuth 2.0 Client agiert und einen OAuth 2.0 Login implementiert.

Fullstack in modern - von Offlinefähigkeit bis hin zu Echtzeitanwendungen. Gemeinsam mit dem Java Magazin haben wir einen Artikelschwerpunkt entwickelt, in dem wir im Rahmen einer Beispielanwendung einige der Technologien vorstellen, mit denen wir auch in Kundenprojekten Architekturanforderungen umsetzen.

Dabei nutzen wir für die Beispielanwendung MQTT als Messagingsystem um Events bis in das browserbasierte Frontend auf Basis von Angular als ein Kommunikationsweg nutzen.

Als Sonderdruck ist der Schwerpunkt im PDF Format als Download am Ende von diesem Beitrag zu finden.

Mit Spring Security können unter anderem Webanwendungen (Spring WebMVC) auf einfache und flexible Weise abgesichert werden. Dabei ist der typische Weg über Security-Filter-Chains die Webschicht von Spring WebMVC mit Spring Security abzusichern. Doch reicht das aus?
Diese rhetorische Frage lässt sich mit vielleicht beantworten: Gibt es keine Programmierfehler oder Logikfehler, so kann das bereits ausreichen. Denn erreicht kein Request unberechtigt die Controller-Schicht, dann kann nichts passieren.

Doch in Zeiten zunehmender Cyberbedrohungen sollte keine Anwendung lediglich durch eine Schicht gesichert werden. Verteidigung in der Tiefe kann dank Spring Security leichtgewichtig mit Method Security umsetzen. Eine deutliche Verbesserung.

In unserem letzten Spring Security Training kam die Frage auf, wie sich dies mit periodischen Aufgaben innerhalb der Spring Anwendung kombinieren lässt. Das soll als Anlass dienen, sowohl periodische als auch asynchrone Ausführung, z.B. durch Message-Queue Nachrichten in Kombination mit Method Security darzustellen.

Die JAX 2024 steht vor der Tür und das Team von trion ist bereits in den Startlöchern, um Wissen und Erfahrung zu teilen. Mit einer breiten Palette von Vorträgen und einem interaktiven Night-Session-Format bietet trion Teilnehmern die Möglichkeit, sowohl in Bezug auf Technologie als auch Architektur in spannende Bereiche einzutauchen und tiefgehende Diskussionen zu führen.

Drools ist eine Rule-Engine, also ein Baustein für Expertensysteme und zur Flexibilisierung von Entscheidungen. Dabei ist Drools flexibel in bestehende JavaEE, Spring Boot und andere Frameworks integrierbar.
Dieser Beitrag beschäftigt sich mit folgender Fragestellung: Wie könnte eine Cloud-native Umsetzung von Drools im Gegensatz zu dem klassischen Modell einer Einbettung aussehen?

Cassandra ist eine noSQL Datenbank, die insbesondere im Kontext großer Datenmengen bei sehr hoher Verfügbarkeit eingesetzt wird. Dabei ist bei Cassandra entscheidend, dass das Schema passend zu den jeweils zu unterstützenden Anwendungsfällen konzipiert ist: Nur so wird die hohe Geschwindigkeit von Cassandra und die Verfügbarkeit sicher gestellt.

Doch Anforderungen können sich ändern, und damit muss auch die Anwendung angepasst werden. Das kann sich auch auf die Datenstrukturen in Cassandra auswirken.
Ein Weg, damit umzugehen, sind Cassandra Materialized Views oder ein kompletter Datenexport als CSV und Re-Import. Bei den für Cassandra typischen großen Datenmengen ist das selten praktikabel.

Unabhängig davon, um man sehr kleine Datenmengen in Cassandra vorhält, zum Beispiel zur Entwicklungszeit, oder eine spezielle Migrationsanwendung für den produktiven Einsatz mit Cassandra erstellt: Die Migrationen sollten sich einfach verwalten und in der Versionskontrolle ablegen lassen.

Cassandra 4 ist ein lang erwartetes Release der Cassandra Datenbank. Dabei hat sich nicht nur einiges in der Datenbank selbst geändert, sondern auch die Java Libraries für den Zugriff haben einige API Änderungen erfahren.
In dem Zuge sind viele andere Projekte aktuell noch nicht soweit, gute Unterstützung für Cassandra 4 zu bieten. Spring Boot bzw. Spring Data Cassandra ist jedoch bereits soweit, dass aktuelle Treiber genutzt werden. Dort stellt sich die Frage, wie das Thema Unit Test bzw. Integrationstest mit Cassandra 4 umgesetzt werden kann.

Dank der Java GraalVM in Kombination mit dem Werkzeug native-image lassen sich Java Anwendungen in nativ kompilierte Binaries überführen, die sogar statisch gelinkt sein können. Damit entfällt die Initialisierung der HotSpot VM sowie das Laden und Initialisiern von Klassen.
Eine derartig gebaute Java Anwendung lässt sich in sehr kurzer Zeit starten. Selbst mit umfangreichen Abhängigkeiten wie Thymeleaf und Spring Security kann man hier im Bereich von einer Sekunde den vollständigen Anwendungsstart erwarten.

Dazu kommt ein gut vorhersagbarer Speicherverbrauch zur Laufzeit, der zudem auch geringer ausfällt, als bei der sehr dynamischen HotSpot VM. Der Tradeoff von GraalVM-Native-Anwendungen ist, dass die Peakperformance im Vergleich zu HotSpot geringer ausfällt und Oracle zudem bestimmte Performanceoptimierungen nur in einer kommerziellen Variante anbietet.

Wie verhält sich Spring Boot mit Spring native - derzeit in Version 0.11.1 als beta - in Bezug auf den produktiven Einsatz? Worauf gilt es zu achten und was funktioniert nicht, wie man es erwartet?
Diese Aspekte werden im folgenden betrachtet.