Inhalt

Generationswechsel - Vorbereitung für ein modernes Frontend

Das jadice web toolkit erlebt mit Version 6 den ersten Generationswechsel in seiner Geschichte (die initiale Version war bereits Generation 5, da die Versionsnummer an den Swing Viewer / document platform angeglichen wurde). Die neue Generation glänzt nicht durch eine große Sammlung an neuen Features, sondern stellt die Weichen, um ein modernes Frontend schrittweise zu ermöglichen, ohne dabei vorhandene Integrationen unbrauchbar zu machen, oder etablierte Technologien und Konzepte über den Haufen zu werfen.

Wir sind stolz darauf, mit diesem Release die erste Version unseres modernen, auf Web Components basierten und für Angular optimierten Frontends für alle Kunden zur Verfügung zu stellen.

Der Umstieg von GWT auf Angular ist nicht als Update oder Upgrade möglich, sondern erfordert eine Neu-Implementierung mit modernen Tools und Frameworks. Elegant ist dabei jedoch, dass das Backend nicht angepasst werden muss - man kann ein und dasselbe Backend für einen GWT- und einen Angular-Viewer verwenden. Natürlich kann auch mit jadice web toolkit Version 6 ein bestehendes GWT Frontend weiter genutzt werden. Die Entwicklung von GWT wird jedoch nicht mehr aktiv fortgeführt, sodass neue Integrationen bestenfalls direkt mit dem Typescript Frontend umgesetzt werden.

Unser Viewer basiert auf Web Components und Typescript. Für Angular existieren entsprechende Komponenten, eine Integration in andere Frontend-Frameworks wie React ist aber ebenfalls möglich.

Neue Funktionen und Features

Kein GWT im Backend

Grundsätzlich gilt, dass Sie natürlich weiterhin auf GWT-RPC und weitere Funktionalitäten von GWT setzen können. Das jadice web toolkit tut dies nun nicht mehr, daher ist es nun möglich, auf weite Teile von GWT zu verzichten. Dies erleichtert den späteren Umstieg auf ein Nicht-GWT-Frontend bzw. macht diesen überhaupt erst möglich.

Tile-Requests

Tile-Requests hatten in der Vergangenheit vier Query-Parameter, wobei sich der interessante Teil im Parameter r verbarg. In diesem Parameter wurden die Informationen die für das Rendering einer Seite benötigt werden per GWT-RPC serialisiert. Wenn Sie Ihre Integration mit Last-Tests getestet haben, sind Sie bestimmt schon darüber gestolpert. Diese URLs sind nur sehr schwer les- und anpassbar (z.B. für Last-Tests). Zukünftig werden auch weitere Informationen per Query-Parameter übertragen. Der Teil der PageSegmentHandles ist nun als JSON kodiert.

Die URL von Tile-Requests (gerenderte Kacheln) sah bisher so aus:

https://webtoolkit.jadice.com/enterprise/jwt/tile?c=a024a898-762a-268f-762a-268f762a268f&v=a024a899-02dd-3354-02dd-335402dd3354&r=7*0*13**674D608AF30ABADAE374AEBB2241DD75*com.levigo.jadice.web.shared.model.internal.FlattenedRenderSpecificationData%2F2762891342*com.levigo.jadice.web.shared.model.settings.AnnotationRenderSettings%2F3358781670*Triangle*%5BI%2F2970817851*%5BLcom.levigo.jadice.web.shared.model.PageSegmentHandle%3B%2F270004123*com.levigo.jadice.web.demo.common.shared.service.sources.SplitFileUploadHandle%2F2259686330*62258f96-07d5-48b4-8904-3ab560099ec0*document*d5729ddb-3c1f-4998-8b97-1825a39806d7*%5BLjava.lang.String%3B%2F2600011424*ROT_000*1*2*3*4*0*0*96*5*6*4*0*0*255*255*7*1*8*9*0*10*0*11*12*0*1122*793*0*0*13*1*

