# Websocket.jar funktioniert nur teilweise



## SyntaxTalksToMe (2. Dez 2019)

Guten Tag,

ich wollte nun meinen Chat etwas umbauen, damit der Client über Websockets nachrichten an den anderen Client verschicken kann. Ich nutze als Server einen Tomcat-Server.

Dafür, habe ich mir diese Jar runtergeladen:
*Java-WebSocket-1.3.8.jar*

Nachdem ich die .jar Datei u.a. dem Projekt hinzugefügt habe, funktionieren zwar die Annotationen wie
@OnOpen, @OnClose ect.

Allerdings die @ServerEndpoint Annotation funkioniert nicht und wird rot unterkringelt.


```
@ServerEndpoint("/websocketendpoint")
public class WsServer {

}
```

Mein Gefühl sagt mir aber, dass das ganze was ich da getan habe, schon veraltet ist und mittlerweile völlig anders läuft. Denn die Jar, fand ich auf einer weniger vertrauenserweckenden Seite und über Oracle bekommt man diese offenbar nur, wenn man sich registriert.

Oder gibts da noch eine weitere .Jar Datei die ich brauche für den Server?

Erleuchtet mich bitte


----------



## mihe7 (2. Dez 2019)

SyntaxTalksToMe hat gesagt.:


> Dafür, habe ich mir diese Jar runtergeladen:


Je nachdem, was Du für ein Buildsystem nutzt bzw. Du an Abhängigkeiten eingestellt hast, brauchst Du keine zusätzlichen Jars. Ansonsten sollte es z. B. bei Maven reichen:

```
<dependency>
    <groupId>javax.websocket</groupId>
    <artifactId>javax.websocket-api</artifactId>
    <version>1.1</version>
    <scope>provided</scope>
</dependency>
```
der pom.xml hinzuzufügen. TomCat implementiert die API bereits, so dass sie nicht mit der Anwendung ausgeliefert werden muss.


----------



## SyntaxTalksToMe (2. Dez 2019)

Das heißt, die Annotation ist dann quasi überflüssig? Denn ich nutze ja Tomcat. Und ich nutze eigentlich auch JavaEE. Das müsste ja dann alles von alleine laufen ... Hach... Wenn ich die Zeit zum coden verwenden könnte was ich jedes mal an Zeit brauche diesen Rotz einzurichten.


----------



## mrBrown (2. Dez 2019)

SyntaxTalksToMe hat gesagt.:


> Das heißt, die Annotation ist dann quasi überflüssig? Denn ich nutze ja Tomcat. Und ich nutze eigentlich auch JavaEE. Das müsste ja dann alles von alleine laufen ... Hach... Wenn ich die Zeit zum coden verwenden könnte was ich jedes mal an Zeit brauche diesen Rotz einzurichten.


Nein - die Annotationen brauchst du. Aber dann die richtige aus javax.websocket-api, die Lib die du eingebunden hast, hat damit nichts zu tun.

Was du nicht brauchst, ist irgendeine Jar die du per Hand irgendwo ablegst. Um javax.websocket-api zu nutzen, bindest du die Dependency über dein Build-System ein. Wenn du händisch was mit irgendwelchen jars machst, machst du nahezu immer was falsch.


----------



## mihe7 (2. Dez 2019)

Nein, die Annotation ist schon richtig, es geht nur um die Jar.



SyntaxTalksToMe hat gesagt.:


> Und ich nutze eigentlich auch JavaEE. Das müsste ja dann alles von alleine laufen



Ja, WS sind Teil von JavaEE. 



SyntaxTalksToMe hat gesagt.:


> Wenn ich die Zeit zum coden verwenden könnte was ich jedes mal an Zeit brauche diesen Rotz einzurichten.



Nimm Maven. Mein Beispiel-POM fürs Forum sieht z. B. so aus und mehr brauchst Du für Java EE nicht:

```
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.javaforum</groupId>
    <artifactId>jpa</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>war</packaging>
    <dependencies>
        <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-api</artifactId>
            <version>7.0</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <finalName>jpa</finalName>
    </build>
    <properties>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
        <failOnMissingWebXml>false</failOnMissingWebXml>
    </properties>
</project>
```
Projekt anlegen:

