Inhalt

Neue Funktionen und Features

Spring Boot

Language Level auf Java 17

Durch die Migration auf Spring Boot 3 / Spring Framework 6 ist es notwendig, das Language Level auf mindestens Java 17 zu heben. Das jadice web toolkit setzt intern nun auf Spring Boot. Dies ist der empfohlene Weg, für die Entwicklung einer Integration des jadice web toolkit. 

Im Referenzhandbuch sind die Schritte beschrieben, um eine bestehende Anwendung auf Spring Boot umzubauen.

Das JavaEE Modul ist ersatzlos entfallen. Wenn Sie JavaEE anstatt Spring Boot verwenden möchten, finden Sie Informationen hierzu ebenfalls im Referenzhandbuch.

Ein klassisches WAR-/EAR-Deployment ist weiterhin möglich. Informationen hierzu finden sich in der Spring Boot Dokumentation.

Spring Framework 5.0 (03/2018) benötigt Servlet 3.1+. Das jadice web toolkit setzt dies seit Version 5.6.0.0 ebenfalls voraus, jedoch war es technisch dennoch möglich, das jadice web toolkit mit einem Servlet 3.0 Container zu betreiben (Websphere 8.5). Spring Boot 2.5.x nutzt nun aktiv Klassen aus Servlet API 3.1+, wodurch sich das jadice web toolkit nicht mehr auf Websphere 8.5 und anderen Containern mit Servlet 3.0 betreiben lässt. Da die konkret verwendete Spring Boot Version vom Integrator zu setzen ist, besteht theoretisch die Möglichkeit, das jadice web toolkit mit Spring Boot 2.4.x zu verwenden, was technisch ein Deployment auf Websphere 8.5 möglich macht. Dies wird jedoch ausdrücklich nicht empfohlen.

Caching

Das Tile-Caching ist nun standardmäßig deaktiviert. Zudem wird der Cache nun mit einer initialen Größe von 90.000 anstatt 3.000 initialisiert. Das JMX-Monitoring des CompositeKeyCaches wird nun auch initial aktiviert, dies musste vorher z.B. über JMX manuell geschehen.

Wenn das Spring Boot Caching verwendet wird, nutzt Spring Boot einen eigenen In-Memory Cache, der unabhängig von den jadice Caches vorhanden ist und gewissermaßen mit den jadice Caches konkurriert. Für die bessere Handhabung der Caches existieren daher zwei Module im jadice web toolkit:

webtoolkit-extension-jsr107

Diese Erweiterung enthält die Klasse com.jadice.web.ext.jsr107.JSR107CacheAdapter, welche einen JCache-kompatiblen Cache (JSR-107) entgegennimmt und dann an den jadice Cache-Manager übergeben werden kann. Somit können JSR-107 kompatible Caches anstatt der jadice Caches verwendet werden.

In diesem Szenario gibt es gewisse Einschränkungen, die es zu beachten gilt, beispielsweise kann kein Off-Heap- oder Festplatten-Cache für jadice Documents und PageSegmente verwendet werden, da sich diese nicht ohne weiteres serialisieren lassen. Weitere Informationen hierzu finden sich im Referenzhandbuch im Kapitel "Caching".

webtoolkit-extension-jadice-jcache

Java 11 Dependencies

Seit Version 5.9 des jadice web toolkit wird der Betrieb unter Java 11 unterstützt.

Metriken

Im Vergleich zu 5.10 hat sich die Art und Weise, wie Metriken erzeugt werden, geändert. Außerdem wurden die Bezeichner leicht geändert, z.B. wurde aus "jwt.readDocument" ein "jwt.read.document". Die neue Art und Weise wird in https://webtoolkit.jadice.com/doc/docs/en/reference/monitoring/ beschrieben.

API-Änderungen und Umbenennungen von Klassen und Packages

com.levigo.jadice.web.client.ui.Splash
com.levigo.jadice.web.client.ui.style.DefaultUIStyle#splashScreen()
com.levigo.jadice.web.client.ui.style.DefaultUIStyle#levigoLogo()

5.11 ist daher die letzte Version, die mit Java 8 und 11 betrieben werden kann. Diese Version wird von uns mindestens so lange mit Fehlerbehebungen versorgt, so lange es auch von Spring Fehlerbehebungen für diese Version gibt (nach aktuellem Stand ist dies bis November 2023 der Fall).