Zukünftig sehen die Requests folgendermaßen aus:

https://webtoolkit.jadice.com/enterprise/jwt/tile?c=a024a898-762a-268f-762a-268f762a268f&v=a0248df6-9f13-a782-9f13-a7829f13a782&deviceResolution=96&zoomFactor=1&defaultLayerStateEnabled=false&rotation=ROT_000&filter=Triangle&roix=0&roiy=0&roiwidth=793&roiheight=1122&layerNames=%5B%5D&gradationCurvePoints=%5B0%2C0%2C255%2C255%5D&handles=%5B%7B%22type%22%3A%22URI%22%2C%22params%22%3A%7B%22uri%22%3A%22upload%3A%2F%2F11785933124963992093%22%2C%22password%22%3Anull%7D%2C%22documentLayer%22%3A%22document%22%2C%22pageIndex%22%3A0%2C%22pageSegmentUUID%22%3A%22f7e36745-2734-423a-b648-f250ca2bb94a%22%7D%5D

Die Handles sehen vor der serialisierung so aus:

[
   {
      "type":"URI",
      "params":{
         "uri":"upload://11785933124963992093",
         "password":null
      },
      "documentLayer":"document",
      "pageIndex":0,
      "pageSegmentUUID":"f7e36745-2734-423a-b648-f250ca2bb94a"
   }
]

Messaging statt RPC

Anstatt eines Remote-Service-Aufrufs versenden Client und Server nun Messages, die interpretiert werden. Diese sind als JSON formatiert und werden nicht mehr per GWT-RPC automatisch serialisiert. Die Messages werden über das Connection-Framework versendet. Dies hat jedoch zur Folge, dass manuelle Anpassungen am Code erforderlich sind. Diese Schritte werden weiter unten erläutert. Das deutlich einfachere Messaging ist im JSON-Format besser interpretier- und debugbar.

URI-Sources

Der bisherige Weg, um ein Dokument zu Anzeige zu bringen, war die Implementierung eines DocumentDataProviders in Kombination mit einer Source und einem PageSegmentHandle. Dieser Weg ist hier beschrieben und wird für den GWT-Viewer nach wie vor unterstützt, im TypeScript-Viewer sind URIs aktuell der einzige Weg um Dokumente laden zu können.

In der Version 6 des jadice web toolkit gibt es nun eine vereinfachte Möglichkeit. Dazu muss vom Integrator lediglich ein URI-Schema definiert und ein entsprechender DocumentDataProvider implementiert werden.

Um dies an einem Beispiel zu veranschaulichen: Angenommen die Dokumente liegen in einem P8-Archiv. Folgende Schritte wären zu erledigen:

@Component
public class P8SchemeDocumentDataProvider implements UriBasedDocumentDataProvider {

    private final String[] schemes = new String[] { "p8" };

    @Override
    public void read(Reader reader, UriSource source) throws JadiceException, IOException {
        String uri = source.getUri();
        String p8Id = uri.substring("p8://".length());
        // Do the magic to retrieve the document from P8 here
    }

    @Override
    public void recover(Reader reader, UriHandle handle) throws RecoverFailedException, JadiceException {
        // Do the magic to retrieve the document from P8 here
    }

    @Override
    public List<String> getSchemes() {
        return Arrays.asList(schemes);
    }
}

    final Reader r = new Reader();
    r.read(new UriSource("p8://LFHA89DH", null /** no password needed for PDF document */), new AsyncCallback<Document>() {
      @Override
      public void onSuccess(Document doc) {
        viewer.getPageView().setDocument(doc);
      }

      @Override
      public void onFailure(Throwable caught) {
        LOGGER.error("loading document failed", caught);
        Window.alert("Can't find the requested document.");
      }
    });

<jwt-multi-mode-viewer [source]="{uri: 'p8://LFHA89DH'}"/>

Eine eigene Source- und Handle-Implementierung wird hier nun nicht mehr benötigt.

HTTP-URIs

