# Wie habt ihr Java EE gelernt?



## Kababär (30. Sep 2016)

Hi,

seit längerer Zeit gucke ich mir mal von Zeit zu Zeit immer mal Komponenten von Java EE an. Sei es Tomaten, Wildfly, Jenkins (heute mal drüber gestolpert) und andere Dinge wie Datenbanken (dazu auch XML und JSON), Frameworks, Testing (JUnit und Selenium) an.
Mir ist klar, dass der Aufwand zu groß ist, um ein solches Konstrukt privat einzurichten, zu warten und generell zu betreiben, denn ausliefern muss man ja an der Stelle nichts. 
Nur finde ich es sehr kompliziert, weil von jetzt auf gleich viele Komponenten aufeinander treffen und zusammen agieren müssen (Java, JavaScript, HTML 5, Server, Datenbanken, ...).
Und dann gibt es noch tausend andere Komponenten wie EJB, Servlets, Pages, Container, Faces, etc. 
ich habe Probleme damit, mir einen überblick über die Anforderungen, den Nutzen, die Zusammenarbeit und die Realisierung dieser Komponenten zu verschaffen. (Die Menge ist einfach gigantisch.)
Wie habt ihr es geschafft bzw wie seid ihr da ran gegangen?

Lohnt sich der Aufwand, so ein Java EE System zuhause einzurichten und damit zu spielen? Auf der Arbeit sind wir natürlich auch im EE Bereich tätig. Nur will ich schon was drauf haben und vieles verstanden habe, wenn ich mal damit konfrontiert werde bzw damit anfange.


----------



## thecain (1. Okt 2016)

Der Aufwand hält sich eigentlich recht im Rahmen, mit Docker etc... einfach nur noch die Applikation muss geschrieben werden.


----------



## stg (1. Okt 2016)

Kababär hat gesagt.:


> Tomaten



Tomaten?



Kababär hat gesagt.:


> Mir ist klar, dass der Aufwand zu groß ist, um ein solches Konstrukt privat einzurichten, zu warten und generell zu betreiben



Wovon redest du da?



Kababär hat gesagt.:


> Und dann gibt es noch tausend andere Komponenten wie EJB, Servlets, Pages, Container, Faces, etc.
> ich habe Probleme damit, mir einen überblick über die Anforderungen, den Nutzen, die Zusammenarbeit und die Realisierung dieser Komponenten zu verschaffen. (Die Menge ist einfach gigantisch.)
> Wie habt ihr es geschafft bzw wie seid ihr da ran gegangen?



Ich weiß nicht, was du dir da für Horrorszenarien ausmalst, aber ein Java EE Anwendungsserver ist im Grunde auch nur ein stink normales Java Programm. Die Installation beschränkt sich auf das bloße entpacken eines zip-files. Fertig. Klar, man kann da unendlich viel konfigurieren usw, aber für den Anfang ist das alles furchtbar egal.