Konkret bedeutet dies, dass der Code unter Java 17 ausgeführt wird. Code der vom GWT-Compiler kompiliert wird (oft "client" und "shared") wird jedoch maximal Language Level 11 unterstützt. Module die also mit dem GWT-Compiler kompiliert werden sollen, benötigen also folgende Einstellung in Maven:

	<properties>
		<maven.compiler.source>11</maven.compiler.source>
		<maven.compiler.target>11</maven.compiler.target>
	</properties>

	<build>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>https://github.com/levigo/jwt-getting-started/blob/master/jwt-tutorial-000/pom.xml     <configuration>
					<source>11</source>
					<target>11</target>
				</configuration>
			</plugin>
		</plugins>
	</build>

Spring Boot 3 & Spring Framework 6

Für die Integration muss ein Upgrade auf Spring Boot 3 stattfinden. Die entsprechenden Schritte sind im Spring Boot 3.0 Migration Guide beschrieben.

JakartaEE

Durch die Migration auf Spring Boot 3 / Spring Framework 6 ist es notwendig, von JavaEE auf JakartaEE zu migrieren. In den meisten Fällen genügt es, die entsprechenden javax-Imports durch jakarta-Imports zu ersetzen und die entsprechenden Dependencies zu verwenden.

Wenn "Traditional Deployment" verwendet wird, also wenn ein WAR-File auf einem App-Server deployt wird, muss der App-Server JakartaEE kompatibel sein. Eine Liste der unterstützten App-Server finden Sie hier.

GWT Relocation & Jakarta Version

Es werden jetzt die GWT-Klassen aus dem Package org.gwtproject verwendet, anstatt die Klassen aus dem Package com.google.gwt.

Weitere Informationen hierzu finden Sie hier.

Dieser Abschnitt gilt für alle aktuellen Versionen (>=5.12.16.0)

Es können die offiziellen GWT-Versionen >=2.11.0 eingesetzt werden, da diese für Jakarta angepasst wurden.

Dieser Abschnitt galt für Versionen < 5.12.16.0

Durch die JakartaEE Migration, sind die bisherigen GWT-Artefakte (gwt-user und gwt-servlet) in allen Versionen, bis hin zur aktuellsten Version 2.10.0 nicht mehr kompatibel mit Spring Boot 3 / Spring Framework 6. Um die Kompatibilität wieder herzustellen, stellt levigo einen GWT-Fork bereit, der auf JakartaEE migriert wurde. In einer Zukünftigen Version von GWT ist dies hoffentlich nicht mehr nötig (die Diskussion auf Github kann hier verfolgt werden.).

Der levigo-GWT-Fork unterscheidet sich lediglich durch Verwendung von jakarta-Imports anstatt javax-Imports gegenüber dem original GWT-Code. Das Repository mit entsprechender History ist auf der levigo Github Seite einsehbar, das gebaute Artefakt wird über den levigo Nexus bereitgestellt.

<dependency>
  <groupId>org.gwtproject</groupId>
  <artifactId>gwt-dev</artifactId>
  <version>2.10.0</version>
</dependency>
<dependency>
  <groupId>org.gwtproject</groupId>
  <artifactId>gwt-codeserver</artifactId>
  <version>2.10.0</version>
</dependency>
<dependency>
  <groupId>org.jadice.gwtproject</groupId>
  <artifactId>gwt-servlet-jakarta</artifactId>
  <version>2.10.1</version>
</dependency>
<dependency>
  <groupId>org.jadice.gwtproject</groupId>
  <artifactId>gwt-user-jakarta</artifactId>
  <version>2.10.0</version>
</dependency>

GWT Devmode

Der Devmode über die Dependency gwt-spring-boot-starter hat in vorherigen Versionen so funktioniert, dass die Spring Boot Server Anwendung einen GWT-Codeserver (auf Basis von Jetty) gestartet hat. Dieser hat die Änderungen am Client-Code on-the-fly kompiliert. Diese GWT-Devmode-Dependency ist mit der Migration auf JakartaEE entfallen, da der Devmode von GWT javax-Packages verwendet und daher nicht weiter kompatibel ist.

Um weiterhin Client-Code debuggen zu können, empfehlen wir das GWT-Plugin von IntelliJ. Bei der Verwendung von Eclipse kann die in gwt-dev enthaltene Klasse com.google.gwt.dev.DevMode manuell gestartet werden.

Der Devmode über das Plugin muss mit den Optionen -war <PFAD ZU /src/main/webapp/> und -noserver gestartet werden.
Dadurch wird eine eigene Server-Anwendung außerhalb des Spring Boot Backends gestartet (-noserver). Zudem wird die vom GWT-Compiler erstellte APPNAME.nocache.js so angepasst, dass die GWT Kompilate über den Devserver geleitet werden, welcher die on-the-fly Kompilierung vornimmt. Damit alles korrekt funktioniert muss der Devmode zuerst gestartet werden und erst im Anschluss die Spring Boot Backend Anwendung.