Standardmäßig wird ein DataProvider mitgeliefert, der Dokumente von einem HTTP Endpunkt anzeigen kann.

<jwt-multi-mode-viewer [source]="{uri: '<a href="http://www.digbib.org/Franz_Kafka_1883/Der_Prozess_.pdf" }"/>

Dies ist sehr komfortabel in der Entwicklung, kann aber dazu führen, dass ein manipulierter Client eine Anfrage an das Backend schickt und dieses daraufhin einen HTTP-Aufruf absetzt.

Um die Einstellung zu ändern:
In der application.yml folgendes einstellen:
webtoolkit:
  uri-provider-http-enabled: false

Neue Defaults

PNG statt WebP

In Version 5.10 des jadice web toolkit wurde eingeführt, dass Tiles standardmäßig als WebP-Images und nicht mehr als PNG an den Client geliefert werden. Dies bringt Vorteile im Bezug auf Geschwindigkeit und Dateigröße. Jedoch hat sich herausgestellt, dass dies im Containerumfeld weniger gut geeignet ist. Die Erzeugung von WebP-Bildern erfordert Off-Heap-Speicher, was im Monitoring nicht gut überwachbar und steuerbar ist. Die Erzeugung von PNG ermöglicht es jadice auch besser mit dem Cache umzugehen, zudem kann so die Memory-Lücke zwischen Container- und JVM-Speicherlimit deutlich kleiner ausfallen, ohne dass es zu OOM-Killed-Fehlern seitens des Containers kommt.

Der neue Standard ist nun "IMAGEIO".

Weitere Informationen zur Wahl des Tile-Compression-Types sind hier zu finden.

Um die Einstellung zu ändern:
In der application.yml folgendes einstellen:
webtoolkit:
  tile-compression-type: WEBP_LOSSY_HIGH_QUALITY
alternativ programmatisch
ConfigurationManager.getServerConfiguration().setTileCompressionType(ServerConfiguration.TileCompressionType.WEBP_LOSSY_HIGH_QUALITY);

Lenient-Lesemodus

Der neue Standard für das Lesen von PDFs ist nicht mehr "Strict" sondern "Lenient on Error". Dadurch sind in der Regel mehr Dokumente (fehlerhafte Dokumente) anzeigbar als vorher.

Zu Risiken und Nebenwirkungen siehe PDF-Struktur Lesestrategien.

Um die Einstellung zu ändern:
In der application.yml folgendes einstellen:
webtoolkit:
  pdf-structure-read-strategy: STRICT
alternativ programmatisch
ConfigurationManager.getServerConfiguration().setPdfStructureReadStrategy(PDFStructureReaderSettings.PDFStructureReadStrategy.STRICT);

Page-Preloading (GWT-Frontend)

Es werden standardmäßig 2 Seiten vor-geladen.

Um die Einstellung zu ändern:
pageView.setPreloadingPageRange(new PreloadingPageRange(2));

Server Sent Events (SSE) standardmäßig deaktiviert (GWT-Frontend)

Im Standard verbindet sich der Client über Websocket mit dem Backend. Schlägt dies fehl, wird nun direkt zu Longpoll übergegangen. Wenn SSE verwendet werden soll, muss dies nun manuell aktiviert werden.

Siehe auch unten.

Um die Einstellung zu ändern:
ServerConnectionBuilder connectionBuilder = new ServerConnectionBuilder().setServerSentEventsEnabled(true);

Cache-Settings

Der standardmäßig verwendete Composite-Key-Cache hat nun die folgenden Default-Einstellungen:

Diese Werte basieren auf unseren Erfahrungen, weiter Informationen können hier nachgelesen werden.

Font-Konfiguration