[QUOTE="Kababär, post: 1103136, member: 29139"
Und dann gibt es noch tausend andere Komponenten wie EJB, Servlets, Pages, Container, Faces, etc.
ich habe Probleme damit, mir einen überblick über die Anforderungen, den Nutzen, die Zusammenarbeit und die Realisierung dieser Komponenten zu verschaffen. (Die Menge ist einfach gigantisch.)
Wie habt ihr es geschafft bzw wie seid ihr da ran gegangen?[/QUOTE]

Die Lernkurve ist am Anfang sehr steil, das stimmt. Es gibt unglaublich viel ... und das beinhaltet auch einen ganzen Haufen veraltete und/oder verworfene Konzepte. Kauf die ein aktuellen Buch zum Thema und arbeite das durch. Wenn du kein Buch kaufen willst, dann kannst du auch mit dem Oracla Java EE Tutorial anfangen.
Wie immer gilt aber auch: Nicht alles auf einmal versuchen. Auf was du dich zu Beginn konzentrieren willst, das hängt von deinen eigenen Präferenzen und Anforderungen ab, aber auch davon, was du schon kannst. Einen allgemeingültig besten Einstieg gibt es nicht, so etwas ist mMn immer ganz individuell zu betrachten. Und da wissen wir zu wenig über dich.


----------



## Kababär (1. Okt 2016)

stg hat gesagt.:


> Tomaten?


Meinte Tomcat. Auto-Korrektur meines "schlauen" Apfels. 



stg hat gesagt.:


> Wovon redest du da?


Ich ging bislang davon aus, dass man zig Konfigurationen und Programme/Frameworks installieren muss, eventuell einen eigenen Server einrichten, etc.
Jetzt habe ich Jenkins installiert (zuerst Tomcat, da wohl Jenkins in Tomcat läuft oder laufen kann). Wenn ich es jetzt noch hinkriege, Git mit Eclipse zu verbinden, kann ich, so wie es aussieht, einfach ein Link zum Git-Projekt oder die lokale Repo angeben.



stg hat gesagt.:


> Ich weiß nicht, was du dir da für Horrorszenarien ausmalst, aber ein Java EE Anwendungsserver ist im Grunde auch nur ein stink normales Java Programm. Die Installation beschränkt sich auf das bloße entpacken eines zip-files. Fertig. Klar, man kann da unendlich viel konfigurieren usw, aber für den Anfang ist das alles furchtbar egal.


Naja, bei Wildfly war die Installation unter Ubuntu schon etwas komplizierter. Jenkins und Tomcat waren da wesentlich einfacher. Ich glaube ich lasse erstmal alles auf dem localhost laufen, da muss ich weniger konfigurieren und kann erstmal alles so lassen.



stg hat gesagt.:


> Die Lernkurve ist am Anfang sehr steil, das stimmt. Es gibt unglaublich viel ... und das beinhaltet auch einen ganzen Haufen veraltete und/oder verworfene Konzepte. Kauf die ein aktuellen Buch zum Thema und arbeite das durch. Wenn du kein Buch kaufen willst, dann kannst du auch mit dem Oracla Java EE Tutorial anfangen.


Gestern Abend habe ich mir noch ein Buch gekauft "Java-Komponenten" von Rainer Öchsle. Da werden JavaBeans, Servlets, Applets, OSGi, Komponenten und Komponentensysteme behandelt.



stg hat gesagt.:


> Wie immer gilt aber auch: Nicht alles auf einmal versuchen.


Das ist mein größtes Problem, um ehrlich zu sein. Ich habe das Gefühl, ich müsse auf einen Schlag alles lernen (JSON scheint wohl oft mit Jenkins in Verbindung gebracht zu werden[öfters in Tutorials drüber gestoplert]). Aber nachdem ich mal Jenkins und Tomcat installiert habe, sehe ich, dass die Konfiguration über die .xml Dateien einfach zu bearbeiten ist und man eine schöne GUI im Browser hat.
Ich dachte immer, man müsse das "programm-spezifisch" konfigurieren (bspw. über die Shell service starten, projekt hochladen, maven goals spezifizieren, git einbinden, repo refreshen, etc, und das alles über die Shell).

Aber was ich mich frage: Tomcat ist ein Web-Server, heißt da kann ich Web-Applikationen laufen lassen und verteilen, so dass die Klienten das Programm nicht installieren müssen, sondern bspw nach einer Authentifikation das Programm im Browser laufen lassen können.
So.. heißt das, dass ich JavaFX Projekte nicht in Tomcat verwenden kann, sondern stattdessen auf Technologien wie HTML5, CSS, JavaScript ausweichen muss (da ja alles über Web läuft)?
Falls ja, folgert daraus, dass JUnit (damit teste ich immer) überflüssig ist und Selenium die bessere Wahl wäre, weil dieser ein Web-Driver ist/hat?

Ich glaube, wenn ich ein Tutorial oder so hätte, wo ich zugucken könnte, wie jemand ein Java Projekt in Jenkins, Git und Tomcat importiert, damit ich sehe, wie die Frameworks miteinander arbeiten, würde ich nicht so dämliche Fragen stellen. Mir fehlt einfach noch Wissen über den Workflow :/

Edit: 





> Es gibt unglaublich viel ... und das beinhaltet auch einen ganzen Haufen veraltete und/oder verworfene Konzepte.


Ja. REST scheint wohl aktuell zu sein und Java Single Pages (früher hat man mehrere Pages genommen oder so?).


----------



## stg (1. Okt 2016)

Weder Selenium, noch Git, noch Jenkins, noch Eclipse, noch maven, noch JUnit haben unmittelbar was mit Java EE am Hut. Du schmeißt hier einfach wirklich alles durcheinander..
Selenium ist ein FrameWork zur Browser-Steuerung. Insbesondere geeignet, um Web-GUI zu testen.
Git ist eine Versionsverwaltung.
Jenkins ist ein Build-Server
Eclipse ist eine IDE.
JUnit ist ein Framework für Unit-tests.
All das wirst du sicherlich (irgendwann einmal) verwenden wollen, wenn du Java EE Anwendungen entwickelst, es ist aber dennoch vollkommen unabhängig von all dem. All das wirst du ja sicherlich auch einsetzen, wenn du "normale" Java-Programme schreibst, oder Handy-Apps oder sonst was. Aber dennoch geht es natürlich auch komplett ohne. Jedes Thema für sich ist es wert, dass man sich darin einarbeitet. Aber wenn du das alles gleichzeitig lernen willst, dann wird das nichts geben.
Wenn du Git schon kennst, dann benutzt es genau so wie vorher auch. Da ändert sich nichts. Wenn nicht, dann mach dir klar, was du als erstes lernen willst. Ist es das Arbeiten mit einer Versionsverwaltung (und was das überhaupt ist) oder doch lieber was anderes?! Gleiches gilt für die anderen...




Kababär hat gesagt.:


> Gestern Abend habe ich mir noch ein Buch gekauft "Java-Komponenten" von Rainer Öchsle. Da werden JavaBeans, Servlets, Applets, OSGi, Komponenten und Komponentensysteme behandelt.



Ich kenne das Buch nicht, aber wenn es Applets behandelt, dann stammt es wohl aus einem vorherigen Jahrtausend.



Kababär hat gesagt.:


> Aber was ich mich frage: Tomcat ist ein Web-Server, heißt da kann ich Web-Applikationen laufen lassen und verteilen, so dass die Klienten das Programm nicht installieren müssen, sondern bspw nach einer Authentifikation das Programm im Browser laufen lassen können.
> So.. heißt das, dass ich JavaFX Projekte nicht in Tomcat verwenden kann, sondern stattdessen auf Technologien wie HTML5, CSS, JavaScript ausweichen muss (da ja alles über Web läuft)?


Die Programme laufen nicht beim Client im Browser, sondern zentral auf dem Anwendungsserver. Deiner Aussage entnehme ich, dass dir das Konzept "Web-Anwendung" gar nicht wirklich klar ist. Bevor du dich an die Entwicklung solcher Anwendungen wagst sollten Grundlagen über Web-Protokolle, Aufbau von HTTP requests, HTML, CSS, JS usw auf jeden Fall sitzen.
Tomcat ist auch kein Java EE Anwendungsserver und auch kein reiner Web Server, sondern (in erster Linie) ein Servlet-Container.



> Falls ja, folgert daraus, dass JUnit (damit teste ich immer) überflüssig ist und Selenium die bessere Wahl wäre, weil dieser ein Web-Driver ist/hat?


Nein, das folgt natürlich nicht. Das sind zwei vollkommen verschiedene Frameworks mit vollkommen verschiedenen Aufgaben.




> Ja. REST scheint wohl aktuell zu sein und Java Single Pages (früher hat man mehrere Pages genommen oder so?).


Ganz allgemein beinhaltet Java EE einen ganzen Haufen an Spezifikationen zu WebServices. Da gehören natürlich auch REST Web Services mit dazu.
Was Java Single Pages sein sollen, weiß ich nicht. Den Begriff hab ich noch nie gehört. Vielleicht meinst du JSP. Das steht aber für Java Server Pages und ist seit vielen Jahren bereits von Oracle als deprecated eingestuft.


----------



## Kababär (1. Okt 2016)

Ohwei, da habe ich wirklich alles durcheinander gehauen.
Ok, ich muss mir erstmal die Grundlagen aneignen für HTTP, CSS, JS (da gibt es auch JSNode habe ich gelesen).

Und vor allem muss ich mir mal aneignen, mit was ich es dann jeweils zu tun habe. Also was Frameworks, Web-Server, Builder, etc sind.Vielleicht wird mir das dann auch mal klarer 

Ich traue mich gar nicht mehr irgendwas zu schreiben ohne es vorher gegoogelt zu haben  Ist ja schon etwas peinlich.



stg hat gesagt.:


> JUnit ist ein Framework für Unit-tests.


Mit JUnit kann ich aber auch Integration-Tests machen, oder? 
Edit: ok kann ich mir selbst beantworten. 



stg hat gesagt.:


> Vielleicht meinst du JSP.


Genau das hab ich gemeint.

Ich danke dir für deine etlichen Bemühungen und Erklärungen 



stg hat gesagt.:


> Ich kenne das Buch nicht, aber wenn es Applets behandelt, dann stammt es wohl aus einem vorherigen Jahrtausend.


Schade. Das Buch war relativ teuer, aber naja. Dann werde ich mir ein anderes kaufen


----------



## thecain (1. Okt 2016)

auf seinem Kanal hats auch noch einige andere Videos zu JEE, einige mehr fortgeschritten, einige weniger.

Ich würde versuchen beim Start nur weniges zu verwenden. Heisst: 
- Einfacher Server. Wildfly Glassfish o.ä. Tomcat ist für JEE ungeeignet, da es nur ein Servlet Container ist.
- Maven
- Wenn du willst JUnit, ist aber nicht JEE spezifisch.
Danach kannst du starten. JEE Tutorials gibts dann im Internet zu Hauf. Für die ersten Schritte würde ich auf ein Buch verzichten.


----------



## Kababär (1. Okt 2016)

Danke, das Video werde ich mir mal angucken!



thecain hat gesagt.:


> Einfacher Server. Wildfly Glassfish o.ä. Tomcat ist für JEE ungeeignet, da es nur ein Servlet Container ist.


Ehrlich gesagt finde ich diese Server-Sache sehr kompliziert. 



thecain hat gesagt.:


> Maven


Oh ja.. dringender Punkt. Wenn es darum geht, Maven zu konfigurieren für ein Projekt, bin ich aufgeschmissen. Ich kann höchstens dependencies hinzufügen und weiß in etwas grob, wie der Lifecycle aussieht und was bei clean und install passiert.
Wenn es darum geht, dass ich Goals angeben soll oder alles via Shell machen soll, zerstöre ich eigentlich nur das Projekt 



thecain hat gesagt.:


> Wenn du willst JUnit, ist aber nicht JEE spezifisch.


Ich denke damit fange ich an. Hab gelesen, dass man beim Maven Build bzw. beim Kompilieren auch die ganzen Tests durchlaufen kann, was an sich ja schon praktisch ist.


----------



## thecain (1. Okt 2016)

Kababär hat gesagt.:


> Ehrlich gesagt finde ich diese Server-Sache sehr kompliziert.


du darfst es einfach nicht wie einen "Server" wie es das Wort an sich sagt verstehen. Eigentlich ist ein Server nur eine Applikation, welche auf deinem Computer oder einem anderen läuft. Das einzige, was dann zum starten noch nötig ist, ist dein war, welches beim Build entsteht, in das richtige deployment verzeichnis zu kopieren. Der Rest ist mit den aktuellen Applicationservern eigentlich schon "Ready to use" vorkonfiguriert. 

Was viele auch empfehlen, ist den Server in einem Dockercontainer zu betreiben, das bedeutet dann aber noch ein neues Tool, das du lernen musst, von daher würde ich erstmal alles lokal installieren.


----------



## Meniskusschaden (1. Okt 2016)

Kababär hat gesagt.:


> stg hat gesagt.:
> 
> 
> > Ich kenne das Buch nicht, aber wenn es Applets behandelt, dann stammt es wohl aus einem vorherigen Jahrtausend.
> ...


Der Autor erwähnt selbst, dass Applets praktisch keine Bedeutung mehr haben und dass er das Kapitel deshalb knapp hält (es sind nur sieben Seiten). Meines Erachtens geht es in dem Buch darum, grundsätzliche Eigenschaften und Prinzipien von Java-Komponentensystemen heraus zu arbeiten. Dazu benutzt er eben ein paar Beispiele. Für den Zweck scheint mir die Aktualität nicht besonders wichtig zu sein. Es ist offenbar nicht die Zielsetzung des Buches, soweit in ein konkretes Produkt einzuführen, dass man es praktisch einsetzen kann, sondern nur zur Veranschaulichung des eigentlichen Themas.
Ich glaube nicht, dass das Buch gut für dein Thema geeignet ist, aber es ist sicher nicht veraltet. Ausserdem sind zumindest die beiden ersten Kapitel über Generics und Reflections noch so allgemein gehalten, dass Sie für jeden Java-Programmierer interessant sind, der sich noch nicht damit beschäftigt hat.


----------



## Kababär (1. Okt 2016)

Hmmm... ich glaube jetzt verstehe ich dann auch mal erst was Java EE eigentlich ist. 
Das Buch habe ich noch nicht durchgelesen, aber die Themen sahen vielversprechend aus. Bei anderen Büchern, die ich so fand, klang es von den Themen her so, als ob die mein Level übersteigen. 
Und wenn du sagst, der author spricht generell über das Thema, ist das ja perfekt für mich (so als überblick?). 
Denn ich hab ja gerade noch kein Verständnis dafür, wie die Komponenten und die Container zusammenarbeiten. 
(Zudem fand ich es ganz nett, dass er generics und Reflections behandelt, womit ich eigentlich noch nix am Hut hatte. 
Kann man sagen, dass Java EE quasi so was wie ein Vertrag ist, wie Applikationen aufgebaut sein müssen (3 Tier bzw. Schichtenmodell?), so dass ich quasi nicht nur Java, sondern auch Perl, C oder Ruby auf den Server lassen kann und integrieren kann?


----------



## Kababär (1. Okt 2016)

Buch gefunden  

https://jaxenter.de/gratis-e-book-the-java-ee-7-tutorial-199


----------