Ergänzende Informationen können Sie in der Knowledge-Base und GWT-Doku finden.

Wenn Sie die GWT-Dev-Dependency dennoch benötigen (z.B. bei Tests), sollten Sie "apache-jsp" ausschließen, da sonst per Classpath-Scanning noch javax-Servlets gefunden werden:

<dependency>
  <groupId>org.gwtproject</groupId>
  <artifactId>gwt-dev</artifactId>
  <exclusions>
    <exclusion>
      <groupId>org.eclipse.jetty</groupId>
      <artifactId>apache-jsp</artifactId>
    </exclusion>
    <exclusion>
      <groupId>org.eclipse.jetty.websocket</groupId>
      <artifactId>websocket-client</artifactId>
    </exclusion>
  </exclusions>
</dependency>

Bill of Materials (BOM)

Bisher war die Empfehlung die BOM webtoolkit-spring-boot-bom zu verwenden. Da das jadice web toolkit vollständig auf Spring Boot setzt wurde diese BOM zugunsten der BOM webtoolkit-bom aufgegeben.

Verwenden Sie daher fortan webtoolkit-bom in Ihrer Integration.

Weitere Informationen hierzu finden Sie hier.

API-Änderungen und Umbenennungen von Klassen und Packages

Änderungen in der Modulstruktur / Integration via maven

WebtoolkitServletContextListener

In den vorangegangenen Versionen des jadice web toolkit war der Empfohlene Einstiegspunkt für serverseitige Anpassungen eine eigene Implementierung der Klasse WebtoolkitServletContextListener. Dieser Weg wird nun nicht mehr unterstützt. Sämtliche Konfigurationen können nun über die application.yml oder über entsprechende Beans vorgenommen werden. Weitere Informationen hierzu finden sich im Referenzhandbuch im Kapitel "Einstiegspunkt des Webtoolkits".

Wenn das jadice web toolkit ohne Spring betrieben werden soll, können Sie weiterhin den Weg über den WebtoolkitServletContextListener gehen, Sie müssen in diesem Fall die entsprechenden Services selbst initialisieren. Dies ist nicht empfohlen, weitere Informationen finden Sie im Referenzhandbuch im Kapitel "Nutzung des jadice web toolkit ohne Spring Framework".

Die Methoden initProperties(), initCaches() und initFonts() der Klasse WebtoolkitServletContextListener wurden ebenfalls entfernt. Möchten Sie beispielsweise eine Font-Konfiguration ohne Spring vornehmen, sollten Sie dies als erste Anweisung, innerhalb des WebtoolkitServletContextListener vornehmen, noch bevor der JWTServerContext initialisiert wird.

jadice core

Die Version 5.11 des jadice web toolkit wurde zeitgleich mit der jadice document platform 5.6 veröffentlicht. Damit wurde auch die Dependency "jadice core" auf Version 3.x angehoben. Wenn Sie also Funktionen der jadice document platform verwenden, sind hier ggf. ebenfalls Migrationsschritte durchzuführen. Die Informationen hierzu finden Sie hier.

Änderungen am Verhalten

HTTP-Sessions

Bisher wurde vom jadice web toolkit stets eine HTTP-Session erzeugt. Das jadice web toolkit speichert jedoch keine Informationen in einer Session. Mit Version 5.11.22.67 wurde die Möglichkeit geschaffen, das Erstellen einer Session durch das jadice web toolkit zu deaktivieren. Dazu gibt es die Folgende Einstellung:

ConfigurationManager.getServerConfiguration().getNetworkConfiguration().setAlwaysCreateHttpSession(false)

Seit Version 5.12 ist dieses Verhalten standardmäßig deaktiviert. Falls sich die Integration darauf verlassen hat, dass eine HTTP-Session in jedem Fall vorhanden ist, weil diese aktiv verwendet wird, müssen Sie nun selbst eine Session erzeugen. 

Technische Details

Bisher wurde von einem jadice Filter request.getSession() oder request.getSession(true) aufgerufen, dadurch wurde immer eine Session erstellt. Wir rufen nun jedoch request.getSession(false) auf. An den Stellen, an denen die Integration eine Session benötigt, sollte daher ein Aufruf mit request.getSession(true) erfolgen, damit diese auch erstellt wird.

Änderungen in der Modulstruktur / Integration via Maven

Entfernte Klassen und Funktionalitäten