In Version 6 des jadice web toolkit wurde die Font-Konfiguration dahingehend angepasst, dass keine Fonts mehr geladen werden, die auf dem Betriebssystem installiert sind. Dies reduziert die Startzeit und oft auch die Anzahl von Warnmeldungen beim Server-Start aufgrund von Problemen beim Einlesen von System-Fonts. Die wahrscheinlich größte Zahl von PDF Dokumenten referenziert entweder Standard-14-Fonts oder hat die Fonts, die zur Anzeige benötigt werden, im Dokument eingebettet. Zudem sind bei einigen Linux-Distributionen (v.a. Distroless) ohnehin keine Fonts vorhanden oder die am ehesten gewünschten (Arial, ...) aus Lizenztechnischen Gründen ebenfalls nicht vorhanden.

Um die Einstellung zu ändern:
Details siehe hier.

Neues Versionsnummern-Schema

Bisher hatte das jadice web toolkit ein vier-stelliges Versionsnummer-Schema. Dieses hat Semantic Versioning um eine führende Stelle, welche der jadice Produktgeneration entsprach, erweitert. Ab Version 6 des jadice web toolkit entfällt die Produktgeneration, sodass ein drei-stelliges Semantic Versioning verwendet wird.

Früher: 5.12.1.2
Heute: 6.1.2

Step-by-Step Migration (Backend & GWT-Frontend)

Anpassung von geänderten Klassen

• Globales Ersetzen von "import com.google.gwt.user.client.rpc.AsyncCallback;" durch "import com.levigo.jadice.web.client.reader.AsyncCallback;"
• Die Exception com.google.gwt.user.client.rpc.SerializationException wird im Client-Code nicht mehr geworfen, entsprechende Catch-Blöcke können entfallen

RemoteLogging

Es gab bisher über das GWT-seitige RemoteLoggingServlet die Möglichkeit Log-Meldungen die beim Client (im Browser) auftraten, ins Server-Log schreiben zu lassen. Als GWT-freie Alternative bieten wir hierzu nun den folgenden Client-Aufruf:

com.levigo.jadice.web.client.util.Logutils.setDefaultRemoteHandler();

Umstellung des Connection-Frameworks auf JSON-Messaging

Genereller Ablauf

Das Messaging folgt dem folgenden Ablauf:

1. Ein Client sendet einen Request an den Server (über das Connection-Framework, also Websocket)
2. Der Server bearbeitet die Anfrage und sendet eine beliebige Anzahl an Antworten an den Client
3. Der Server beendet die Konversation durch eine EOC-Nachricht
   1. alternativ kann der Client durch eine Control-Message die Konversation ebenfalls beenden

Eine Message besteht dabei aus den folgenden Bestandteilen:

• MessageName
  • ein beliebiger, eindeutiger String
• Conversation-ID 
  • eine fortlaufende Nummer, die sicherstellt, dass Nachrichten in der richtigen Reihenfolge verarbeitet oder gegebenenfalls nochmals übertragen werden
• Payload
  • beliebiger JSON-Inhalt

Umstellung

Durch den Entfall von GWT-RPC und der Umstellung auf JSON sind nun (sofern keine URI-Sources verwendet werden) manuelle Anpassungen erforderlich.

In der Vergangenheit war es oft gängige Praxis folgenden Aufbau für einzelne Module zu verwenden:

• Ordner "server"
  • Backend-Code
• Ordner "client"
  • GWT-Frontend-Code
• Ordner "shared"
  • Code, der von Client und Server verwendet wird, oftmals Sources, Handles, Server-Operation-Parameters und String-Konstanten

Diese Aufteilung ist zwar komfortabel, jedoch war seitens GWT schon seit jeher eine klare Trennung von Client- und Server-Code in Form unterschiedlicher Maven-Module (und nicht nur in unterschiedlichen packages) angeraten. Diese Empfehlung möchten wir an dieser Stelle auch klar aussprechen.

