Frage zu J2EE
- Themenstarter Bumbum564
- Beginndatum
Habe es jetzt 3x versucht und immer wieder der gleiche Fehler...
Weiß nicht, was ich falsch gemacht haben soll.
Verstehe nicht, dass es bei Dir geht und bei mir nicht...
Habe nomma mein Kompl. Project exportiert. vllt fällt dir ja daran nochwas auf.
Also ich habe wirklich keine Ahnung mehr, was hier schief läuft
Weiß nicht, was ich falsch gemacht haben soll.
Verstehe nicht, dass es bei Dir geht und bei mir nicht...
Habe nomma mein Kompl. Project exportiert. vllt fällt dir ja daran nochwas auf.
Also ich habe wirklich keine Ahnung mehr, was hier schief läuft
Zuletzt bearbeitet:
Oliver Gierke
Erfahrenes Mitglied
Auch, wenn ihr schon am implementieren seid 
... Darf ich kurz zwischenfragen, was zu der Entscheidung geführt hat überhaupt EJB (in welcher Version auch immer zu verwenden? JavaEE != EJB, das vergessen viele. Es gibt da eine Reihe Ansätze, die wesentlich flexibler und trotzdem einfacher sind.
Wenn du die Aufgabe hast, die in EJB einzuarbeiten - okay. Falls es um ein Produktivprojekt geht, würde ich mich sicher erstmal nach Alternativen umschauen. Der Overhead den EJB mit sich bring ist schon nicht zu unterschätzen (siehe die letzten 10 Posts.
Gruß
Ollie
... Darf ich kurz zwischenfragen, was zu der Entscheidung geführt hat überhaupt EJB (in welcher Version auch immer zu verwenden? JavaEE != EJB, das vergessen viele. Es gibt da eine Reihe Ansätze, die wesentlich flexibler und trotzdem einfacher sind.Wenn du die Aufgabe hast, die in EJB einzuarbeiten - okay. Falls es um ein Produktivprojekt geht, würde ich mich sicher erstmal nach Alternativen umschauen. Der Overhead den EJB mit sich bring ist schon nicht zu unterschätzen (siehe die letzten 10 Posts
. Gruß
Ollie
Hi Ollie.
Also meine Aufgabe ist es mittels Eclipse und dem JBoss mich in J2EE einzuarbeiten.
Da ich mich mit der 3 Schichtenarchitektur befassen soll und erstmal ein kleines Projekt erstellen soll. Wenn soweit alles läuft und ich alles soweit verstanden habe, wird es in der Praxis umgesetzt werden und erst einmal für Testzwecke / Vergleich benutzt.
Was genau meinst du damit?
Das das alles nicht leicht werden wird war mir von anfang an klar.
Also meine Aufgabe ist es mittels Eclipse und dem JBoss mich in J2EE einzuarbeiten.
Da ich mich mit der 3 Schichtenarchitektur befassen soll und erstmal ein kleines Projekt erstellen soll. Wenn soweit alles läuft und ich alles soweit verstanden habe, wird es in der Praxis umgesetzt werden und erst einmal für Testzwecke / Vergleich benutzt.
Was genau meinst du damit?
Das das alles nicht leicht werden wird war mir von anfang an klar.
Oliver Gierke
Erfahrenes Mitglied
Okay, gehen wir ins Detail, denn es geht um Details.
1. JavaEE VS. J2EE
Die Version 5 der Java Spec für Enterpriseanwendungen heißt "JavaEE", alles davor "J2EE". Das ist in sofern wichtig, dass mit JavaEE EJB3 gekommen ist, die letzte Version des EJB Standards in J2EE ist EJB2.1.
Wenn es also heißt "in J2EE einarbeiten" heißt das Java Enterprise Standard 1.4 (inklusive EJB2.1). Wenn es heißt "in JavaEE einarbeiten, dann Standard 1.5 (oder 5) - und der enthält nur EJB3.
2. JavaEE != EJB3 oder J2EE != EJB2.X
JavaEE / J2EE werden landläufig synonym mit EJB verwendet. Dabei ist EJB "nur" das Komponentenmodell innerhalb von JavaEE (SessionBeans, EntityBeans usw.). Es gibt eine Reihe weitere APIs die zum JavaEE Standard gehören: JTA, JMS, JMX usw.
Was ich damit meine, ist, dass man eine JavaEE Anwendung nicht zwingen (meiner Meinung nach zu 90% nicht) auf EJB basieren muss bzw. sollte. Parallel zu EJB haben sich nämlich wesentlich leichtgewichtegere Ansätze wie Spring (http://www.springframework.org) etabliert und EJB in meinen Augen auch zum Großteil verdrängt. Der Vorteil von Spring: POJO Programmiermodell, keine (ungewollten) Abhängigkeiten zur Infrastrukur (durch DependencyInjection - DI), Portable Service Abstraction (d.h. du bindest Infrastrukturdienste wie Security, Transaktionen auf die gleiche Weise in eine Spring basierte J2SE Anwendung ein, wie in eine Spring basierte JavaEE Anwendung). Weiterhin brauchst nicht zwingendermaßen einen ApplicationServer um die Anwendung laufen zu lassen.
Kernziel der ganze Sache ist vor allem die Containerunabhängigkeit. Echte Unittests gehen mit EJB ohne Container gar nicht, JAAS als Securitystandard ist unflexibel und überholt. EJB kann keine echte DI, kein richtiges AOP - alles Sachen die heutzutage die Grundlage von Enterpriseanwendungen sind.
Was will ich damit sagen:
Ich geh jetzt mal davon aus, dass deine Aufgabe eher eine wissensaneignende Natur hat. Und da stößt man beim Thema JavaEE natürlich schnell auf EJB. Das sollte den Blick allerdings nicht vor alternativen Technologien in diesem Bereich verschließen, die sich bereits zu Defacto Standards gemausert haben. Wie gesagt, ich finde, es gibt nur sehr wenige Anforderungen, die mich zu der Entscheidung bringen, eine Anwendung mit EJB zu implementieren.
Gruß
Ollie
1. JavaEE VS. J2EE
Die Version 5 der Java Spec für Enterpriseanwendungen heißt "JavaEE", alles davor "J2EE". Das ist in sofern wichtig, dass mit JavaEE EJB3 gekommen ist, die letzte Version des EJB Standards in J2EE ist EJB2.1.
Wenn es also heißt "in J2EE einarbeiten" heißt das Java Enterprise Standard 1.4 (inklusive EJB2.1). Wenn es heißt "in JavaEE einarbeiten, dann Standard 1.5 (oder 5) - und der enthält nur EJB3.
2. JavaEE != EJB3 oder J2EE != EJB2.X
JavaEE / J2EE werden landläufig synonym mit EJB verwendet. Dabei ist EJB "nur" das Komponentenmodell innerhalb von JavaEE (SessionBeans, EntityBeans usw.). Es gibt eine Reihe weitere APIs die zum JavaEE Standard gehören: JTA, JMS, JMX usw.
Was ich damit meine, ist, dass man eine JavaEE Anwendung nicht zwingen (meiner Meinung nach zu 90% nicht) auf EJB basieren muss bzw. sollte. Parallel zu EJB haben sich nämlich wesentlich leichtgewichtegere Ansätze wie Spring (http://www.springframework.org) etabliert und EJB in meinen Augen auch zum Großteil verdrängt. Der Vorteil von Spring: POJO Programmiermodell, keine (ungewollten) Abhängigkeiten zur Infrastrukur (durch DependencyInjection - DI), Portable Service Abstraction (d.h. du bindest Infrastrukturdienste wie Security, Transaktionen auf die gleiche Weise in eine Spring basierte J2SE Anwendung ein, wie in eine Spring basierte JavaEE Anwendung). Weiterhin brauchst nicht zwingendermaßen einen ApplicationServer um die Anwendung laufen zu lassen.
Kernziel der ganze Sache ist vor allem die Containerunabhängigkeit. Echte Unittests gehen mit EJB ohne Container gar nicht, JAAS als Securitystandard ist unflexibel und überholt. EJB kann keine echte DI, kein richtiges AOP - alles Sachen die heutzutage die Grundlage von Enterpriseanwendungen sind.
Was will ich damit sagen:
Ich geh jetzt mal davon aus, dass deine Aufgabe eher eine wissensaneignende Natur hat. Und da stößt man beim Thema JavaEE natürlich schnell auf EJB. Das sollte den Blick allerdings nicht vor alternativen Technologien in diesem Bereich verschließen, die sich bereits zu Defacto Standards gemausert haben. Wie gesagt, ich finde, es gibt nur sehr wenige Anforderungen, die mich zu der Entscheidung bringen, eine Anwendung mit EJB zu implementieren.
Gruß
Ollie
