Hallo Freunde,

ich möchte demnächst mich mit J2EE beschäftigen.

Könnte mir jemand diesbezüglich, das Buch, das Tutorial empfehlen womit ich anfangen sollte.

Als Betriebssystem möchte in unter Linux (Ubuntu) arbeiten. Als IDE wollte ich mal Netbeans ausprobieren.

Nach ersten Recherchen scheint es etwas aufwendiger zu sein diese Einzurichten da weitere Tools und Software nötig ist. Das verschiedene Versionen der Software und Tools nicht immer miteinander kompatibel ist.

Da wird es wohl nahe sein, eines der Bundle von Sun oder Netbeans zu verwenden. Nur welches ?

http://java.sun.com/javaee/downloads/index.jsp
Java EE 5 Tools Bundle Beta
Java EE 5 SDK SOA Starter Kit Preview

http://java.sun.com/javaee/downloads/previous/
hier gibt es noch ältere Sachen zu 1.4

Auf den Seiten von Netbeans gibt es bspw. folgende Bundle:
NetBeans IDE 5.5 Beta 2 + Application Server 9.0 Bundle Installer
NetBeans IDE 5.5 Beta 2 + JBoss Application Server 4.0.4 Bundle Installer

Oder wäre für den Einstieg eine ganz andere Kombination besser?


Bitte nicht gleich alles empfehlen ! Sonst bin genauso schlau wie vorher .


Vg Erdal

Also ich bastel hier mit Eclipse 3.2.1 und Apache Geronimo 1.1.1 rum. Ob das nun empfehlendswert ist kann ich dir leider nicht sagen, da ich mir bis jetzt noch nix anderes angesehen habe.

Tuts gibts unter http://www.eclipse.org/webtools/comm...html#tutorials und http://www-128.ibm.com/developerwork...ry/os-gerplug/

Hallo, gute Umgebung ist mit Elipse und JBoss

Bei Eclipse wtp-all-in-one runterladen: http://www.eclipse.org/webtools/

Bei JBoss.org vorbeisurfen den JBoss Application Server runterladen und mit ejb3 opiton installieren. Dann noch auf der JBoss Seite sich den EJB 3.0 TrailBlazer reinziehen und was auch sehr nützlich ist ist das JBoss Seam Project.
Einen guten Einstieg bietet das Step-By-Step getting started Tutorial.

Viel Erfolg

Hallo!

Also Bücher zum Thema J(2)EE gibts wie Sand am Meer:
Für traditionelles J2EE mit EJB...
http://www.amazon.de/Enterprise-Java...e=UTF8&s=books

Java EE 5 - Einstieg für Anspruchsvolle
http://www.terrashop.de/82732362A/artikel.php

JBoss
http://www.terrashop.de/89864318A/artikel.php

J2EE und JBoss - Grundlagen und Profiwissen
http://www.terrashop.de/44640508A/artikel.php

Tomcat 5
http://www.terrashop.de/82732202A/artikel.php

Spring - Framework für die Java-Entwicklung
http://www.terrashop.de/89864365A/artikel.php

Nicht fehlen darf natürlich:
J2EE Development without EJB
http://www.amazon.com/Expert-One-on-.../dp/0764558315

Lies erstmal J2EE und JBoss - Grundlagen und Profiwissen und dann nach belieben einen der anderen Titel.

Gruß Tom

Hallo Tom,

bis du noch auf EJB vor v3.0 festgenagelt, weil deine angegebenen Quellen kein EJB3 enthalten.
Für alle Neueinsteiger würde ich allerdings die Version 3 empfehlen, da man sich da den ganzen Umstand mit Deployment Discriptor, XDoclet etc sparen kann. Läuft alles mit POJO's und Annotations. Und die Erweiterung mit JBoss Seam ist einfach genial.


Gruß
Andreas

Hallo!