Die oben aufgeführte Aufteilung funktioniert auch weiterhin, im Zuge der Umstellung kommen nun jedoch einige DTO-Klassen in server und client hinzu, da Client-Code nun spezielle Client-DTOs benötigt und das Backend spezielle Backend-DTOs. Der Grund für das manuelle Erstellen von DTO-Objekten ist, dass auf dem Client kein Reflection zur Verfügung steht und TypeScript nicht mit (von GWT) serialisierten Java-Klassen umgehen kann. Speziell abstrakte Klassen sind ohne Reflection nicht einfach serialisierbar. Um die zu übertragenden Java-Klassen nach JSON (und zurück) zu serialisieren, werden DTO-Klassen benötigt, die nur die relevanten Informationen enthalten.

Bei dieser "Fleißarbeit" im Client-Code können diese IntelliJ-Code-Templates hilfreich sein: levigo/useful-intellij-live-templates: Collection of importable live templates for IntelliJ IDEA (github.com)

Server-seitig empfiehlt sich der Einsatz von Lombok.

Mapper

Wenn nur einfache Datenstrukturen bei ServerOperations übertragen werden, ist als Integrator Ihr einziger Berührungspunkt mit den Mappern der Aufruf der entsprechenden Mapper bei der Umstellung von Source und Handle (nächster Abschnitt). Bei komplexeren Datenstrukturen, muss ggf. selbst Einfluss auf das Mapping genommen werden.

Für die Serialisierung/Deserialisierung wird jackson verwendet. Dieses nutzt Mapper, um Objekte zu JSON zu konvertieren. Im jadice web toolkit gibt das darauf basierende Mapper, fachlich gegliedert nach dem jeweiligen Einsatzgebiet. Dabei kann zwischen den folgenden Mapper-Arten unterschieden werden:

SimpleMapper

Bei einem SimpleMapper, werden Java-Klassen auf die entsprechenden DTOs gemappt.

PolymorphicMapper

In der Java-Welt gibt es bekanntlich ein Vererbungs-Modell, welches zum Teil sehr komplexe Datenstrukturen erlaubt. Diese Komplexität ist in der JavaScript-Welt eher unüblich und in einer JSON-Struktur weder sauber abbildbar noch erforderlich. Um dennoch vorhandene Strukturen einfach serialisieren zu können, kann ein PolymorphicMapper verwendet werden.

Erstellen von DTOs

From/To Pattern

Die DTO-Objekte werden lediglich zur Serialisierung/Deserialisierung benötigt. Im Code kann wie gewohnt mit den "original" Objekten gearbeitet werden. Wir empfehlen, die DTO-Klassen mit speziellen Methoden zu versehen, die dafür zuständig sind, ein Objekt in und von einem DTO zu konvertieren. Diese Methoden werden von den Mappern verwendet. Anbei folgendes Beispiel für ein DTO für die Klasse java.awt.Color (→ Beispiel-Use-case: Ein Color-Objekt wird als Teil einer ServerOperation vom Client an den Server übertragen)

Client-Seitiges DTO 

Diese DTOs werden nur im Client-Code verwendet. Die Klassen sind für die Verwendung im GWT-Code vorgesehen und haben daher eine Abhängigkeit auf gwt-user. Client-DTOs erweitern JavaScriptObject, eine GWT-JSNI-Klasse.

import java.awt.Color;

import com.google.gwt.core.client.JavaScriptObject;

@SuppressWarnings("ProtectedMemberInFinalClass")
public final class ColorDTO extends JavaScriptObject {
    protected ColorDTO() {
    }

    public native int getRed()/*-{
        return this.r;
    }-*/;

    public native int getGreen()/*-{
        return this.g;
    }-*/;

    public native int getBlue()/*-{
        return this.b;
    }-*/;

    public native int getAlpha()/*-{
        return this.a;
    }-*/;

    public static native ColorDTO create(int r, int g, int b, int a)/*-{
        return {r: r, g: g, b: b, a: a};
    }-*/;

    public static ColorDTO from(Color color) {
        if (color == null) {
            return null;
        }

        return create(color.getRed(), color.getGreen(), color.getBlue(), color.getAlpha());
    }

