Wiki source code of Basisprojekt

Version 66.2 by Marco Grawunder on 2026/10/18 14:02

Show last authors
1 [[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]
2
3 {{info}}
4 **Worum geht es auf dieser Seite?**
5
6 Diese Seite erklärt den **Einstieg in das bereitgestellte Basisprojekt** und die darin verwendete Client-Server-Kommunikation. Behandelt werden insbesondere Einrichtung und Build, Spring, REST/OpenAPI, DTOs sowie WebSockets/STOMP.
7
8 Das Basisprojekt verwendet mindestens **Java 21**. Screenshots können sich bei neueren Versionen optisch unterscheiden.
9 {{/info}}
10
11 {{toc/}}
12
13
14 = Basisprojekt mit IntelliJ einrichten =
15
16 [[image:1755245956916-184.png]]
17
18 == Repository klonen ==
19
20 {{warning}}
21 Im Screenshot wird teilweise das globale Basisprojekt gezeigt. **Verwenden Sie für die Arbeit das bereits für Ihre Gruppe angelegte Repository.**
22 {{/warning}}
23
24 Sie finden die Clone-URL wie folgt:
25
26 * Loggen Sie sich auf [[https:~~/~~/gitlab.swl.informatik.uni-oldenburg.de/>>https://gitlab.swl.informatik.uni-oldenburg.de/]] ein
27 * Falls nicht vorausgewählt, wählen Sie auf der linken Seite "Projects"
28 [[image:1757398628416-879.png||height="119" width="541"]]
29 * Da Sie bisher noch nichts gemacht haben, ist diese Seite leer. Wechseln Sie auf den Reiter Member
30 * Dort sollte ihr Repository zu finden sein.
31 * Oben rechts gibt es einen Button Code. Kopieren Sie dort die URL, die hinter "Clone with HTTPS" steht.
32 [[image:1757398731084-704.png||height="454" width="323"]]
33
34 [[image:1755245971657-468.png]]
35
36 == Access Token ==
37
38 {{expandable summary="Schritt-für-Schritt: Access Token einrichten"}}
39 Beim ersten Git-Zugriff über HTTPS werden Zugangsdaten benötigt. Statt des normalen Passworts sollte ein persönlicher **Access Token** verwendet werden. Öffnen Sie dazu Ihr Profilbild, wählen Sie **Edit profile** und anschließend **Access tokens**.
40
41 [[image:1757398899497-714.png||height="246" width="278"]]
42
43 Dort können Sie mit [[image:1757398947128-748.png||height="89" width="197"]] ein neues Token anlegen.
44
45 Als Namen kann z. B. `IntelliJ` verwendet werden. Access Tokens sind aus Sicherheitsgründen zeitlich begrenzt. Wählen Sie ein Ablaufdatum, das zum Projektzeitraum passt.
46
47 [[image:1757399088336-273.png||height="92" width="547"]]
48
49 Bei den Scopes sollten die beiden Rechte "read_repository" und "write_repository" gewählt werden.
50
51 Danach wird das Access Token generiert
52
53 [[image:1757399184270-348.png||height="99" width="978"]]
54
55 {{warning}}
56 Kopieren und speichern Sie das erzeugte Token unmittelbar. Es wird nach der Erstellung nicht erneut vollständig angezeigt. **Tokens dürfen niemals in das Repository eingecheckt werden.**
57 {{/warning}}
58
59 Beim **Einloggen **(Achtung! Gemeint ist hier, wenn Intellij (bzw. git) nach den Account-Daten beim Clonen fragt. Man kann auch einen Gitlab-Account hinterlegen (der dann aber parallel existiert). Hier für ist es wichtig, dass noch "api" und "read_user" als Recht vergeben wird.) in IntelliJ können Sie dieses Token im Passwort-Feld verwenden. Geben Sie ihren Account bei Name ein.
60 {{/expandable}}
61
62 == SSH ==
63
64 Hinweis: Man kann jetzt auch mit SSH clonen. Da gitlab aber hinter einem Reverseproxy liegt, geht das nur mit der direkten Adresse des Host:  vmisdata07.uni-oldenburg.de. Ist nun auch in Gitlab zu konfiguriert:
65
66 == Nach dem Klonen ==
67
68 sollten Sie einen Bildschirm ähnlich zu dem folgenden sehen:
69
70 [[image:1755245980026-164.png]]
71
72 Auf dem main-Branch (master) kann keine Änderung gemacht werden, deswegen muss auf einen anderen Branch gewechselt werden. Im Beispiel development.
73
74 [[image:1755245996886-733.png]]
75
76 == Initialer Maven-Build und Codegenerierung ==
77
78 Nach einem frischen Checkout fehlen zunächst generierte Quellen. Führen Sie deshalb einen Maven-Build aus. Eine erneute Generierung ist insbesondere notwendig, wenn die OpenAPI-Beschreibung geändert wurde oder generierte Quellen fehlen.
79
80 [[image:1755246008466-477.png]]
81
82
83 [[image:1755246018789-616.png]]
84
85
86 == Lombok-Plugin ==
87
88 Falls das Lombok-Plugin noch nicht installiert ist, installieren bzw. aktivieren Sie es in IntelliJ.
89
90 [[image:1755248508652-523.png]]
91
92 Je nach IntelliJ-Edition kann zusätzlich das Spring-/Spring-Boot-Plugin hilfreich sein.
93
94 [[image:1756886220468-891.png]]
95
96 == Server starten ==
97
98 Den Serverbereich aufklappen und dort auf die Datei ServerApp mit der rechten Maustaste klicken.
99
100 [[image:1755246035428-328.png]]
101
102
103 Falls IntelliJ nach dem Start Annotation Processing für Lombok anbietet, aktivieren Sie es. Ohne korrekt eingerichtetes Lombok bzw. Annotation Processing werden Änderungen gegebenenfalls erst nach einem erneuten Maven-Build korrekt erkannt.
104
105 [[image:1755246072443-191.png]]
106
107
108 [[image:1755246118807-452.png]]
109
110
111 == Logging umstellen ==
112
113 {{expandable summary="Schritt-für-Schritt: Logging konfigurieren"}}
114 Wenn man möchte, kann man das Logging umstellen.
115
116 [[image:1755246135109-325.png]]
117
118
119 [[image:1755246147827-679.png]]
120
121
122 [[image:1755246162330-595.png]]
123 {{/expandable}}
124
125 == Development-Profil aktivieren ==
126
127 {{expandable summary="Schritt-für-Schritt: Development-Profil aktivieren"}}
128 Für lokale Tests existiert das Spring-Profil `dev`. Darin werden automatisch vorbereitete Testnutzer (`user1` bis `user9`) angelegt, sodass nicht für jeden Testlauf neue Konten registriert werden müssen.
129
130 Wenn man die Anwendung einmal gestartet hat, kann man dies Configuration anpassen:
131
132 [[image:1757399848941-253.png||height="209" width="558"]]
133
134 [[image:1755246173415-934.png]]
135
136
137 Wenn die verwendete IntelliJ-Version keine Spring-Unterstützung bietet, kann das Profil über eine Umgebungsvariable in der Server-Konfiguration gesetzt werden:
138
139 **SPRING_PROFILES_ACTIVE=dev**
140
141 [[image:1755248752596-839.png]]
142
143 Danach muss man den Server neu starten!
144 {{/expandable}}
145
146 == Client starten ==
147
148 Wenn der Server gestartet ist, kann man mehrere Clients starten. Dafür auf jeden Fall die Klasse Main verwenden.
149
150 {{warning}}
151 Falls der Start fehlschlägt, prüfen Sie insbesondere die tatsächlich verwendete Java-Version. Für das Basisprojekt wird mindestens **Java 21** benötigt.
152 {{/warning}}
153
154 [[image:1755246257400-525.png]]
155
156
157 [[image:1755246212916-883.png]]
158
159
160 [[image:1755246223246-834.png]]
161
162
163 === Mehrere Instanzen des Clients ermöglichen ===
164
165 {{expandable summary="Schritt-für-Schritt: mehrere Client-Instanzen starten"}}
166 Standardmäßig erlaubt IntelliJ nicht das Starten mehrerer Clients. Man könnte nun mehrere Configurations für den Client anlegen. Man kann aber auch in der Konfiguration unter "Modify options" den Haken bei "Allow multiple instances" setzen. Dann kann eine beliebige Anzahl von Clients gestartet werden.
167
168 [[image:1755246233218-893.png]]
169
170
171 Falls die Anmeldung eines vorbereiteten Testnutzers fehlschlägt, prüfen Sie insbesondere, ob das `dev`-Profil aktiv ist und der Benutzer angelegt wurde. Läuft der Server nicht, erscheint in der Regel eine andere Fehlermeldung.
172
173 [[image:1755246292057-581.png]]
174 {{/expandable}}
175
176 = Überblick über das Basisprojekt =
177
178 [[image:1755249096987-249.png]]
179
180
181 [[image:1755249136156-419.png]]
182
183
184 == Projektstruktur ==
185
186 [[image:1755249228556-469.png]]
187
188
189 = Kommunikation vom Client zum Server: REST =
190
191 [[image:1755249285866-367.png]]
192
193 Für klassische Request/Response-Operationen verwendet das Basisprojekt **REST über HTTP**. Als Austauschformat wird **JSON** verwendet. Die zentrale Spiellogik verbleibt auf dem Server.
194
195 = OpenAPI =
196
197 {{info}}
198 Die grafische OpenAPI-Darstellung hängt von der verwendeten IntelliJ-Edition und den installierten Plugins ab. Falls sie nicht verfügbar ist, kann ein geeignetes OpenAPI-Plugin installiert werden.
199 {{/info}}
200
201 {{info}}
202 Es gibt (als Beta-Version) ein Plugin für IntelliJ mit dem die Berbeitung, gerade zu Anfang hoffentlich etwas einfacher funktioniert. Zu finden ist das Plugin hier: https://swl.informatik.uni-oldenburg.de/swp/downloads/openapi/ (Achtung! Muss von der Platte installiert werden. Siehe https://www.jetbrains.com/help/idea/managing-plugins.html#install_plugin_from_disk
203 {{/info}}
204
205 [[image:1755250026156-269.png]]
206
207 [[image:1755250050031-304.png]]
208
209 * **Paths**: Endpunkte der API (z.B. /users, /lobbies).
210 * **Operations**: Spezifikation von Methoden wie GET, POST.
211 * **Schemas**: Beschreibung der Datenstrukturen für Ein- und Ausgaben.
212 * **Security**: Authentifizierungsmechanismen.
213
214 [[image:1755250061990-172.png]]
215
216 OpenAPI-Dokumente können in JSON oder YAML formuliert werden. **YAML** steht heute rekursiv für „YAML Ain't Markup Language“ und ist für menschenlesbare Konfigurations- und Beschreibungsdateien häufig kompakter als JSON.
217
218 [[image:1755250157536-746.png]]
219
220 Die aktuelle Version des OpenAPI Dokumentes findet sich im Basisprojekt 2 [[https:~~/~~/gitlab.swl.informatik.uni-oldenburg.de/SPB/SWPBasisprojekt2/-/blob/master/openapi.yaml?ref_type=heads>>https://gitlab.swl.informatik.uni-oldenburg.de/SPB/SWPBasisprojekt2/-/blob/master/openapi.yaml?ref_type=heads]]
221
222 Dort wird die Datei auch grafisch dargestellt.
223
224
225 = Maven und OpenAPI =
226
227 Die OpenAPI-Datei kann verwendet werden, um Teile der [[REST-Schnittstelle>>doc:Main.Basisprojekt.WebHome||anchor="HErweiterungderREST-Schnittstelle"]] zu generieren. Dafür wird der OpenAPI Generator eingesetzt [[https:~~/~~/github.com/OpenAPITools/openapi-generator>>https://github.com/OpenAPITools/openapi-generator]]
228
229 Die Generierung kann über die Kommandozeile erfolgen; im Basisprojekt ist sie bereits in den Maven-Build integriert.
230
231 Dafür ist in den Maven-Dateien bereits das OpenAPI Generator Plugin integriert. Da im Client und im Server unterschiedliche Arten verwendet werden, erfolgt die Konfiguration im Client und im Server unterschiedlich:
232
233 == Client ==
234
235 Im Java-Client wird ein HTTP-Client für den Zugriff auf die generierte API verwendet.
236
237
238 [[image:1756887005209-855.png]]
239
240 == Server ==
241
242 Auf der Serverseite werden Spring-/Spring-Boot-kompatible Schnittstellen und Controller-Strukturen generiert.
243
244 [[image:1756887037619-847.png]]
245
246 {{info}}
247 Weiterführende technische Konzepte des Basisprojekts sind insbesondere **Lombok**, **Dependency Injection** und **Spring Boot**. Für Spring bietet z. B. der folgende Leitfaden eine ausführlichere Einführung: [[Spring Framework Guide>>url:https://www.marcobehler.com/guides/spring-framework]].
248 {{/info}}
249
250
251
252 = Erweiterung der REST-Schnittstelle =
253
254 {{expandable summary="Ausführliches Beispiel: REST-Schnittstelle erweitern"}}
255 In diesem Beispiel wird einmal gezeigt, wie die REST-Schnittstelle des Basisprojektes einfach erweitert werden kann.
256
257 In diesem Beispiel soll die aktuelle Schnittstelle um die Möglichkeit erweitert werden, alle Lobbies vom Server zu bekommen.
258
259 == Schritt 1: OpenAPI-Dokument erweitern ==
260
261 Um diese neue Funktion sowohl im Client als auch im Server verwenden zu können, ist es notwendig, diese neue Funktion im OpenAPI-Dokument zu definieren.
262
263 Die Funktion soll sehr einfach sein und keine Parameter verlangen. Dafür bietet sich die GET-Funktion an.
264
265 Im folgenden Bild sind alle Anpassungen zu sehen:
266
267 [[image:1756887436525-790.png||height="355" width="974"]]
268
269
270 Nach dem Speichern, sollte das OpenAPI-Dokument wie folgt aussehen
271
272 [[image:1756887488020-376.png||height="642" width="904"]]
273
274
275 Jetzt kann man entweder in IntelliJ
276
277 [[image:1756888245896-845.png||height="347" width="620"]]
278
279 oder im Terminal (z.B. auch in IntelliJ)
280
281 [[image:1756888279902-777.png||height="637" width="1053"]]
282
283 Wobei hier auch clean compile reichen würde.
284
285 **ACHTUNG! Falls maven Problem macht, kann das auch an einer falschen Java-Version im System liegen (siehe auch [[FAQ>>doc:.Basisprojekt FAQ.WebHome]])**
286
287 Es werden durch den Aufruf neue Inhalte generiert (bzw. die alten überschrieben).
288
289 [[image:1756888428042-802.png||height="538" width="1077"]]
290
291 Hinweis: Niemals Änderungen unterhalb des target-Ordners machen. Das wird von Maven bei clean gelöscht.
292
293 === Wo wird die eigentliche Funktionalität implementiert? ===
294
295 Für jeden API-Bereich (z. B. `lobbies` und `users`) werden serverseitig typischerweise mehrere Schnittstellen bzw. Klassen generiert:
296
297 * *Api (z.B, LobbiesApi): Beschreibung der REST-Methoden, vor allem auch das Mapping von z.B. /lobbies/join auf die Methode lobbyJoin(String)
298 * (((
299 *ApiController implements *Api (Für Spring) (z.B. LobbiesApiController)
300 )))
301 * (((
302 * `*ApiDelegate` (z. B. `LobbiesApiDelegate`): Delegationsschnittstelle. Die fachliche Implementierung erfolgt **im eigenen, nicht generierten Code**.
303 )))
304
305
306
307 == Schritt 2: Erweiterung auf Server-Seite ==
308
309 Da es schon Funktionen für die Lobbies gibt, gibt es auch bereits eine Implementierung, die LobbiesApiDelegate überschreibt
310
311 [[image:1756888762381-912.png||height="48" width="789"]]
312
313 Für die fachliche Umsetzung wird ein eigener Service bzw. eine passende Delegate-Implementierung verwendet. Soll die Klasse von Spring verwaltet werden, muss sie als Spring-Komponente im Application Context registriert sein.
314
315 In der Klasse muss man dann die neue Methode lobbyList aus der API überschreiben.
316
317 [[image:1756888929507-312.png||height="156" width="1161"]]
318
319 Dabei wird folgendes gemacht:
320
321 1. Es wird ein Rückgabeobjekt vom Typ Liste erzeugt
322 1. Es wird über alles Lobbies auf dem Server gegangen (lobbyManagement.getLobbies())
323 1. Da der Client u.U. nicht die vollständigen Informationen über die Lobbies bekommen soll, gibt es zwei unterschiedliche Klassen: ServerLobby und LobbyDTO.
324 1. Die Foreach-Schleife sorgt dafür, dass in das Rückgabeobjekt nur die LobbyDTOs eingefügt werden.
325 1. Dafür wird eine Funktion mit dem Namen lobbyMapping verwendet
326 1. Schließlich wird am Ende gesagt, dass alles ok ist und eine Antwort ResponseEntity.ok mit dem Rückgabeobjekt (lobbies) gesendet.
327
328 **Anmerkung**: Das Basisprojekt ist aktuell so eingerichtet, dass Spring Exceptions auffängt und entsprechend an den Client leitet. Diese findet in der Klasse  GlobalExceptionHandler statt
329
330 Auf Server-Seite fehlt jetzt noch die Methode getLobbies im LobbyManagement
331
332 [[image:1756889590500-656.png||height="81" width="518"]]
333
334
335 === LobbyMapping ===
336
337 Da interne Serverobjekte häufig in DTOs überführt werden müssen, verwendet das Basisprojekt **MapStruct**. Die DTOs werden in der Regel aus der OpenAPI-Beschreibung generiert; das Mapping zwischen internem Modell und DTO wird im eigenen Code definiert.
338
339 Also z.B.
340
341 [[image:1756889440395-856.png]]
342
343 und definiert ein Interface mit einer Annotation
344
345 [[image:1756889472103-847.png]]
346
347 und damit kann man die Funktion aufrufen. Hinweis: Der Mapper ist im LobbyService über die Spring Dependency Injection gebunden.
348
349 == Schritt 3: Erweiterung auf Client-Seite (Java) ==
350
351 {{info}}
352 Dieses Beispiel bezieht sich auf den Java-Client. Bei Web-Clients, z. B. mit Angular oder React, unterscheidet sich die konkrete technische Integration; der OpenAPI-Vertrag bleibt jedoch derselbe.
353 {{/info}}
354
355 Auf der Client-Seite wird die komplette Kommunikation mit dem Server in der generierten Klasse DefaultApi gekapselt.
356
357 [[image:1756889795622-530.png]]
358
359 Dort gibt es eine neue Methode lobbyList. Die sorgt dafür, dass der REST-Aufruf auf die Server-Seite geht und liefert das passende Objekt List<LobbyDTO> zurück
360
361 Im Client gibt es auch eine Klasse LobbyService. Dort ist die DefaultApi Klasse über Dependency Injection gebunden.
362
363 [[image:1756889917681-650.png]]
364
365 Dort kann man nun eine neue Methode getLobbies() integrieren:
366
367 [[image:1756889979252-910.png]]
368
369 Und das Ganze dann z.B. im MainMenuPresenter verwenden:
370
371 [[image:1756890010118-149.png||height="116" width="972"]]
372
373 Anmerkung: Obwohl DefaultApi alle Funktionen zum Server kapselt, sollte man im Client spezifische Services für bestimmte Bereich haben, die diese Klasse verwenden.  Das führt zu einer besseren Trennung von Funktionalitäten im Code.
374 {{/expandable}}
375
376 = Asynchrone Kommunikation zum Client: WebSockets =
377
378 [[image:1756890800817-370.png||height="604" width="1121"]]
379
380 Für klassische REST-Aufrufe initiiert der Client die Anfrage. Muss der Server Clients **asynchron über Ereignisse oder Zustandsänderungen informieren**, verwendet das Basisprojekt WebSockets.
381
382 Spring bietet eine native Unterstützung von WebSockets. Für eigene Funktionen kann man sich in die Kommunikation über die Serverklasse WebSocketHandler einklinken
383
384
385 [[image:1756890924024-346.png||height="377" width="1092"]]
386
387
388 Sobald sich jemand beim Server für WebSockets angemeldet hat wird von Spring ein org.springframework.web.socket.messaging.SessionConnectedEvent
389 geworfen, welches in der folgenden Methode (im WebSocketHandler) aufgefangen wird
390
391 [[image:1756890958794-603.png||height="373" width="1087"]]
392
393 Die Methode ist Observer für das Event SessionConnectedEvent
394
395 Der WebSocketServer kennt die Nutzer und erlaubt das Einloggen nur, wenn Login und Passwort stimmen (durch Spring Security)
396
397 [[image:1756891019715-621.png]]
398
399 1)Aus dem Event kann der Nutzer gelesen werden (der sollte nie leer sein)
400
401 2) Dann wird sich aus dem Repository (später mehr) der Nutzer geholt, der durch den Namen identifiziert ist (z.B. „test1“)
402
403 3) Schließlich werden allen anderen darüber informiert, dass ein neuer Nutzer da ist
404
405 == STOMP ==
406
407 WebSocket stellt einen bidirektionalen Kommunikationskanal bereit. Für eine strukturierte Nachrichtenkommunikation verwendet das Basisprojekt darüber **STOMP (Streaming Text Oriented Messaging Protocol)**.
408
409 STOMP definiert u. a. Operationen wie `CONNECT`, `SEND` und `SUBSCRIBE` und arbeitet mit Topics. Ein Client kann ein Topic abonnieren und erhält anschließend Nachrichten, die der Server auf diesem Topic veröffentlicht.
410
411
412 Veröffentlicht der Server eine Nachricht auf einem Topic, erhalten sie die dafür registrierten Clients. Dieses Modell entspricht dem **Publish/Subscribe-Pattern**.
413
414 [[https:~~/~~/docs.spring.io/spring-framework/reference/web/websocket/stomp.html>>url:https://docs.spring.io/spring-framework/reference/web/websocket/stomp.html]]
415
416
417 Der Server definiert je nach fachlichem Bereich unterschiedliche Topics. Für das Nutzermanagement sind beispielsweise vorgesehen:
418
419 * `/topic/users/loggedIn`: Ein Nutzer hat sich angemeldet.
420 * `/topic/users/loggedOut`: Ein Nutzer hat sich ausgeloggt.
421
422 [[image:1756891125969-748.png||height="317" width="726"]]
423
424 Topic-Namen sind Strings, sollten aber einem konsistenten fachlichen Namensschema folgen. Für Lobby-Ereignisse bietet sich entsprechend `/topic/lobbies/...` an.
425
426 == WebSockets: Versenden von Nachrichten ==
427
428 [[image:1756891180516-843.png||height="426" width="801"]]
429
430 [[image:1756891216134-578.png||height="428" width="699"]]
431
432 == Nachrichteninhalt ==
433
434 [[image:1756891254830-647.png||height="101" width="777"]]
435
436 * message kann grundsätzlich alles sein, was serialisiert werden kann
437 * Technisch könnte Java-Serialisierung verwendet werden; das alte Basisprojekt hat dies teilweise getan.
438 * Das hat aber eine Reihe von Nachteilen
439 ** Der Empfänger muss dafür unbedingt auch ein Java-Client sein und er muss exakt dieselbe Klasse bei sich haben, damit der das Objekt wieder zurück in ein Java-Objekt umwandeln kann
440 ** Es gibt eine Reihe von Sicherheitsproblemen
441 * Besser ist ein technologieunabhängigeres Austauschformat. Im Basisprojekt wird deshalb JSON verwendet.
442 * Insbesondere Web-Clients (JavaScript) bieten hervorragende Möglichkeiten, an JSON zu verarbeiten
443 * Client und Server haben sich damit auf Format für den Austausch geeinigt
444 ** Topic: Strings
445 ** Message: JSON
446
447 Auch über WebSockets werden an Clients nur geeignete DTOs übertragen; interne Serverobjekte bleiben serverintern.
448
449 [[image:1756891375095-158.png||height="266" width="775"]]
450
451 == Wie verbindet sich ein Client mit dem Server? ==
452
453 {{expandable summary="Technische Details zum Verbindungsaufbau"}}
454 Der `UserService` bietet die Anmeldung an. Im Basisprojekt erfolgt sie beim Aufbau der WebSocket-/STOMP-Verbindung; die Zugangsdaten werden dabei über die bestehende Sicherheitskonfiguration geprüft.
455
456 [[image:1756891512330-186.png||height="170" width="820"]]
457
458 === Auf Client-Seite: WebSocketConnectionManager ===
459
460 [[image:1756891551794-161.png||height="387" width="1019"]]
461
462 1) Variablen definieren
463
464 2) WebSocketClient erzeugen
465
466 3) Daraus WebSocketStompClient machen
467
468 4) Jackson als Mapper definieren (DTO-Object <-> JSON)
469
470 [[image:1756891617399-232.png||height="289" width="1006"]]
471
472
473 1) Asynchron die Verbindung zum Server aufbauen
474
475 2) Wenn erfolgreich in das Hauptmenü wechseln (showScene à später mehr)
476
477 3) Über den Kontext ein Event pushen LoggedInEvent
478
479 4) Jede Serververbindung hat eine Session
480 {{/expandable}}
481
482 = Siehe auch =
483
484 * [[Stichwortverzeichnis>>doc:Main.Index.WebHome]]
485 * [[Glossar>>doc:Main.Glossar.WebHome]]
486 * [[Basisprojekt FAQ>>doc:Main.Basisprojekt.Basisprojekt FAQ.WebHome]]