Inhalt

Neue Funktionen und Features

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 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 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