    public static Color to(ColorDTO dto) {
        if (dto == null) {
            return null;
        }

        return new Color(dto.getRed(), dto.getGreen(), dto.getBlue(), dto.getAlpha());
    }
}

Server-Seitiges DTO 

import java.awt.Color;

import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@NoArgsConstructor
@AllArgsConstructor
public final class ColorDTO {
    private int r;
    private int g;
    private int b;
    private int a;

    public static ColorDTO from(Color color) {
        if (color == null) {
            return null;
        }

        return new ColorDTO(
                color.getRed(), color.getGreen(), color.getBlue(), color.getAlpha()
        );
    }

    public static Color to(ColorDTO dto) {
        if (dto == null) {
            return null;
        }

        return new Color(dto.getR(), dto.getG(), dto.getB(), dto.getA());
    }
}

Mapping registrieren

Damit das jadice web toolkit die DTOs serialisieren und übertragen kann, müssen die Mappings sowohl server- als auch clientseitig bekannt gemacht werden.

com.levigo.jadice.web.client.messaging.mapper.SimplePolymorphicMapper.registerMapping(
                "COLOR", Color.class,
                (color) -> ColorDTO.from((Color) color),
                (json) -> ColorDTO.to((ColorDTO) json)
        );

com.levigo.jadice.web.server.messaging.mapper.SimplePolymorphicMapper.registerMapping(
                "COLOR", Color.class,
                (color) -> json(ColorDTO.from((Color) color)),
                (json) -> ColorDTO.to(dto(json, ColorDTO.class))
        );

Im Produkt vorgenommene interne Umstellungen

Das Konzept der DTOs wurde auch intern für die Umstellung von GWT-RPC auf JSON-Messaging verwendet. Die entsprechenden Klassen befinden sich serverseitig hauptsächlich in com/levigo/jadice/web/server/messaging und clientseitig in com.levigo.jadice.web.client.messaging .

Diese ersetzen vor allem die zuvor von GWT verwendeten Custom Field Serializer.

Für das Versenden der Nachrichten wurde in com.levigo.jadice.web.transport.shared.messaging.DefaultMessageNames eine Liste von Konstanten definiert, um die vom Produkt genutzten Nachrichten zu unterscheiden.

com.levigo.jadice.web.shared.model.document.snapshot.DocumentSnapshot  ist im Wesentlichen der Ersatz für das alte com.levigo.jadice.web.shared.model.serveroperation.internal.SynchronizeObject.

Umstellung von Sources und Handles

Grundsätzlich ist das Vorgehen für Source und Handle dasselbe wie bei anderen Objekten (siehe vorheriger Abschnitt). Für die Sources und Handles werden ebenfalls je eine DTO-Klasse für den Client und eine für den Server benötigt.

Mapping registrieren (für Source und Handle)

Damit das jadice web toolkit die DTOs serialisieren und übertragen kann, müssen die Mappings sowohl Server- als auch Clientseitig bekannt gemacht werden.

@Component
public class Mappings {
    @PostConstruct
    public void init() {
        SourceMapper.get().registerDirectMapping(ClassPathWithAnnoSource.TYPE, ClassPathWithAnnoSource.class);
        PageSegmentHandleMapper.get().registerMapping(
                ClassPathWithAnnoHandle.TYPE,
                ClassPathWithAnnoHandle.class,
                (handle) -> {
                    final ClassPathWithAnnoParamsDTO dto = ClassPathWithAnnoParamsDTO.from((ClassPathWithAnnoHandle) handle);
                    return new ObjectMapper().valueToTree(dto);
                },
                (json) -> {
                    final ClassPathWithAnnoParamsDTO dto = new ObjectMapper().treeToValue(json, ClassPathWithAnnoParamsDTO.class);
                    return ClassPathWithAnnoParamsDTO.toHandle(dto);
                }
        );
    }
}

