Im heutigen Blog-Beitrag möchte ich gerne mit der Frage starten, warum wir in den meisten neuen Projekten, in denen eine Weboberfläche entwickelt werden soll, zunächst an die verschiedenen Javascript-Frameworks denken? Sollte ich als gestandener Java-Entwickler nicht eine Lösung in meinem Ökosystem bevorzugen?

Sicherlich spielen in den meisten Architekturentscheidungen nicht nur solche Überlegungen eine Rolle. Dennoch möchte ich zeigen, wie man mit aktuellen Enterprise-Frameworks (Quarkus), ansehnliche Weboberflächen mit Jakarta Faces und Primefaces erstellen kann.

Wir starten mit einer einfachen Quarkus-Anwendung. Die einzige Abhängigkeit, die ich zusätzlich benötige, ist die Primefaces-Extension aus dem Quarkiverse.

Mit dieser Abhängigkeit kommt ebenfalls eine Jakarta Faces Implementierung mit in unser Projekt. In diesem Fall die Apache MyFaces Implementierung in der Version 4.1.1. Sie beinhaltet also den Standard 4.1 der Faces Spezifikation und ist damit kompatibel zu JakartaEE 11.

Eine weitere Konfiguration der Anwendung ist nicht notwendig. Primefaces verwendet eine automatische Konfiguration der Webanwendung, daher ist keine web.xml notwendig aber selbstverständlich für weitere Konfigurationen erlaubt. Diese Datei wird wie üblich im META-INF-Verzeichnis untergebracht. Quarkus verwendet standardmäßig das resources-Verzeichnis unterhalb vom META-INF-Verzeichnis für die Auslieferung der „statischen“ Inhalte. Wir können in diesem auch unsere xhtml-Dateien für die Faces-Anwendung ablegen.

Mit diesem minimalen Aufwand haben wir eine lauffähige Webanwendung mit Jakarta Faces erstellt. Damit wir das Ganze jetzt auch noch mit etwas Leben füllen können, erstellen wir eine Entität und einen Service.

Wir stellen uns vor, dass hinter dem Service auch noch eine Repository-Klasse stecken kann und diese die Daten aus der Datenbank für uns verwaltet. Für uns reicht diese Tiefe für das einfache Beispiel aus.

Um nun die Verbindung zur Webansicht zu schließen erstellen wir noch eine weitere Klasse.

Mit der zusätzlichen Annotation @Named machen wir den Presenter unter dem Namen trainingPresenter bekannt. Damit haben wir nun die Möglichkeit die Daten in der xhtml-Datei zu verwenden.

Dieses einfache Beispiel zeigt, dass man auch ohne den Einsatz eines Javascript-Frameworks Webanwendungen mit JakartaEE erstellen kann. Der Vorteil von diesem Ansatz ist, dass auch Java-Entwickler ohne Javascript Know-How Webanwendungen erstellen können. Darüber hinaus entfällt die Umwandlung der Daten in Json und die Übertragung zum Client in dieser Form. Die Darstellung wird auf dem Server gerendert und direkt ausgeliefert.

Für diejenigen, die schon lange im Enterprise-Umfeld unterwegs sind, waren die meisten Dinge bekannt. Dennoch gibt es häufig viele Bedenken gegen diesen Ansatz. In diesem Beitrag haben wir uns ein einfaches Beispiel angeschaut. In einem späteren Beitrag werde ich dann den Vergleich zu Angular machen. Dazu werden wir uns dann genauer Anschauen, wo die Vor- und Nachteile der beiden Frontend-Technologien liegen.

Testen von Enterprise-Anwendungen ist i. A. eine schwierige Angelegenheit, hat man es doch mit komplexen Anwendungen zu tun, die im Kern auf einem Injektionscontainer basieren. Man muss also entweder die zu testenden Anwendungskomponenten ohne Injektionscontainer selbst konstruieren und alle Dependencies mit Mock-Objekten versorgen oder die Anwendung im Injektionscontainer testen.

Im Test möchte man i. A. nicht mit externen Systemen arbeiten, sondern stattdessen bspw. passend vorbereitete Testdaten verwenden. Wir müssen somit Datenbanken oder REST-Api-Server „mocken“, also durch eine Testimplementierung ersetzen. Das kann in Quarkus-Tests sehr elegant mit CDI Alternatives geschehen. Dazu schreibt man eine zum zu ersetzenden Produktivservice kompatible Klasse im Test Classpath und annotiert sie mit @Alternative:

Die Mock-Klasse muss für den Test noch aktiviert werden. Das könnte mit @Priority geschehen, was dann aber für jeden Testfall Gültigkeit hätte. Für eine dedizierte Steuerung bietet Quarkus sog. Test Profiles an. In ihnen können (u. a.) CDI Alternatives aktiviert werden:

Annotiert man nun noch die Testklasse mit @TestProfile, wird die zu testende Anwendung mit der aktivierten Mock-Klasse hochgefahren:

Quarkus bietet noch viele weitere Features für die Unterstützung von Tests an, z. B. zusätzliche Mocking-Möglichkeiten, Dev Services oder Continuous Testing.

Wenn Sie Quarkus genauso begeistert wie mich (wovon ich mal ausgehe), dann kommen Sie doch mal zu unseren Vorträgen und Seminaren dazu!

Im Java Ökosystem haben wir bereits die Wahl zwischen unterschiedlichen Templating Engines von beispielsweise JSP über Thymeleaf bis zu FreeMarker. Wieso also eine weitere Option dazuholen? Wir schauen uns die Vorteile von Qute in einem kleinen Beispielprojekt an um genau das herauszufinden.

Die Bibliothek Qute ist spezifisch für die Anforderungen von Quarkus entwickelt worden und kann dort neben dem Templating für Webseiten auch z.B. in der Mailer-Erweiterung oder andere Templating Aufgaben verwendet werden. Dabei führt Qute möglichst viele Schritte bereits zur Build Zeit durch um zur Laufzeit Ladezeiten zu verringern und Fehler frühzeitig zu erkennen. Damit eignet sich Qute auch gut für nativ kompilierte Anwendungen. Die Validierung und Verarbeitung der Templates zur Build Zeit deckt Syntax- und Typfehler zuverlässig und frühzeitig auf und verringert die Zeit für manuelles Testen und Debuggen. Die Bibliothek unterstützt wahlweise ein reaktives Paradigma und bietet eine sehr gute Integration in den Quarkus Dev-Modus. Über die Quarkus IDE Tools werden Probleme auch bereits beim Entwickeln markiert und Vorschläge werden für bekannte Typen unterstützt.