Ich bin Gott sei dank überhaupt nicht auf EJB festgenagelt
... btw. ist dir hier nicht genug EJB 3.0 drin: Java EE 5 - Einstieg für Anspruchsvolle ?

Mit dem Springframework macht Java Enterprise Development viel mehr Spaß als mit dem "Standard" JEE Schmuß...

Gruß Tom

Hoffe du füllst dich nicht auf den Schlipps getreten.... war zumindest nicht meine absicht. Das du dich nicht auf irgendetwas festnagelst weiß ich aus diversen Beiträgen von dir.

Das genannte Buch kenne ich nicht, allerdings stand im "aus dem inhalt" auch nichts von ejb3 drin.

Kannst du mir erklären was die vorteile von spring vs ejb3 sind, das entwicklung damit so viel mehr spaß bringt, ich kenne spring eben noch nicht.


Gruß
Andreas

Hallo!

Schau dir doch mal diesen Vergleich an:
http://www.onjava.com/pub/a/onjava/2...ring-ejb3.html

Was mir persönlich an Spring besser gefällt:
- Bessere AOP Möglichkeiten über Spring-AOP bzw. der AspectJ Integration, besseres
(bzw. überhaupt ein) Pointcut Model .etc.
- Kein Application Server Notwendig
- Mehr Dependency Injection Möglichkeiten (Constructor-Injection, Method-Injection, Interface-Injection (Nicht direkt, aber über geschicktes AutoWiring möglich... ), AFAIK erlaubt EJB 3.0 Dependency Injection nur für Objekte die im JNDI registriert sind...
- und und und...

Noch was zu dem Pointcut Model. Bei den von Spring angebotenen AOP Möglichkeiten kann man über Pointcuts sagen wo bestimmte "Zusatzfunktionalität" wie Transaction-Handling, Access-Controll etc. eingewoben werden soll... sprich man sagt deklrativ wo was passieren soll. (Bsp.:
public * de.tutorials.v6.portal.services.IService+.*(..) -> Bei allen public Methoden von Implementierungen des IService Interfaces)

Beim EJB "Pointcut Model" gibt man an den entsprechenden Stellen (Methoden) explizit an, welche Zusatzlogik (Advices, Interceptors) Anwendung finden sollen. Das ist genau der umgekehrte Weg. -> Dort würde man an den konkreten Methoden oder an der konkreten Klasse die entsprechende Annotationen vorfinden die dann jeweils angeben würden, was zu tun wäre.

Gruß Tom

Es gibt noch ein paar mehr Punkte, die Spring für 90% der Anwendungen sinnvoller erscheinen lassen oder die "bessere" Alternative seien lassen:

- Aus Tom's "kein Application Server notwendig" folgt etwas ganz wichtiges: (Unit-)Testbarkeit ohne Infrastruktur. Komponentenklassen sind direkt mit JUnit testbar, Integrationstests werden mit von Spring bereitgestellten Subklassen von UnitTest möglich
- die AOP Funktionalität möcht ich auch nochmal unterstreichen. In EJB3 ist Interception, wie es da heißt, nur mit EJBs möglich (obwohl ich auch mal davon gelesen hab, eswäre auch mit Servlets möglich). Ein Witz ist eigentlich das Definieren von Interceptoren durch Annotations-> ich will durch AOP ja Aspekte gerade zentral behandeln und konfigurieren und nicht überall im Code verteilen

Zusätzliche Argumente / Vorteile:
- Spring skaliert nach oben und auch nach unten. Bei kleineren Projekten holt man sich nicht so schnell unnötigen Overhead ins Haus. Spring ist sehr modular aufgebaut, so dass man auch nur die Libs braucht, die man wirklich benötigt.
- Das Remotingmodell finde ich auch sehr einfach/spannend: Services können per Konfiguration zum WebService gemacht werden.
- Das MVC Framework macht gut Spass, obwohl ich in Struts 2 auch sehr interessante Ansätze sehe.
- Spring forciert eine gute Architektur bzw. sauberes Layering, wohingegen EJB (besonders in der 2.1er Spezifikation) eher zum grundsätzlichen Arbeiten mit Workarounds führt.
- Der Kern der Anwendung bleibt View-unspezifisch. D.h. man kann eine Webanwendung auch bequem und leicht hinter einen SWT Client packen.
- Es existiert ein wachsendes Ökosystem mit vielen praktischen Erweiterungen usw: WebFlow, SpringModules.

Fazit: Spring ist das felxiblere und leichtgewichtigere Pendant zu EJB und - solang nicht extensiv auf verteilte Objekte gesetzt wird ("The first rule to distributing objects is 'Don't distribute'" - Martin Fowler ) - eigentlich das Framework der Wahl

Ich hab vor kurzem nen Blogeintrag zu Spring verfasst: hier

Btw. merkt man, dass ich Spring Fan bin?

Gruß
Ollie

Hallo,
ich habe eine Frage, ich fange auch an mit Java zu Programmieren. Ich lese zZ das Buch "Java ist auch eine Insel"! Ich will erstmal Das Java wissen bekommen, bevor ich mit Java EE anfang, also mit Webappliaktion. Sind doch welche oder?

Jetzt meine Frage, ich hab auf dem PC das JDK 5.0.9, langt doch und ich nutze Eclipse, brauch ich noch was weil ihr von soe viel Zeug hier schreibt!

Hallo!

Es gibt noch ein paar mehr Punkte, die Spring für 90% der Anwendungen sinnvoller erscheinen lassen oder die "bessere" Alternative seien lassen:

- Aus Tom's "kein Application Server notwendig" folgt etwas ganz wichtiges: (Unit-)Testbarkeit ohne Infrastruktur. Komponentenklassen sind direkt mit JUnit testbar, Integrationstests werden mit von Spring bereitgestellten Subklassen von UnitTest möglich

Na ja, bei größeren Anwendungen braucht das starten des ApplicationContexts fast genauso lange wie der start eines
ApplicationServers (Beispielsweise bei intensiver Verwendung von Hibernate, etc.) Aber in der Regel gehts natürlich schon ein ganzes Stückschen flotter Desweiteren sind IMHO gerade für Integrationstests bestimmte Infrastrukturen notwendig (Beispieliele: Datenbank muss vor dem Test mit passenden Testdaten initialisiert werden (-> DBUnit) anschlißend muss wieder aufgeräumt werden, zum Testen des Login Moduls muss der LDAP Server muss verfügbar sein, der Third Party Webservice muss zur verfügung stehen, und und und... auch wenn man sich hier mit exzessivem Mocking helfen kann bleibt man jedoch manchmal nicht von sämtlicher Infrastruktur verschohnt)
Btw. Es sind Subklassen von TestCase

- die AOP Funktionalität möcht ich auch nochmal unterstreichen. In EJB3 ist Interception, wie es da heißt, nur mit EJBs möglich (obwohl ich auch mal davon gelesen hab, eswäre auch mit Servlets möglich). Ein Witz ist eigentlich das Definieren von Interceptoren durch Annotations-> ich will durch AOP ja Aspekte gerade zentral behandeln und konfigurieren und nicht überall im Code verteilen

Wie ich bereits sagte, der Interception Mechanismus von EJB 3.0 ist quasi "the other way around" im Gegensatz zu traditionellem AOP mit einem Around Advice.

Zusätzliche Argumente / Vorteile:
- Spring skaliert nach oben und auch nach unten. Bei kleineren Projekten holt man sich nicht so schnell unnötigen Overhead ins Haus. Spring ist sehr modular aufgebaut, so
dass man auch nur die Libs braucht, die man wirklich benötigt.

Ich würde eher sagen, dass man Spring in beliebigen Ausbaustufen in der Anwendung einsetzen kann. Beispielsweise kann man sich auch nur dem IoC bedienen oder man benutzt den sukzessive nach und nach den kompletten Spring-Stack. Dies erlaubt es Spring Schrittweise einzusetzen und so die Technologie "sanft" in die Architektur einzuführen.

Das Spring Anwendungen skalieren würde ich eher in anderem Kontext sehen, nämlich in der Unterstützung der Implementierung von Verteilten System über das einfache Remoting, und die zahlreichen Clustering-Möglichkeiten über Thirdparty Produkte (GigaSpaces, JGroups etc.).

- Das Remotingmodell finde ich auch sehr einfach/spannend: Services können per Konfiguration zum WebService gemacht werden.

Das kann man mit normalen JEE 5 auch in ähnlicher Weise Viel interessanter finde ich hier die Vielfallt an zur Verfügung stehenden Remoting Methoden: RMI, RMI over IIOP, Springs HTTP Remoting, Webservices über Axis, Hessian, Burlap ode XFire etc. darüber hinaus ist es auch recht einfach eigene Remoting Stacks hinzuzufügen (haben wir gerade für JGroups gemacht).

- Das MVC Framework macht gut Spass, obwohl ich in Struts 2 auch sehr interessante Ansätze sehe.

Das Spring MVC Framework ist zur Implementierung der Präsentationsschicht (Web) einer Spring-Awendung ein guter Weg, jedoch sollte man auch erwähnen, dass es mit Spring Webflow noch eine Zusätzliches Framework gibt, mit dessen Hilfe man auch größere komplexe Page-Flows deklarativ in Form einer Statemachine modellieren kann, darüber hinaus gibts noch Support für Continuations und und und...

- Spring forciert eine gute Architektur bzw. sauberes Layering, wohingegen EJB (besonders in der 2.1er Spezifikation) eher zum grundsätzlichen Arbeiten mit Workarounds führt.

Insbesondere das Forcieren des Konzeptes gegen Interfaces zu Programmieren und konkrete Implementierungen in der Konfiguration zu verstecken macht die Anwendung sehr flexibel hinsichtlich Erweiterbarkeit und Wartbarkeit. Weiterhin erlaubt Spring eine Art Komponentisierung des Gesamtsystems, so dass man nach und nach aus kleinen Komponenten (Spring-Beans) größere komplexere Komponenten zusammenstöpseln kann.

- Der Kern der Anwendung bleibt View-unspezifisch. D.h. man kann eine Webanwendung auch bequem und leicht hinter einen SWT Client packen.

Also ich würde das eher Präsentationsschichtunabhängigkeit nennen... und die bekommt man natürlich auch nicht automatsich Man muss natürlich durch geschickte Implementierung der einzelnen Schichten diese weitestgehend unabhängig voneinender machen, Spring bietet hier durch Best Practices viel Unterstützung, jedoch muss der Entwickler immer noch wissen wie man diese richtig Umsetzt.

- Es existiert ein wachsendes Ökosystem mit vielen praktischen Erweiterungen usw: WebFlow, SpringModules.

....SpringIDE, Integration in Zahlreiche Applikationserver (Spring stellt beispielsweise die Basis der JEE 5 Implementierung im BEA Weblogic dar). Weiterhin gibt es starke Unterstützung in der Industrie durch namhafte Firmen wie BEA, Oracle und IBM.

Fazit: Spring ist das felxiblere und leichtgewichtigere Pendant zu EJB und - solang nicht extensiv auf verteilte Objekte gesetzt wird ("The first rule to distributing objects is 'Don't distribute'" - Martin Fowler ) - eigentlich das Framework der Wahl

Hochgradig Verteilte Systeme sind IMHO noch der einzige Anwendungsfall in denen EJB noch als Implementierungsbasis in betracht gezogen werden sollten, ansonsten würde ich immer zu Spring greifen.

Btw. Spring kann natürlich auch in einem normalen J2EE Server wie JBoss laufen und bietet auch support für EJBs. -> Die Entscheidung etwas zwingend mit EJB Implementieren zu wollen schließt den Einsatz von Spring natürlich nicht aus

Gruß Tom

@venyl:
Da haste dir aber ganz schön was vorgenommen!
Ich bin auch dabei mich in J2EE rein zu arbeiten und das ist ganz schön komplex. Dabei kann ich Java ganz gut; verstehe zumindest alle objektorientierten Konzepte.
Nachdem du Java einigermaßen drauf hast, solltest du dich vielleicht erstmal mit JSPs auseinandersetzen. Damit kannst du schon Webapplikationen erstellen und das schafft Verständnis für das Kommende: J2EE mit Application Server.
Für den Anfang reicht Eclipse ohne Zusätze. Wenn du bei den JSPs bist, sollteste dir die Eclipse WTP Plugins installieren.

Ein sehr interesanter Thread.

2 Fragen:

1. Wie lange denk ihr benötigt man um sich in Spring einzuarbeiten?
2. Wie baut man am besten modular aufgebaute Applikationen (damit es ähnlich zu RCP ist wo man einfach plugins ein- und ausstöpseln kann)?

Ich denke der Break Even liegt bei Spring beim Verstehen der DependencyInjection. Zum Anfang denkt man halt laufend: "WIe komm ich denn jetzt an den ApplicationContext?" Die Lösung lautet fast immer: "Brauchst du net, lass dir die benötigten Objekte einfach injizieren". Ist am Anfang etwas schwer zu verstehen, aber hat mans erstmal geschnall, will man gar nicht mehr ohne. Bei jeder manuellen Instantiierung kommt man sofort ins grübeln .

Die größte Hürde war für mich eigentlich die Toolproblematik. Wo kommt welche lib hin? WIe teil ich die Konfigurationsfiles am besten auf? usw. usw. Die Dokumentation von Spring ist sehr ausführlich, die API ist verhältnismäßig "überdokumentiert" Das Forum ist auch sehr hilfreich. Meistens reicht eine Suche im Forum, man bekommt da eine Klasse genannt, die das beschriebene Problem irgendwie löst und den Rest erledigt man über das Studium der API für die Klasse.

Für den Einstieg empfiehlt sich IMHO auch das Buch vom Eberhard Wolff. Es gibt einen guten Überblick über die DI, Spring und AOP, das Webframework, geht jedoch nicht sonderlich in die Details.

Vielleicht nimmst du dir AppFuse oder Equinox als Startbasis (https://appfuse.dev.java.net/). Das sind Skeletons für Springprojekte, die einen Großteil schonmal vorbereitet haben.

Wenn Fragen auftauchen, stellst du die einfach

Wie lang man braucht? Hm... schwirig zu sagen. Ich mag nicht von mir behaupten, schon alle Features von Spring zu beherrschen. Aber um das Gros abfackeln zu können würde ich so 1 Monat veranschlagen, Fulltimearbeit und entsprechende SE-Kenntnisse vorrausgesetzt. Als Javanewbie wirds sicher ne Weile länger dauern, wer jedoch schon Webanwendungen programmiert hat, wird Spring fressen

Modularität: hm... geht in Spring im Endeffekt über die Konfiguration. WIchtig ist allerdings auch ein Design bzw. eine Architektur, die das überhaupt möglich macht. Ein Service Layer aufgeteilt in fachliche Bereiche, keine zyklischen Abhängigkeiten, Programmierung gegen Interfaces... all das sind so Kleinigkeiten. Seit kurzem gewinnt die OSGI Integration von Spring auch mehr an Popularität. Damit ist es möglich Teile von Serveranwendungen zur Laufzeit zu starten, herunterzufahren, zu konfigurieren und/oder auszutauschen. Das Ding steckt allerdings noch etwas in den Kinderschuhen.

REINHAUN!

Danke für die ausführliche Antwort *DAUMEN HOCH*