private void registerMappings() {
  SourceMapper.get().registerMapping(ClassPathWithAnnoSource.TYPE, ClassPathWithAnnoSource.class,
      (source) -> ClassPathWithAnnoParamsDTO.from((ClassPathWithAnnoSource) source),
      (json) -> ClassPathWithAnnoParamsDTO.toSource((ClassPathWithAnnoParamsDTO) json));
 
  PageSegmentHandleMapper.get().registerMapping(CompositeHandle.TYPE, CompositeHandle.class,
      (handle) -> CompositeParamsDTO.from((CompositeHandle) handle),
      (dto) -> CompositeParamsDTO.toHandle((CompositeParamsDTO) dto));
}

GWT ablösen

GWT.create ablösen (optional)

Grundsätzlich gilt, dass Sie natürlich weiterhin auf GWT-RPC setzen können. Um jedoch ein Backend ohne GWT zu bekommen, sollten Sie alle GWT.create-Aufrufe entfernen und stattdessen Messages über unser Connection-Framework versenden. Dies ist weiter unten beschrieben.

Dependencies entfernen

Im Backend können sämtliche GWT-Dependencies entfernt werden

EnableGWTSpringBootApplication

Die Annotation @EnableGWTSpringBootApplication kann im Server-Teil entfernt werden. Die Annotation @EnableJWTSpringBootApplication ersetzt diese.

Umstellung von Server-Operations

Das Server-Operation Konzept ermöglichte es bisher Integratoren, dokumentbezogene Aktionen asynchron serverseitig auszuführen. Anwendungsfälle sind beispielsweise das Speichern von clientseitigen Änderungen an Annotationen.

Dieses Konzept wurde jetzt auf das Messaging-Verfahren des Connection-Frameworks umgestellt. Die Idee ist, dass ein Client generisch eine Nachricht an den Server verschicken kann, unabhängig davon, ob das Dokument mit übertragen werden soll oder nicht. Der Server horcht auf Nachrichten und reagiert entsprechend (asynchron). Die Server-seitige Logik (im MessageListener) sollte unbedingt asynchron (über ein Future) ausgeführt werden und abbrechbar sein (→ einen CancelHandler bereitstellen). Stellen Sie bitte unbedingt (z.B. über einen finally-Block) sicher, dass die Konversation sauber beendet wird, z.B. durch ein sendSuccess oder ein sendFail.

Um eine Klasse zu einem MessageListener zu machen, wird die Klasse mit @MessageName annotiert. Um einen MessageListener zu registrieren wird dieser mit @Component annotiert. 

Client-seitig führt ein Command nun keinen invoke-Aufruf mit einem Observer mehr aus sondern es wird ein send-Aufruf mit einem MessageHandler ausgeführt.

API-Änderungen und Umbenennungen von Klassen und Packages

Client

Server

Alter Pfad	Neuer Pfad	Wechsel Modul	Anmerkung
com.levigo.jadice.web.server.ServerOperation	com.levigo.jadice.web.transport.client.messaging.MessageListener	webtoolkit-server-api → webtoolkit-connection	Grundlegende Änderungen, wie Daten vom Client an den Server geschickt werden.
DocumentDataProvider	com.levigo.jadice.web.server.UriBasedDocumentDataProvider	In webtoolkit-server-api enthalten	Empfohlener DataProvider, der über URIs funktioniert.

API Änderungen bei jadice Core

Wenn Sie jadice Core APIs direkt verwenden sind ggf. weitere Änderungen erforderlich, die API-Änderungen sind hier dokumentiert.

Connection Framework

Server Sent Events deprecated

Der Verbindungsaufbau über SSE ist nun im Standard deaktiviert und auch der Backoff-Mechanismus unterstützt SSE nur, wenn dies manuell aktiviert wurde.

Weitere Informationen sind im Referenzhandbuch zu finden.

Export

Da ServerOperations generell entfernt wurden, muss hier ggf. eine Export-Server-Operation durch einen Export-Message-Listener ersetzt werden.

Änderungen in der Modulstruktur / Integration via Maven

-

Entfernte Klassen und Funktionalitäten