```
mkdir projektname
cd projektname
cp ../vorlagen/pom.xml .
mkdir -p src/{test,main}/java
```
Fertig.

In der IDE: Maven-Projekt erstellen, Inhalt der POM überschreiben, wenn der nicht sowieso schon passt, fertig.


----------



## mrBrown (2. Dez 2019)

mihe7 hat gesagt.:


> ```
> <artifactId>javaee-api</artifactId>
> <version>7.0</version>
> 
> ...


Willkommen in 2019


----------



## mihe7 (2. Dez 2019)

mrBrown hat gesagt.:


> Willkommen in 2019


Ich hab gewusst, dass bzgl. der Versionen etwas kommt


----------



## SyntaxTalksToMe (2. Dez 2019)

Trotz auf die Gefahr hin gleich geschlagen zu werden   :

Ich habe noch nie Maven genutzt und hatte es mir noch nicht angeschaut.

Was ich bisher gelesen habe und sofern ich es richtig verstanden habe, ist es der Traum eines jeden Java-Users?  Es vereinheitlicht alles, so dass umständliche Versionsunterschiede/Konflikte umschifft werden?

Aber danke euch Leute. Mit dem MavenProjekt ging es auf anhieb. Jetzt gehts auch mit dem ServerEndpoint. Und siehe da: Jetzt sehe  ich auch diese POM XML Datei


----------



## LimDul (2. Dez 2019)

SyntaxTalksToMe hat gesagt.:


> Trotz auf die Gefahr hin gleich geschlagen zu werden   :
> 
> Ich habe noch nie Maven genutzt und hatte es mir noch nicht angeschaut.
> 
> ...


Traum würde ich nicht sagen, man erschafft sich auch gerne mit Maven eine Dependency Hölle - insbesondere wenn man ein Projekt mit submodulen hat und es nicht sauber strukturiert.

Aber es erleichtert sehr viel, da man sich so um deutlich weniger Gedanken machen muss. Insbesondere sorgt es dafür, dass alle Abhängigkeiten aufgelöst werden und am Ende das richtige jar/war/ear/.... rauspurzelt.


----------



## mihe7 (2. Dez 2019)

SyntaxTalksToMe hat gesagt.:


> Was ich bisher gelesen habe und sofern ich es richtig verstanden habe, ist es der Traum eines jeden Java-Users?


Das jetzt nicht gerade, aber im EE-Umfeld ist Maven (noch) der Standard, wobei auch hier Gradle auf dem Vormarsch ist.

Ursprünglich musste man auch unter Java mit batch-Dateien oder Makefiles arbeiten, dann kam ant, das ähnlich wie make zu verstehen ist aber als Java-Anwendung plattformunabhängig ist und aufgabenorientiert arbeitet. 

Nun hat man über die Zeit erkannt, dass die Projekte immer vor ähnlichen Problemen standen, die Entwickler rumkonfigurieren mussten, dass für einen Build mehr oder weniger immer die gleichen Aufgaben zu erledigen sind usw.

Beispielsweise muss bei ant (ohne Ivy) der Entwickler sich die notwendigen Jars selbst besorgen, im build.xml (von ant) muss angegeben werden, wo die Bibliotheken zu finden sind. Dann müssen Tasks für die Übersetzung, das Generieren von JARs/WARs/EARs, JavaDocs, usw. erstellt werden. Immer das Gleiche.

Mit Maven hat man dann die Idee Convention over Configuration umgesetzt. Standardmäßig werden (von den jeweiligen Plugins) bestimmte Dinge angenommen, z. B. die Verzeichnisstruktur oder welche Phasen in einem Build durchlaufen werden. 

Ebenfalls ist klar, dass kaum ein Projekt ohne externe Abhängigkeiten auskommt. Daher verwaltet Maven die Abhängigkeiten in einem lokalen Repository. Hat man im Projekt eine Abhängigkeit deklariert, die dort nicht zu finden ist, versucht Maven, die benötigten Artefakte (poms, jars, ...) aus einem remote Repository zu laden usw.

Der Ansatz von Maven erleichtert vieles, macht manche Dinge aber auch sehr kompliziert, die z. B. in ant kein Problem darstellen.


----------



## SyntaxTalksToMe (2. Dez 2019)

Ich danke für die Ausführungen. Sie gaben mir einen guten Einblick. Nachdem ich von C# zu Java gewechselt bin, hatte ich mit JavaFX angefangen. Aber gerade für Neulinge in Punkto Java, sind diese .jar geschichten in ihren unendlichen Ausführungen und Versionen etwas erschlagend.
Ich bin ja froh, dass sich der Java-Wald sich bei mir jetzt langsam gelichtet hat und ich zumindest eine Überblick bekommen habe, was es alles so gibt und wo die Unterschiede liegen. Jemand der jahrelang Java nutzt, merkt das vermutlich nicht mehr bzw nimmt das alles für selbstverständlich hin.

Ich hatte mir am Anfang gesagt, ich lerne zuerst dass eine, dann das andere. Aber so funktioniert es nicht. Wenn man eine Anwendung schreibt hat man diverse Vorstellungen. Möchte man diese umsetzen, muss man sich gleichzeitig mit vielen Dingen beschäftigen.

Aber das sind Erfahrungen, die man einfach selbst machen muss.

Und ich möcht enochmal wiederholen: Ich danke euch allen für eure Antworten


----------



## SyntaxTalksToMe (3. Dez 2019)

Kann man in der Web.xml auch definieren, wo nach den Servlets gesucht werden? Oder macht man das eher in der POM.xml.


----------



## mihe7 (3. Dez 2019)

SyntaxTalksToMe hat gesagt.:


> Kann man in der Web.xml auch definieren, wo nach den Servlets gesucht werden?


Wie meinen?


----------



## SyntaxTalksToMe (3. Dez 2019)

Ok, ich habs hinbekommen.

Aber ich hätte noch ein paar Fragen zu dieser Sache, was aber auch generell gilt. Denn es bringt mir persönlich wenig, Tutorials zu folgen, wenn ich denn dann überhaupt nicht weiß, warum ich tue was ich tue 

Dazu ein paar Fragen:

1. Was genau tut diese Group ID bei Maven und die Artifiact ID? Ist das sowas wie ein Workspace im Workspace? Also quasi ein Workspace für Maven?

2. Ich hatte ein Problem, dass die Servlets von den HTML Dateien nicht gefunden worden sind. Ich weiß, dass Dateien, nicht außerhalb des Build-Paths liegen sollen. Beispielsweise die Servlets. Man kann sich ja eine Package-Struktur anlegen, um Ordnung zu halten. Aber wo kann man einstellen, an welchen Ort nach beispielsweise Servlets gesucht werden soll?
Ich habe zuerst geguckt unter Project Properties -> Deployment Asssembly. Kann man da nach eigenen Gutdünken Ordner hinzufügen, damit diese mit in den Buildpath mit aufgenommen werden? Hierzu aber noch Frage 3. Aktuell habe ich die Servlets in /src/main/java/ drinnen und es funktioniert.

3. Ich hab gesehen, dass in der Web.xml auch Pfadangaben für die Servlets stehen. Ich habe allerdings festgstellt, dass ich  zwei web.xml Dateien habe. Einmal im Tomcat Verzeichnis und einmal in meiner MavenWebApp. Wie verhält sich das?

4. Ich hatte ein Test_Servlet in Maven erstellt um zu sehen, wo genau Eclipse dieses dann speichert. Anschließend hatte ich es wieder gelöscht. Kurz darauf merkte ich aber, dass das gelöschte Servlet noch immer in der Web.xml stand. Gibts da ein Trick, dass automatisch zu bereinigen?


----------



## LimDul (3. Dez 2019)

GroupId & ArtifactID zusammen kennzeichen das Maven-Artefakt eindeutig. Zusammen mit der Version ergibt sich dann ein eindeutiges Jar File. Deswegen ist die groupId in der Regel auch der Domainname des Entwicklers (in umgedrehter Form) um sicher zu sein, dass der weltweit eindeutig ist. Die ArtifictId kann man dann selber frei vergeben, die muss halt nur innerhalb der GroupId eindeutig sein.

Wenn du z.B. mal auf https://search.maven.org/  siehst, dass die ganzen Artefakte darüber eindeutig gekennzeichnet sind.


----------