Für unsere Beispielanwendung erstellen wir eine kleine Verwaltung der Planeten unseres Sonnensystems. Die Web-Schnittstelle realisieren wir mit Jakarta REST, dafür können wir folgende Maven-Dependency verwenden.

Qute Templates erstellen

Zunächst brauchen wir dann ein Template für eine Übersichtsseite. Templates werden für die quarkus-rest-qute Integration überlicherweise im Verzeichnis src/main/resources/templates und möglichen Unterverzeichnissen angelegt. Für die typensichere Integration ist standardmäßig vorgesehen, dass Templates die in der Klasse PlanetResource verwendet werden in einem Unterordner mit demselben Namen liegen. Qute-Ausdrücke werden durch geschweifte Klammern eingeleitet und geschlossen. Eine Dokumentation der verschiedenen Möglichkeiten gibt es hier. In unserem Beispiel verwenden wir diese Arten von Ausdrücken.

• Einfache Ausdrücke: {planet.name}
• Ternäre Ausdrücke: {planet.hasRings ? 'Ja' : 'Nein'}
• Schleifen: {#for planet in planets} und {/for}
• Bedingte Bereiche: {#if planets.isEmpty()} und {/if}
• Direkter Zugriff auf benannte CDI-Beans: {cdi:vertxRequest.getParam('search', '')}
• Automatisches Einbinden von CSS/JS Resourcen mit quarkus-web-bundler: {#bundle /}

Hier sind die entsprechenden Zeilen auch noch einmal im Kontext markiert.

^{src/main/resources/templates/PlanetResource/planets.html}

Qute Templates verwenden

Sobald wir das Template fertiggestellt haben können wir uns dem Rendern der Seite zuwenden. Die Jakarta REST Methoden müssen dafür ein Objekt vom Typ TemplateInstance zurückgeben. Um Templates typensicher zu definieren gibt es mit Qute zwei Möglichkeiten. Die erste Möglichkeit ist es die Templates über public static native Methoden innerhalb einer statischen Klasse mit der Annotation @CheckedTemplate zu referenzieren. Die Methode planets referenziert standardmäßig dann die Template Datei src/main/resources/templates/PlanetResource/planets.html. In den Methoden Parametern können die für das Rendern notwendigen Daten mit dem Parameternamen als Key definiert werden. Über diesen Namen können wir diese Daten im Template verwenden. Aufgrund des native Keywords müssen wir keine Implementierung vornehmen und können die Methode einfach verwenden um unsere TemplateInstance zu erstellen. Die Implementierung übernimmt Qute für uns.

^{src/main/java/de/gedoplan/showcase/web/PlanetResource.java}

Probleme mit dem Schlüsselnamen oder einem Methodennamen fallen bereits zur Compilezeit auf und der Vorgang wird abgebrochen. Läuft die Anwendung zu diesem Zeitpunkt bereits im Dev-Modus wird nach einem Reload im Dev-Modus direkt auf die Stelle im Template verwiesen, die für den Fehler verantwortlich ist.

Eine andere Möglichkeit Templates zu referenzieren funktioniert über Records. Für das Template PlanetForm.html definieren wir einen Record PlanetForm um neue Planeten anzulegen oder bestehende zu bearbeiten. Der Record muss das Interface TemplateInstance implementieren um Qute zu signalisieren, dass es sich hierbei um eine Templatereferenz handelt, und um einen validen Rückgabewert in den Methoden darzustellen.

^{src/main/java/de/gedoplan/showcase/web/PlanetResource.java}

Hier kommen wir ohne das Keyword native aus. Wichtig ist es hier auf Groß- und Kleinschreibung zu achten und wenn wir z.B. das Template Planet.html verwenden möchten würde die Record Definition sich standardmäßig mit dem Namen der Model-Klasse Planet überschneiden. Hier müssten wir entweder einen voll qualifizierten Namen verwenden, den Klassen- oder Dateinamen anpassen oder die Standardeinstellungen mit der Annotation @CheckedTemplate anpassen.

Mit der Annotation @TemplateData an der beim Rendern verwendeten Klasse Planet können wir Qute anweisen einen sogenannten Resolver zu generieren um einen Zugriff über Reflection zur Laufzeit zu vermeiden. Für Enumerations gibt es die Annotation @TemplateEnum, die es uns auch erlaubt im Template auf die Enum-Konstanten zuzugreifen.

^{src/main/java/de/gedoplan/showcase/model/Planet.java}

^{src/main/java/de/gedoplan/showcase/web/PlanetResource.java}

Methodenerweiterungen für Datenobjekte

Manchmal wäre es hilfreich, wenn wir bestehende Java-Klassen um neue Methoden erweitern könnten, wie man es z.B. aus Kotlin kennt. Zumindest für die Datenobjekte, die wir in den Templates verwenden, können wir mit Qute solche Methoden definieren. In diesem Fall möchten wir auf der Planetenseite gerne auch den Abstand zur Sonne in astronomischen Einheiten angeben. Wir könnten hier natürlich auch einfach unsere Klasse erweitern, aber insbesondere wenn die betreffende Klasse nicht unter unserer Kontrolle liegt können wir diesen Ansatz verwenden.

Wir definieren eine statische Methode mit der Annotation @TemplateExtension die ein Planet Objekt entgegen nimmt und einen double Wert zurückgibt. In der Methode wird dann die entsprechende Berechnung vorgenommen. Bei der Ausgabe können wir auf eine weitere, bereits vordefinierte, Erweiterung zurückgreifen und über str:fmt() die Ausgabe entsprechend formatieren.

^{src/main/java/de/gedoplan/showcase/web/PlanetResource.java}

^{src/main/resources/templates/PlanetResource/planet.html}

Das ganze Projekt findet ihr wie immer auch auf GitHub.

In Cloud-Anwendungen – aber durchaus nicht nur dort – interessieren wir uns dafür, wie die Anwendungen laufen, ob es ihnen „gut“ geht und wie sie sich untereinander aufrufen. Technisch sind das die Aspekte Metrics und Tracing.

Die CNCF (Cloud Native Computing Foundation) hat dafür schon seit Jahren ein Open-Source-Projekt namens Open Telemery, das u. a. APIs bereitstellt, mit denen diese sog. Telemetriedaten in Anwendungen erfasst und exportiert werden können. Für Java nimmt sich nun MicroProfile Telemetry des Themas an und für Quarkus gibt es passende Extensions!

Die Extension quarkus-opentelemetry unterstützt u. a. Tracing, d. h. die Verfolgung von Requests über ggf. mehrere Anwendungen hinweg. Solange man sich im Bereich von RESTful Services befindet, die mit Jakarta RESTful Webservices implementiert sind und die andere Services bei Bedarf mit MicroProfile Rest Client aufrufen, muss die Anwendung dafür kaum konfiguriert werden. Einzig die Adresse des Tracing Collectors ist (bspw. in application.properties) anzugeben:

quarkus.otel.exporter.otlp.endpoint=http://localhost:4317

Noch bequemer wird es während der Entwicklung, wenn man den für Quarkus ebenfalls verfügbaren Dev Service nutzt, d. h. die Adresse im Dev Mode nicht definiert und mittels der Extension quarkus-observability-devservices-lgtm einen Telemetry Collector aus dem Grafana-Projekt in einem Container hochfahren lässt. Grafana LGTM ist eine All-in-One-Lösung für L(ogging), G(rafana), T(races) und M(etrics), die aus einem Open Telemetry Collector, den Backends Loki für Logging, Tempo für Tracing und Prometeus für Metrics, sowie Grafana zur Visualisierung besteht.

Sind in derart ausgerüstenen Anwendungen einige Requests durchgelaufen, kann man sich diese in ihrem zeitlichen Zusammenhang in Grafana aus der angebundenen Tempo-Datenbank visualisieren lassen.

Die Spezifikation MicroProfile Telemetry verlangt derzeit nur die Implementierung von Tracing, aber Quarkus unterstützt auch Metrics und Logging. Bei der oben genannten Extension müssen diese Aspekte in der Konfiguration eingeschaltet werden:

quarkus.otel.metrics.enabled=true
quarkus.otel.logs.enabled=true

Die von den Anwendungen exportierten Daten können dann in Grafana in den Datenbanken Prometeus bzw. Loki zentral eingesehen werden.

Schon ohne wesentliche Konfiguration und ganz ohne spezielle Programmierung werden Quarkus-Anwendungen so mit ganz niedriger Einstiegshürde „observable“. Man kann aber auch recht leicht Tracing-Daten anreichern oder eigene sog. Spans einbringen. Ebenso lassen sich anwendungsspezifische Metriken bspw. als Counter oder Histogramme programmieren.

Mehr Details finden Sie in Open Telemetry und MicroProfile Telemetry – oder noch besser: Kommen Sie doch zu einem unserer Quarkus-Seminare!

Damit LLMs ihre Aufgaben möglichst zielgerichtet erfüllen ist es manchmal sinnvoll Eingabe- und Ausgabebedingungen zu definieren und zu prüfen. Die Quarkus-Integration von LangChain4j bietet genau dafür schon länger die Guardrails-Funktionalität. Nun ist diese Funktionalität mit Version 1.1.0 auch in der Upstream-Bibliothek verfügbar und kann damit auch z.B. in JSE-, JEE- oder Spring-Anwendungen verwendet werden. Wir werfen in diesem Beitrag einen Blick auf das Konzept und lernen die Quarkus-Implementierung an einer kleinen Beispielanwendung kennen. Die Upstream-Implementierung nutzt prinzipiell die gleichen Schnittstellen und häufig ist zum Übertragen nichts weiter als ein Anpassen der import-Anweisung notwendig.

Eingabebedingungen festlegen

Unsere Beispielanwendung verwendet ein LLM um Java-spezifische Fragen zu beantworten. In diesem Fall verwenden wir der Einfachheit halber ein allgemein trainiertes LLM das vermutlich auch auf Fragen zu anderen Programmiersprachen sinnvoll antworten könnte. Wenn wir aber ein spezifisch trainiertes LLM verwenden oder zu einem spezifischen Thema Kontext bereitstellen, ist es sinnvoll die Anfragen auch auf die relevante Domäne zu beschränken. Andernfalls kann das zu verstärkten „Halluzinationen“ und faktisch falschen Aussagen führen. Hier nutzen wir ein InputGuardrail um die Anfragen auf das Thema Java zu beschränken. Weitere mögliche Anwendungsfälle könnten die Einschränkung auf eine bestimmte Sprache (Deutsch, …), das automatische Zensieren von personenbezogenen Daten oder das Erkennen von böswilligen Anfragen sein.

Fangen wir mit einer simplen Implementierung an. Das Interface InputGuardrail sieht die Methode validate() vor, die im einfachsten Fall eine UserMessage entgegen nimmt. Der Rückgabewert kann eine von drei Ausprägungen annehmen:

• success: Bei einem erfolgreichem Durchlaufen aller InputGuardrails wird die Anfrage an das LLM weitergeleitet. Über successWith(String) kann die Anfrage vor dem Weiterleiten noch angepasst werden um z.B. bestimmte Inhalte zu entfernen.
• failure: Ein Fehlschlagen führt dazu, dass die Anfrage nicht an das LLM weitergeleitet wird. In diesem Zustand werden allerdings trotzdem weitere InputGuardrails durchlaufen um mögliche weitere Probleme festzustellen und zu sammeln.
• fatal: Ein fatales Fehlschlagen führt zum direkten Abbruch und es werden auch keine weiteren InputGuardrails durchlaufen.

^{src/main/java/de/gedoplan/showcase/SimpleJavaQuestionDetectionInputGuardrail.java}

In unserem AiService können wir die InputGuardrails einfach über die Annotation @InputGuardrails aktivieren. Die Annotation kann auch eine Liste von Klassen entgegennehmen.

^{src/main/java/de/gedoplan/showcase/JavaQuestionsAiService.java}

Wenn wir uns nun ein paar mögliche Anfragen anschauen, dann fällt relativ schnell auf, dass dieses einfache Implementierung noch nicht ausreicht.

1. Can you give me an example for the syntax of lambda expressions in Java?
2. Can you give me an example for the syntax of lambda expressions in Python?
3. What is new in JDK 21?
4. What is the weather like in Java, Indonesia?

Die ersten beiden Anfragen werden noch richtig eingeordnet, aber die dritte Anfrage wird trotz des klaren Java-Bezugs abgelehnt. Die vierte Anfrage wird durchgewunken, dabei hat sie nichtmal etwas mit Programmierung zutun.

Eine etwas komplexere Eingabebehandlung könnten wir zum Beispiel mit einem zweiten AiService umsetzen. Die dahinterliegende LLM-Konfiguration kann von der eben verwendeten abweichen. Die Konfiguration können wir unter dem Namen topicDetectionModel in den properties festlegen. Wir verwenden hier das Structured Output Feature von LangChain4j, das wir uns hier bereits angesehen haben.

^{src/main/java/de/gedoplan/showcase/TopicDetectionAiService.java}

^{src/main/java/de/gedoplan/showcase/TopicDetectionResult.java}

Auch unser erweitertes Guardrail muss entsprechend angepasst werden und den TopicDetectionAiService verwenden.

Damit werden nun zumindest die 4 oben stehenden Beispiele richtig zugeordnet.

Nun zur Ausgabeüberprüfung

Auch für die Ausgabe können wir Regeln definieren, die erfüllt sein müssen, damit ein Ergebnis zurückgeliefert wird. Dafür ist das Interface OutputGuardrail vorgesehen, welches analog zur Eingabevariante eine validate() Methode vorsieht, die aber hier im einfachsten Fall ein AiMessage Objekt statt einer UserMessage verarbeitet. Auch hier nehmen die Rückgabewerte die oben für die Eingabevariante beschriebenen Ausprägungen an – mit einem Zusatz: Mithilfe von retry und reprompt können Anfragen automatisch zur Nachbesserung an das LLM zurückgegeben werden. Wie häufig dieser Vorgang maximal ausgeführt wird, kann in Quarkus über eine Property konfiguriert werden. In der Upstream-Bibliothek ist das beim Aktivieren der Guardrails im AiService möglich.

Für das Structured Output Feature gibt es bereits eine vorimplementierte Guardrail AbstractJsonExtractorOutputGuardrail, die wir auch hier anwenden können um die Wahrscheinlichkeit einer strukturell korrekten Antwort zu erhöhen. Wenn das LLM neben einer validen JSON-Struktur noch weiteren Text mitliefert wird zunächst versucht den überflüssigen Inhalt zu kürzen. Führt das nicht zum Erfolg wird das LLM gebeten die Ausgabe nochmal zu überprüfen und korrekt zu formatieren. Erst nach einem erfolgreichen Durchlaufen der Guardrail wird die Ausgabe zurückgegeben.

Da in der Guardrail für den Test der JSON-Struktur der konkrete Rückgabe-Typ zur Laufzeit bekannt sein muss, kann die vordefinierte Guardrail nicht einfach über eine Typenvariable generisch konfiguriert werden. Stattdessen müssen wir in der Quarkus-Integration aktuell eine eigene Implementierung der abstrakten Basisklasse bereitstellen und darin die Typinformation hinterlegen. Die Upstream-Implementierung nutzt zum Festlegen der Typinformation zur Laufzeit einen Konstruktoraufruf.

Diese Guardrail können wir nun im TopicDetectionAiService aktivieren.

Für die Quarkus-Integration steht mit Release der neuen Upstream-Implementierung nun eine Integration der Neuerungen an. Es werden sich in dem Zuge vermutlich zumindest einige Paketdefinitionen ändern um auch hier zukünftig wenn möglich die Upstream-Annotationen und Klassen zu verwenden.

Einfache dynamische Ausgabeanpassung

Wenn ich garnicht prüfen möchte ob die Ausgabe valide ist, aber die Ausgabe möglicherweise dynamisch erweitern oder anderweitig verändern möchte, wäre das prinzipiell mit OutputGuardrail#successWith bereits möglich. In der Quarkus-Integration gibt es allerdings auch die Möglichkeit einen AiResponseAugmenter zu definieren. Trotz des Wortes „Augment“ hat das nicht direkt etwas mit dem Thema Retrieval Augmented Generation (RAG) zu tun (zum Blog-Beitrag). Das „Augment“ bezieht sich hier auf die Antwort des LLM und nicht die Anfrage. Nichtsdestotrotz kann mit einem AiResponseAugmenter die Ausgabe z.B. derart erweitert werden, dass tatsächlich verwendete Quellen, die als Kontext zur Anfrage hinzugefügt und letztlich in der Antwort verwendet wurden, in der Antwort zusätzlich verlinkt oder verdeutlicht werden. Das Ziel wäre hier die Erklärbarkeit und Nachvollziehbarkeit von Antworten zu erhöhen.

In unserem Fall liefert das konfigurierte LLM gemma3n:e2b leider Antworten mit mehreren nicht notwendigen Zeilenumbrüchen am Ende, die bei einer einfachen Ausgabe der Antwort die Formatierung stören. Wir definieren deshalb einen TrimResponseAugmenter der Whitespaces am Ende der Antwort abschneidet.

^{src/main/java/de/gedoplan/showcase/TrimResponseAugmenter.java}

Im AiService kann der AiResponseAugmenter dann über die Annotation @ResponseAugmenter(TrimResponseAugmenter.class) aktiviert werden.

Das ganze Beispielprojekt gibt es wie immer auf GitHub zum Ausprobieren.

Bei der Integration von Daten aus Fremdsystemen bspw. für den Import kommen immer wieder die gleichen Anforderungen auf.

• Wir haben hier eine Datei in einem bestimmten Format, die ihr in euer System übernehmen müsst.
• Wir können euch zwar die Daten liefern, aber weitere Informationen dazu liegen in einem anderen System vor.
• usw.

Diese Anforderungen gleichen meistens einem bestimmten Muster. Apache Camel ist ein Framework für solch eine Integration von Systemen und Datenformaten. Es liefert bereits sehr viele Lösungsmuster für diese Art von Implementierungen.

Ich habe mir ein ganz kleines Beispiel einer solchen Integration herausgesucht und möchte euch die Nutzung von Apache Camel in Verbindung mit einer Quarkus-Anwendung zeigen. Wir bekommen unsere Daten in Form einer CSV-Datei und möchten diese als Java Klassen in unserer Anwendung nutzen.

Um einen Import von CSV-Daten ohne ein Mapping oder einen Konverter zu lösen gibt es in Camel das Datenformat Bindy. Damit ist es möglich, durch den Einsatz von Annotationen, die Java Klasse entsprechend vorzubereiten.

Apache Camel arbeitet die Aufgaben in sogenannten Routen ab. Diese können in Java mit Hilfe eines Route-Builders erstellt werden. Für den Import ergibt sich somit die folgende Route:

Hierbei weisen wir Camel an die Dateien in einem bestimmten Verzeichnis zu überwachen und diese dann zunächst von CSV in unsere Customer Klasse umzuwandeln. Da es sich hierbei um eine Liste von Daten handelt, teilen wir diese Liste in ihre einzelnen Einträge auf und geben die weitere Verarbeitung an eine weitere Route.

In dieser Route übergeben wir jedes einzelne Customer Objekt in eine CDI-Bean. Diese haben wir mit einer @Named-Annotation versehen und können diesen Namen in der Route ansprechen.

Wir übergeben also an die CDI-Bean mit dem Namen importService und rufen die Methode importCustomer auf. Diese bekommt als Parameter ein Customer Objekt übergeben. Damit bin ich in meiner Java-Welt angekommen und kann das Objekt in meiner Anwendung nutzen.

Mit Hilfe von Apache Camel lassen sich die alltäglichen Probleme der Integration von Daten auf einfache Art und Weise lösen, ohne jedes mal das Rad neu erfinden zu müssen. Das Beispiel findet ihr wie immer auf Github.

Der Dev-Service in Quarkus bietet dem Entwickler eine sehr komfortable Möglichkeit die lokale Entwicklung zu beschleunigen. Nach einer Änderung des Quellcodes werden die angepassten Teile automatisch neu bereitgestellt und man kann die Anpassungen sofort testen. Darüber hinaus stehen in den Dev-Services weitere Unterstützung bei der Entwicklung zur Verfügung.

Sobald man bspw. einen JDBC-Treiber für seine Persistenz-Schicht einsetzt, wird je nach Treiber eine entsprechende Datenbank automatisch über Testcontainers zur Verfügung gestellt. Das funktioniert für sehr viele weitere Technologien wie bspw. Messaging über Kafka oder AMQP, aber auch für die Security in Form von Keycloak. Diese Möglichkeiten sind schon sehr vielfältig, dennoch wurden in vielen Projekten zusätzlich auch weitere Docker-Container insbesondere über Docker Compose für die lokale Entwicklung eingesetzt.

Mit dem Release 3.22 wurde diese Möglichkeit mit den Dev-Services verbunden. Es lassen sich jetzt über eine compose-devservices.yml diese Container zusätzlich mit integrieren. Damit müssen diese Container nicht mehr separat gestartet werden. Die folgende yml-Datei konfiguriert eine PostgreSQL und einen mailhog-Container.

Die PostgreSQL Datenbank wird von Quarkus automatisch mit der Datasource verbunden. Quarkus erkennt über das verwendete postgres-Image, dass keine vorkonfigurierte Datenbank gestartet werden muss. Bei mailhog handelt es sich um einen Dienst, der nicht automatisch mit zur Verfügung gestellt werden würde. Wird in Quarkus die Mail-Extension verwendet, wird in den Dev-Services automatisch in den Mock-Modus umgeschaltet. Damit werden alle versendeten Mails im Quarkus-Log ausgegeben und intern gespeichert. Das kann man in den application.properties deaktivieren. Dann benötigen wir jedoch eine Konfiguration für einen Mailserver. Diesen starten wir als zusätzlichen Container und verbinden den Port 1025 mit der Quarkus-Konfiguration quarkus.mailer.port.

Ich glaube durch die Integration von Docker Compose in die Dev-Services ist es in vielen Projekten einfacher eine lokale Entwicklungsumgebung bereitzustellen und damit die Entwicklung nochmals zu optimieren. Eine ausführliche Dokumentation findet ihr hier: https://quarkus.io/guides/compose-dev-services.

In diesem Teil der „AI in Java“ Serie schauen wir uns das Thema Retrieval Augmented Generation (RAG) genauer an. Damit können wir LLMs unter anderem mit spezifisch für den Geschäftsprozess relevanten Informationen versorgen ohne das Model erst mit neuen Daten zu trainieren.

In den vorherigen Blogposts dieser Serie haben wir LLMs bereits ermöglicht Schnittstellen (Tools) zu nutzen um weitere Informationen zu erhalten oder sogar Geschäftsprozesse zu steuern (mit Spring AI und mit Quarkus+LangChain4j). Bei RAG wird bei der Anfrage bereits bestimmt welche Informationen (z.B. aus einer vorbereiteten Sammlung an Dokumenten) für die Anfrage relevant scheinen und dem LLM direkt mit der Anfrage als Kontext zur Verfügung gestellt. Das LLM kann nun auf Basis dieser Informationen eine Antwort auf die Anfrage generieren. Wir probieren das ganze anhand eines einfachen Beispielprojekts mit Quarkus und LangChain4j aus. Als LLM verwenden wir wieder mistral mit Ollama.

Ähnlich wie in den bisherigen Beispielen stellen wir dem LLM auch hier wieder Verkehrs- und Wetterinformationen zur Verfügung. Konkret geschieht das in diesem Fall durch einfache Textdateien mit einem Wetterbericht oder Informationen zu Baustellen. Um einfach mal anzufangen und die Möglichkeiten auszuprobieren eignet sich das Easy RAG Feature von LangChain4j das, insbesondere mit der Quarkus Integration, sehr einfach einzubinden ist. Wir fügen einfach die quarkus-langchain4j-easy-rag Maven Dependency hinzu, legen die entsprechenden Dokumente in unseren Projekt ab und spezifizieren den Pfad in der application.properties Datei.

In unserem Fall legen wir die Textdateien im Ordner documents ab. Wir aktivieren zusätzlich eine weitere Property, damit die Anwendung bei einem Neustart, zum Beispiel durch eine Änderung im Dev-Modus, die Embeddings für unsere Informationen nicht neu berechnen muss. Moment — Embeddings? Embeddings sind Vektoren, die die Semantik (also die Bedeutung) von Textabschnitten darstellen sollen. Um die Relevanz eines Textabschnitts für eine bestimmte Fragestellung zu ermitteln wird dann die Ähnlichkeit der Embeddings (also zeigen die Vektoren in eine ähnliche Richtung) verglichen. Easy RAG stellt die Embeddings der Textsegmente als Default in einem in-memory store bereit, das reicht für unsere einfachen Beispiele zum Ausprobieren aus. Für weiterführende Projekte gibt es Schnittstellen für persistente Vektordatenbanken. Bestimmt werden die Embeddings durch das Model nomic-embed-text, das standardmäßig für Projekte mit Ollama Integration ausgewählt wird.

Aber was passiert nun eigentlich, wenn wir Anfragen an unser LLM stellen ohne weitere Einstellungen vorzunehmen?

Okay unsere Frage wurde beantwortet. Aber wie man sieht beinhaltet die angereicherte Anfrage mehr Informationen, als für die Beantwortung notwendig gewesen wären — und das LLM nutzt sie bereitwillig für eine ausschweifende Antwort. Das bedarf vielleicht doch noch etwas fine-tuning. Für einen kleinen Überblick können wir z.B. eine kleine HTTP-Schnittstelle hinzufügen, in der die Anfrage mit den gespeicherten Embeddings verglichen und die Embeddings samt einem Score für die Ähnlichkeit zurückgegeben werden. Der Score nimmt einen Wert zwischen 0 und 1 abhängig von der Ähnlichkeit ein.

Eine relativ einfache Konfiguration ist die Menge an Ergebnissen, die bei einer Anfrage an den Embedding-Store zurückgegeben werden, weiter zu begrenzen. Hierfür kann der Wert der Property quarkus.langchain4j.easy-rag.max-results von der Voreinstellung (5 Ergebnisse) abgeändert werden. Eine Begrenzung auf Basis des Score ist über die Property quarkus.langchain4j.easy-rag.min-score möglich. Statt des bereitgestellten RetrievalAugmentors können wir auch einen eigenen Augmentor verwenden und hier die Ergebnisse anhand des Scores oder anderen Filteranweisungen beschränken. Auch Komponenten wie der ContentInjector, der bestimmt wie der Prompt an das LLM formatiert wird, können hier angepasst werden.

Durch die Beschränkung des mitgelieferten Kontexts erreichen wird schonmal etwas bessere Ergebnisse. Durch Anpassungen des Prompts können auch hier noch weitere Optimierungen abhängig vom konkreten Anwendungsfall vorgenommen werden. Wobei auch hier gilt: LLMs sind sehr große stochastisch operierende Maschinen und jede Verarbeitung ist im Regelfall anders.

Auch beim Prozess des Einbettens und Speichern der Dokumenteninhalte können wir noch Optimierungen vornehmen. Über die Properties quarkus.langchain4j.easy-rag.max-segment-size und quarkus.langchain4j.easy-rag.max-overlap-size kann die maximale Größe von Segmenten und deren Überlappung beim Einlesen für den spezifischen Inhalt angepasst werden. Natürlich ist sobald es über kleine Beispiele hinausgeht auch eine persistente Vektordatenbank sehr sinnvoll. Für Quarkus sind bereits einige Integrationen wie quarkus-langchain4j-redis verfügbar, die auch Dev-Services für die Entwicklung mitbringen.

Das Beispielprojekt gibt es wie immer auch auf GitHub.

Im letzten Blog-Artikel zum Thema AI haben wir uns die Tools-Unterstützung mit Spring und Spring AI angeschaut (siehe hier). In diesem Artikel schauen wir uns nun dasselbe Beispiel mit Quarkus und LangChain4j an. Die Bibliothek ist zunächst mal an kein bestimmtes Framework gebunden, es gibt aber optionale Integrationen um die Verwendung mit Spring Boot oder Quarkus zu vereinfachen. In unserem Beispielprojekt verwenden wir wieder das Modell mistral (lokal mit Ollama) und ermöglichen dem LLM aktuelle Wetter- und Verkehrsinformationen abzurufen. Für dieses Beispiel füllen wir diese Schnittstellen aber zunächst nur mit Beispieldaten.

Im Gegensatz zur Umsetzung mit Spring AI kann man bei Langchain4j auch einen eher deklarativen Ansatz auf Basis von Annotationen verwenden um die LLM-Schnittstelle zu definieren. In den Code-Beispielen fokussieren wir uns diesmal auf die Wetterinformationen. Die Schnittstellen für die Verkehrsinformationen sind analog implementiert.

Tools (also Funktionalitäten, die das LLM verwenden kann) können mit @Tool und einer Beschreibung der Schnittstelle annotiert werden. Man kann auch hier beliebige Java-Typen als Parameter angeben, LLMs kommen aber mit einer flacheren Struktur oft besser klar. Mit der @P Annotation können die Parameter hier noch weiter beschrieben und als optional gekennzeichnet werden.

Die Typen sind hier dieselben wie bereits im Spring AI Beispiel.

Die Mock-Schnittstelle liefert dann ein paar vordefinierte Wetterinformationen.

Unsere Anwendung beinhaltet auch eine einfache HTTP-Schnittstelle zum Testen, in der eine Anfrage an das LLM gesendet wird. Die Antwort bekommen wir dann entsprechend zurück.

Der ToolsAiService kann durch die Quarkus Integration über Annotationen bereitgestellt und konfiguriert werden.

Eine beispielhafte Interaktion kann dann so aussehen.

Im Gegensatz zu Spring AI können wir hier Logging für die HTTP Kommunikation mit dem LLM einfach über die Properties quarkus.langchain4j.ollama.chat-model.log-requests und quarkus.langchain4j.ollama.chat-model.log-responses aktivieren.

Das Beispiel gibt es wie immer auf GitHub.

Im ersten Teil der Serie zum Einsatz von DMN-Engines in Enterprise Projekten habe ich euch den Gedanken der Entscheidungstabellen als dynamische Geschäftslogik versucht ein wenig näher zu bringen. Im zweiten Teil wollen wir diese Entscheidungstabellen nun in unsere Anwendung einbauen.

Die kleine Beispielanwendung ist eine Quarkus-Anwendung, die eine Integration der Camunda DMN-Engine nutzt. Ich habe mich an dieser Stelle für den Einsatz der Camunda Version 7 entschieden, da diese sehr einfach in eine Anwendung eingebunden werden kann. Wir starten natürlich ebenfalls mit einer Entscheidungstabelle, die ich mit Hilfe des Camunda Modelers erstellt habe. Das Beispiel ist ebenfalls sehr einfach gehalten. Auf Basis der Anzahl von getätigten Bestellungen soll ein Rabatt für die aktuelle Bestellung ermittelt werden.

Diese Entscheidungstabelle ist mit Hilfe der Decision Model and Notation (DMN) erstellt worden. Dabei handelt es sich um eine Spezifikation der Object Management Group (OMG). Die technische Basis bildet die DMN-Datei, welche die Entscheidungstabelle im XML-Format enthält. Um diesen Beitrag nicht unnötig aufzublähen, beschränke ich mich an dieser Stelle nur auf die Entscheidungstabellen. Im Modeler wird diese Notation entsprechend in eine grafische Form gebracht, damit eine Modellierung auch von nicht technik-affinen Personen erfolgen kann.

Um nun die so erstellte DMN-Datei auch in unserer Anwendung nutzen zu können, habe ich eine Java-Klasse implementiert, in der ich zunächst die DMN-Engine erzeuge und mit der DMN-Datei initialisiere. Anschließend kann ich mir dann die eigentliche Entscheidungstabelle aus dieser Datei geben lassen.

private DmnEngine dmnEngine;
private DmnDecision discountDecision;

@PostConstruct
void init() {
  dmnEngine = DmnEngineConfiguration
      .createDefaultDmnEngineConfiguration()
      .buildEngine();
  discountDecision = dmnEngine.parseDecision("discount", this.getClass().getResourceAsStream("/shop.dmn"));
}

Für die Ermittlung des Rabattes nutze ich nun keinen Code, der in einer Java-Methode implementiert wurde, sondern die Entscheidungstabelle. Auch diese verwendet Eingabeparameter um ein Ergebnis liefern zu können. Diese werden über eine Variablen Map in die DMN-Engine übergeben.

var variableMap = Variables.createVariables()
    .putValue("orders", numberOfOrders);
var decisionResult = dmnEngine.evaluateDecision(discountDecision, variableMap);

Durch den Einsatz der Entscheidungstabelle habe ich die notwendige Implementierung der Geschäftslogik ausgelagert. Diese Logik kann nun durch den Einsatz des Modellers auch von Personen aus der Fachabteilung gepflegt werden. Ändern sich die Anforderungen ist es jederzeit möglich die Tabelle entsprechend anzupassen und diese ohne eine weitere Codeanpassung in der Anwendung zu nutzen. Ich hoffe ich konnte an diesem kleinen Beispiel die Möglichkeiten dieser Technologie zeigen. Die Beispielanwendung ist hier zu finden.

Generative KI Modelle sind immer noch in aller Munde und mittlerweile hat vermutlich jeder schon einmal versucht sich mit ChatGPT zu unterhalten. Um die KI Modelle auch programmatisch anzufragen bieten einige Anbieter auch (meist kommerzielle) HTTP-Schnittstellen an, mit denen wir unsere Anwendungen mit den Fähigkeiten der KI Modelle ausstatten können. Das manuelle Erstellen von HTTP-Anfragen wird allerdings schnell anstrengend und fehleranfällig. Für etwas mehr Komfort gibt es mittlerweile auch für Java die ein oder andere Bibliothek, die uns den Zugriff erleichtert. Lokale Ausführungsumgebungen wie Ollama ermöglichen es uns außerdem diese Anfragen zu verarbeiten, ohne dass Informationen unseren Kontrollbereich verlassen.

LangChain4j ist bereits am längsten verfügbar und kann in Java-Projekten mit beliebigem Unterbau verwendet werden. Es gibt zudem spezifische Integrationen für Spring Boot und Quarkus für die Verwendung in dem jeweiligen Framework. Spring AI ist eine etwas neuere Entwicklung aus dem Spring Team und konkret auf die Verwendung im Spring Framework zugeschnitten. Zu guter Letzt bietet auch Microsoft eine Java-Variante seiner .NET-Bibliothek Semantic Kernel.

All diese Bibliotheken sind in sehr aktiver Entwicklung, es bleibt spannend zu beobachten ob sich hier ein Favorit durchsetzen wird. Wir werden uns in weiteren Blog-Posts einige Funktionalitäten und Umsetzungen noch genauer anschauen.

Viele Anwendungen speichern User- und Berechtigungsdaten in Datenbank-Tabellen. Mit Hilfe der Extension quarkus-elytron-security-jdbc ist es sehr einfach, in Quarkus-Anwendungen Security-Daten aus Tabellen zu nutzen. Die Daten gehen dabei in das Standard-Security-System von Jakarta EE ein und können dann bspw. programmatisch genutzt werden:

Mit den üblichen Annotationen ist auch eine deklarative Nutzung möglich:

Zur Konfiguration reichen zwei SQL Queries mit ein paar Zusatz-Properties:

Die Beispiele stammen aus unserer Quarkus-Demo-Anwendung quarkus-security-jdbc, die in https://github.com/GEDOPLAN/quarkus-demo enthalten ist.

Die Konfiguration unseres Java-Backend über Umgebungsvariablen zur Laufzeit ist zum Beispiel mit MicroProfile-Config im JEE/Quarkus Kontext oder ConfigurationProperties in Spring Boot ziemlich einfach. Wenn unsere Anwendung einmal gebaut ist, können wir sie in unterschiedlichen Umgebungen ausrollen und verwenden. Das ist insbesondere praktisch, wenn wir die Anwendung als Containerimage (z.B. mit Docker) bereitstellen. Hier ist es üblich den Container bei der Ausführung mit den notwendigen Konfigurationen über Umgebungsvariablen zu versorgen. So können wir unser Image auch zuerst in einer Testumgebung betreiben und nach einer erfolgreichen Prüfung in die Produktivumgebung ausrollen ohne dabei das Image anpassen zu müssen. Diese Vorgehensweise kann allerdings etwas ins Stocken geraten, wenn wir auch unser JavaScript-Frontend derart konfigurieren wollen. Das Problem tritt in unseren Projekten zum Beispiel auf, wenn die Anwendung über einen SSO-Server wie Keycloak authentifiziert wird, die URL und andere Konfigurationen für die Anmeldung sich aber je nach Einsatzumgebung unterscheiden.

In einer Angular-Anwendung geschieht die Konfiguration (ähnlich wie auch in anderen JavaScript-Anwendungen) üblicherweise zur Build-Zeit über Environments (siehe: https://angular.io/guide/build#configuring-application-environments). Hier kann man grundsätzlich auch mehrere Umgebungen unterscheiden, die Konfigurationswerte müssen allerdings bereits zum Build-Zeitpunkt festgelegt werden, unabhängig von der späteren tatsächlichen Einsatzumgebung.

Diese Beschränkung ist für den Betrieb der Anwendung als Containerimage natürlich ärgerlich. Gibt es nicht einen Weg wie wir die einfache Konfigurierbarkeit des Java-Backend nutzen können um die Umgebungsvariablen auch dem Angular-Frontend zur Verfügung zu stellen? Klar! Das Frontend fragt sowieso die darzustellenden Daten beim Backend an, da können wir auch eine Schnittstelle hinzufügen, die die Werte der Umgebungsvariablen bereitstellt.

Konfiguration des Backend

In unserem einfachen Beispielprojekt (GitHub) stellen wir im Quarkus-Backend am Endpunkt /api/envConfig die Property de.gedoplan.quinoaDemo.envConfig.runtimeEnvironment bereit. Für die Konfiguration verwenden wir die @ConfigProperties Annotation von MicroProfile-Config.

Den Konfigurationswert können wir in der application.properties Datei mit default-Werten belegen und/oder zur Laufzeit zum Beispiel über Umgebungsvariablen setzen:

Laden der Konfiguration im Frontend

Das Frontend im Beispielprojekt ist eine Angular 17 Anwendung mit standalone components. Dasselbe Prinzip kann allerdings auch in einer Anwendung mit @NgModule verwendet werden.

Zunächst legen wir hier ein Interface und einen Service an um die Konfiguration aus dem Backend zu laden und bereitzustellen.

In der ApplicationConfig, die in main.ts an bootstrapApplication() übergeben wird, können wir dafür sorgen, dass die Konfiguration beim Initialisieren der Anwendung geladen wird. In diesem Fall wird die ApplicationConfig in app.config.ts erstellt.

Über den EnvConfigService können wir nun auf die Konfiguration zugreifen:

Anwendungsfall: Keycloak-Authentifizierung

Wie in dem einfachen Beispiel oben können wir auch eine Keycloak-Authentifizierung damit konfigurieren. Eine beispielhafte Umsetzung findet sich auf dem keycloak Branch des Repositories. Für die Authentifizierung verwenden wir keycloak-angular als Dependency. Diese muss mit der Keycloak-URL, dem Realm und der Client-Id konfiguriert werden. Vor dem Initialisieren des KeycloakService können wir in der app.config.ts sicherstellen, dass die Konfiguration geladen ist und die entsprechenden Werte verwenden:

Im Quarkus-Backend ist die Keycloak-Authentifizierung konfiguriert, der Endpunkt zum Laden der Konfiguration muss allerdings ungesichert erreichbar sein um die Angular-Anwendung zu initialisieren. Da hier nur Informationen übertragen werden, die sowieso öffentlich im JavaScript-Client konfiguriert werden, stellt das auch kein Sicherheitsproblem dar. Geheime Schlüssel oder ähnliches sollten natürlich über diesen Weg nicht übertragen werden.

Die Anwendung kann jetzt ohne weitere Konfigurationsanpassung im Angular-Frontend ausgeführt werden und ein erstellter Container kann bei der Ausführung zum Beispiel in einem Kubernetes-Cluster einfach über das Backend konfiguriert werden.

Das ganze Projekt inklusive Ausführungsbeispiele gibt es auf GitHub.

Der Alltag eines Entwicklers ist oftmals geprägt von sich immer wiederholenden Entwurfsmustern. Möchte man beispielsweise eine REST-Schnittstelle für persistente Datenobjekte entwickeln muss man zunächst die gewünschten Entitäten definieren. Anschließend sorgt man ggf. mit Repository-Klassen dafür, dass diese Objekte auch persistieren. Zu guter Letzt implementiert man noch die Ressourcen bzw. Endpunkte, die diese Daten nach außen bringen bzw. von dort annehmen können.

Es wäre doch schön, wenn man sich einige dieser Schritte sparen könnte und es einen automatisierten Weg gäbe, der mir diese Arbeiten abnimmt. Mit Hilfe von Quarkus und Panache ist genau das möglich. In diesem Blog Beitrag möchte ich euch das einmal anhand eines einfachen Beispiels zeigen.

Entitäten definieren

Was uns durch keinen Automatismus abgenommen werden kann ist natürlich die Definition unserer Entität. Diese können wir mit Hilfe von Jakarta Persistence (Hibernate) wie folgt definieren:

Wir benutzen an dieser Stelle Lombok um uns Getter- und Setter-Methoden sparen zu können. Darüber hinaus sollten die Methoden equals und hashcode natürlich JPA-konform definiert werden.

Repository anlegen

Panache bietet die Möglichkeit zwei Ansätze für den Zugriff auf die Entitäten einzusetzen. Zum Einen das Active Record Pattern und zum Anderen das Repository Pattern. Ich habe mich an dieser Stelle für Letzteres entschieden, womit es notwendig wird eine Repository Klasse zu definieren.

Panache liefert uns an dieser Stelle bereits die grundlegenden CRUD-Methoden mit. Diese könnten wir nun einsetzen um in einem Rest-Endpunkt die Zugriffe zu implementieren.

Endpunkt erzeugen

Damit Panache uns automatisiert unseren Endpunkt erzeugen kann, müssen wir lediglich ein entsprechendes Interface anlegen und mit unserer Repository-Klasse „verbinden“.

Anschließend stehen uns die üblichen Methoden zum Zugriff auf die Ressource zur verfügung. Eine Liste aller Einträge lässt sich bspw. über folgenden Aufruf abrufen.

Darüber hinaus gibt es noch weitere nützliche Parameter, die man bei dem Aufruf mitgeben kann. Mit size kann man die Anzahl der gleichzeitig zurückgelieferten Elemente bestimmen. Auch eine Paginierung ist bereits vorhanden. Für weitere Informationen sei auf die Quarkus-Dokumentation verwiesen.

Neben der Nutzung von Hibernate bzw. Jakarta Persistence lässt sich ebenfalls eine MongoDB zur Speicherung der Daten nutzen.

Das Beispiel haben wir wie immer auf Github abgelegt.

Insbesondere bei der Migration einer Quarkus 2 Anwendung auf Quarkus 3 stößt man beim Testen der Anwendung im K8s-Cluster eventuell auf das Problem, dass die Anwendung über den konfigurierten Ingress nicht erreichbar ist und uns nur eine Fehlerseite mit dem HTTP Statuscode 502 Bad Gateway vom nginx Ingress erwartet. Dabei hat man doch in der Konfiguration des Ingress gar nichts verändert!

Das Problem wird klarer, wenn man sich den Log des Ingress Controllers anschaut. Hier findet sich folgender Abschnitt:

[...] upstream sent too big header while reading response header from upstream [...]

Die Authentifizierung unserer Anwendung läuft in diesem Fall über OIDC und im K8s-Cluster läuft zu diesem Zweck ein Keycloak. Quarkus 3 speichert anders als Quarkus 2 die notwendigen Tokens in den Browser Cookies nun standardmäßig verschlüsselt. Das führt dazu, dass die Cookies größer werden und auch der „Set-Cookie“ HTTP-Header, mit dem die Anwendung den Browser anweist die Tokens in einem Cookie zu speichern, an Größe zunimmt. Standardmäßig hat der häufig eingesetzte nginx als Ingress Controller eine proxy-buffer-size von 4k eingestellt, leider reißt unsere HTTP-Response nun dieses Limit und der Ingress antwortet stattdessen mit einem Fehler. Die Lösung für dieses Problem ist allerdings relativ einfach umsetzbar, denn eine Vergrößerung dieser Einstellung lässt das Problem verschwinden. Im Falle des nginx Ingress Controllers kann die Konfiguration z.B. direkt an der spezifischen K8s-Ingress Beschreibung vorgenommen werden.

Hier kann dann die proxy-buffer-size erhöht werden und die Anwendung sollte nun auch in der Quarkus 3 Version erreichbar sein.