Java EE 6 vs. Spring 3 Stack [geschlossen]

Ich starte jetzt ein neues Projekt. Ich muss Technologien wählen. Ich brauche etwas Leichtes, also kein EJB oder Seam. Andererseits brauche ich JPA (Hibernate oder Alternative) und JSF mit IceFaces.

Denken Sie, dass ein solcher Stapel auf Spring 3, der auf Tomcat bereitgestellt wird, eine gute Wahl ist? Oder könnte eine Java EE 6-Webanwendung besser sein? Ich befürchte, dass Java EE 6 eine neue Technologie ist, die noch nicht gut dokumentiert ist. Tomcat scheint einfacher zu warten zu sein als Glassfish 3.

Was ist deine Meinung? Hast du irgendwelche erfahrungen

Ich brauche etwas Leichtes, also kein EJB oder Seam.

Möchten Sie erklären, was EJBs seit EJB3 schwer macht? Ist dir klar, dass wir nicht mehr im Jahr 2004 sind? Ich würde gerne Ihre Definition von Licht und Ihre Argumente lesen (und ich werde meine Antwort gerne aktualisieren, da ich mir ziemlich sicher bin, dass ich ein paar solide Dinge zu sagen hätte).

Andererseits brauche ich JPA (Hibernate oder Alternative) und JSF mit IceFaces.

Das Java EE 6-Webprofil, das JSF 2.0, JPA 2.0, Bean Validation, EJB 3.1 Lite, CDI usw. enthält, ist hierfür perfekt geeignet. Sie können das GlassFish v3-Webprofil verwenden , um eine Anwendung auszuführen, die mit dem Java EE 6-Webprofil erstellt wurde .

Denken Sie, dass ein solcher Stapel auf Spring 3, der auf Tomcat bereitgestellt wird, eine gute Wahl ist? Oder könnte eine Java EE 6-Webanwendung besser sein?

Nun, ich mag die Idee, meinen Code auf einer nicht proprietären Plattform (Java EE) anstatt auf einem proprietären Container (Spring) auszuführen . Und ich denke, dass Java EE 6 gut genug ist (und dies ist ein Euphemismus, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI Kick Ass). Beachten Sie, dass ich ein JSF-Skeptiker war, aber ich habe einen zweiten Blick darauf geworfen, und JSF 2.0 mit CDI ist so unterschiedlich, dass ich es nicht einmal vergleichen kann. Und wenn Sie sich CDI nicht angesehen haben, lassen Sie mich Ihnen sagen, dass es rockt.

Ich befürchte, dass Java EE 6 eine neue Technologie ist, die noch nicht gut dokumentiert ist.

Java EE sieht für mich ziemlich gut dokumentiert aus. Das klingt nach freiem Anspruch. Und ob Sie es glauben oder nicht, ich finde, dass der Frühling kompliziert wird, während Java EE einfacher wird.

Tomcat scheint einfacher zu warten zu sein als Glassfish 3.

Hast du etwas probiert? Haben Sie ein bestimmtes Problem gehabt? Auch dies klingt nach freiem Anspruch.

Ich habe JavaEE6 nicht verwendet.

Ich bin jedoch von allen früheren Versionen von JavaEE und EJB so schlimm zusammengeschlagen worden, dass ich ihm nicht vertrauen werde, bis er sich als De-facto-Standard etabliert hat, nicht nur als De-jure-Standard. Im Moment ist der Frühling immer noch der De-facto-Standard.

Täuschen Sie mich einmal Schande über Sie. Mach mich zweimal zum Narren, schäme dich für mich. Mach mich dreimal zum Narren, EJB.

Einige werden behaupten, dass Spring proprietär ist. Ich würde argumentieren, dass die Herstellerimplementierungen der JavaEE-Spezifikationen genauso proprietär waren, wenn nicht mehr.

Ich habe kürzlich eine umfassende Konvertierung durchlaufen, bei der eine Reihe von Java-Anwendungen von JBoss auf Weblogic verschoben wurden. Alle Spring / Hibernate-Apps wurden ohne Änderungen portiert, da alle benötigten Bibliotheken integriert waren. Alle Apps, die JPA, EJB und JSF verwendeten, waren eine Katastrophe beim Portieren. Subtile Unterschiede in der Interpretation von JPA, EJB und JSF zwischen App-Servern verursachten alle Arten von bösen Fehlern, deren Behebung ewig dauerte. Sogar etwas so Einfaches wie die JNDI-Benennung war zwischen AppServern völlig anders.

Der Frühling ist eine Umsetzung. JavaEE ist eine Spezifikation. Das ist ein RIESIGER Unterschied. Ich würde es vorziehen, eine Spezifikation zu verwenden, wenn die Spezifikation zu 100% luftdicht ist und absolut keinen Spielraum für die Implementierung dieser Spezifikation durch die Anbieter bietet. Aber die JavaEE-Spezifikation war das noch nie. Vielleicht ist JavaEE6 luftdichter? Ich weiß es nicht. Je mehr Sie in Ihrem WAR packen können und je weniger Sie von AppServer-Bibliotheken abhängig sind, desto portabler wird Ihre Anwendung, und das ist schließlich der Grund, warum ich Java und nicht Dot-NET verwende.

Selbst wenn die Spezifikation luftdicht wäre, wäre es schön, den Appserver aktualisieren zu können, ohne alle meine Technologie-Stacks in allen meinen Anwendungen zusammen aktualisieren zu müssen. Wenn ich ein Upgrade von JBoss 4.2 auf JBoss 7.0 durchführen möchte, muss ich die Auswirkungen der neueren Version von JSF auf alle meine Anwendungen berücksichtigen. Ich muss die Auswirkungen auf meine Spring-MVC- (oder Struts-) Anwendungen nicht berücksichtigen.

Es spielt keine Rolle. Java EE 6 ist gut genug und aufgrund der dortigen Profile nicht "schwer" - Sie verwenden nur das Webprofil.

Ich persönlich bevorzuge den Frühling. Aber mir gehen die rationalen Argumente gegen Java EE 6 aus :)

(Wie ich durch einen Kommentar erinnert wurde - vielleicht möchten Sie RichFaces sowie ICEfaces und / oder PrimeFaces ausprobieren - je nachdem, welche Komponenten Sie benötigen).

Vor kurzem bestand eine meiner Kundenaufgaben darin, Spring Stack gegen Custom Framework Stack gegen Java EE Standards zu evaluieren. Nach einem Monat Evaluierung und Prototyping war ich nicht nur glücklich, sondern auch begeistert von den Java EE 6-Funktionen. Für jede neue "Enterprise" -Projektarchitektur im Jahr 2011 und in Zukunft würde ich Java EE 6 und mögliche Erweiterungen wie Seam 3 oder das kommende Apache JSR299-Erweiterungsprojekt verwenden. Die Java EE 6-Architektur ist optimiert und enthält die besten Open-Source-Ideen, die in den letzten Jahren entwickelt wurden.

Berücksichtigen Sie die folgenden Funktionen sofort: Ereignisverwaltung, Kontexte und DI, Interceptors, Decorators, RESTful-Webservices, integrierte Tests mit einbettbarem Container, Sicherheit und vieles mehr.

Die meisten meiner Ergebnisse werden in meinem Blog veröffentlicht und erläutern die wichtigsten Konzepte von Java EE 6, die Sie möglicherweise nützlich finden.

Natürlich gibt es keine feste Regel für die Auswahl eines Frameworks. Java EE 6 könnte für einfachere "Websites", die keinen umfangreichen Sitzungsstatus für Konversationen erfordern, gut aufgebläht sein. Sie können auch Grails auswählen oder spielen! Rahmen. Aber für Konversations-Webanwendungen kann ich kein besseres Argument sehen, warum Java EE 6 nicht gut passt.

Jetzt, nach einiger Zeit, habe ich Erfahrung mit Stapeln:

• Java EE 5 + Naht + GraniteDS + Flex
• Frühling 3 + Vaadin (auf GWT)
• Frühling 3 + JSF 2.0 (PrimeFaces)

Meine Schlussfolgerungen sind:

• Spring 3 ist viel einfacher als Seam (fast Java EE 6) und läuft auf Tomcat und Jetty! (Steg für die Entwicklung mit Maven Plugin ist ein Trasure).
• Ich liebe Flex (ich war eigentlich lange Zeit ein Flex-Entwickler, daher bin ich voreingenommen) und wenn Sie eine umfangreiche Benutzeroberfläche benötigen und FlashBuilder kaufen können, verwenden Sie diese, aber verwenden Sie dieses Spring + GraniteDS- oder BlazeDs-Backend. Wenn Sie FlashBuilder nicht kaufen können, verschwenden Sie keine Zeit.
• Vaadin ist großartig!. Der Entwicklungsprozess ist einfacher als bei Flex, aber Sie können problemlos umfangreiche Anwendungen ohne HTML-Probleme erstellen. Sie werden keine einzelne JS-Zeile schreiben. Sie brauchen nur etwas CSS (in Flex brauchen Sie es auch). Wenn sich Ihre Anwendungsoberfläche also wie eine Desktop-Anwendung verhält und Sie Flex nicht verwenden können (oder wollen), verwenden Sie Vaadin. Warnung! Vaadin hat einen großen JS-Overhead für den Browser.
• Wenn Sie eine einfachere Website-ähnliche Anwendung erstellen, verwenden Sie JSF2.0 (mit Spring-Backend wie oben). Sie müssen mit HTML kämpfen (ich hasse es) und das Erstellen einer reichhaltigen Oberfläche wird schwieriger sein als Vaadin (insbesondere Layouts). Sie erhalten leichtes HTML für langsamere Browser / Computer. Ich mag PrimeFaces - es ist einfach und gut dokumentiert. Der zweite Platz ist IceFaces
• Wenn Sie eine Website (NICHT eine Webanwendung) erstellen, auf der Sie HTML zum Leben erwecken müssen (anstatt eine Unternehmensanwendung zu erstellen, die in den Browser passt), verwenden Sie Wicket (wenn Sie komponentenbasiert sind, ziehen Sie die Einstellung) oder SpringMVC (wenn Sie vorlagenbasiert bevorzugen) , Push-Einstellung) oder verwenden Sie einfach Play! Rahmen. Denken Sie daran, dass das Erstellen umfangreicher datenbasierter Komponenten viel schwieriger sein wird, Sie jedoch die Kontrolle über jedes HTML-Tag haben (Ihr HTML / Grafik-Designer wird es lieben).

Lesen Sie Adam Biens Future Of Enterprise Java ... ist klar (Java EE mit / ohne Spring und umgekehrt) , einschließlich Kommentaren, um beide Seiten der Medaille zu erhalten. Ich werde Spring aus mehreren Gründen wählen und das Folgende ist einer von ihnen (Wiedergabe eines der Kommentare aus dem Beitrag)

„Ich bin nicht sicher, über welchen Java EE 6-Server Sie sprechen. Es gibt Glassfish-zertifiziert und TMAX JEUS. Es wird eine Weile dauern (lesen Sie: Jahre), bis Java EE 6-kompatible Versionen von WebSphere, WebLogic, JBoss usw. in Produktion sind und für echte Anwendungen verwendet werden können. Spring 3 benötigt nur Java 1.5 und J2EE 1.4 und kann daher in fast allen Umgebungen problemlos verwendet werden. '

Meine Meinung basiert auf etwas, das von anderen nicht erwähnt wird, nämlich dass Code bei meiner Arbeit dazu neigt, Jahrzehnte (buchstäblich) zu leben, und daher ist die Wartung für uns sehr wichtig. Pflege unseres eigenen Codes und der von uns verwendeten Bibliotheken. Unser eigener Code, den wir kontrollieren, aber es liegt in unserem Interesse, dass die von uns verwendeten Bibliotheken in den oben genannten Jahrzehnten oder länger von anderen verwaltet werden.

Um es kurz zu machen, ich bin zu dem Schluss gekommen, dass der beste Weg, dies zu erreichen, die Verwendung von Open-Source-Implementierungen von Sun-Spezifikationen bis hin zur rohen JVM ist.

Von den Open-Source-Implementierungen hat Apache Jakarta bewiesen, dass sie ihre Bibliotheken pflegen, und in letzter Zeit hat Sun viel Arbeit bei der Erstellung hochwertiger Implementierungen für Glassfish v3 geleistet. In jedem Fall haben wir auch die Quelle für alle Module. Wenn also alles andere fehlschlägt, können wir sie selbst warten.

Sonnenspezifikationen sind normalerweise sehr streng, was bedeutet, dass Implementierungen, die der Spezifikation entsprechen, leicht ausgetauscht werden können. Schauen Sie sich nur die Servlet-Container an.

In diesem speziellen Fall würde ich empfehlen, sich JavaServer Faces anzusehen, nur weil es Teil von Java EE 6 ist, was bedeutet, dass es sehr, sehr lange verfügbar und gewartet sein wird. Dann haben wir uns entschieden, MyFaces Tomahawk zu erweitern, da es einige nützliche Ergänzungen enthält und es sich um ein Jakarta-Projekt handelt.

An JBoss Seam oder anderen ist nichts auszusetzen. Es ist nur so, dass ihr Fokus weniger auf dem für uns so wichtigen Wartungsproblem liegt.

Ich kann sehen, wie Sie Spring verwenden, wenn Sie es bereits haben, aber was bringt es für das neue Projekt? Ich würde direkt mit Java EE 6 (ejb3, jsf2.0 usw.) gehen.

Wenn der Client mit Flex einverstanden ist, entscheiden Sie sich dafür. Verwenden Sie BlazeDS oder ähnliches - kein MVC. Möglicherweise verbringen Sie mehr Zeit mit diesem Teil (Datenaustausch zwischen Server und Client), haben jedoch auf beiden Seiten die volle Kontrolle.

Verwenden Sie Vaadin nicht, es sei denn, Sie möchten Ihren Browser beenden. Außerdem verbringen Sie mehr Zeit damit, den Code zu umgehen, sobald Ihre Seiten komplexer werden. Außerdem muss Ihre Denkweise komplett geändert werden, und alles, was Sie über die Standard-Front-End-Entwicklung wissen, wird verschwendet. Das Argument, dass Sie kein HTML oder JS verwenden müssen, macht wenig Sinn. Sie müssen es immer noch wissen, auch wenn Sie es nicht verwenden. Es wird schließlich in HTML und JS gerendert. Versuchen Sie dann, es zu debuggen - stellen Sie sicher, dass Sie ein paar Tage Zeit für einfache Dinge haben. Außerdem kann ich mir keinen Webentwickler vorstellen, der HTML / JS nicht kennt.

Ich verstehe einfach nicht, warum Leute all diese Abstraktionen ausprobieren, anstatt Java EE direkt zu verwenden.

Warum gibt es immer noch Gerüchte darüber, dass EJB 2010 im Schwergewicht ist? Es scheint, dass die Leute nicht in Java EE-Technologien aktualisiert werden. Probieren Sie es einfach aus, Sie werden angenehm überrascht sein, wie die Dinge in Java EE 6 vereinfacht werden.

Die Antwort auf Ihre Fragen hängt von Ihren Projektanforderungen ab. Wenn Sie keine Java EE-Funktionen wie Nachrichtenwarteschlangen, von Containern verwaltete globale Transaktionen usw. benötigen, entscheiden Sie sich für Tomcat + Spring.

Aus Erfahrung habe ich auch herausgefunden, dass Projekte, die viel Integration, Planung und Nachrichtenwarteschlangen von Webdiensten erfordern, am besten mit einem Teil des Java EE-Stacks ausgeführt werden können. Das Gute ist, dass Sie mit Spring weiterhin Java EE-Module integrieren können, die auf einem Anwendungsserver ausgeführt werden.

Java EE 6 unterscheidet sich stark von den vorherigen Versionen und macht wirklich alles viel einfacher. Java EE 6 kombiniert die besten Ideen aus der vielfältigen Java-Community - zum Beispiel war Rod Johnson vom Spring Framework aktiv an der Erstellung des Dependency Injection JSR in Java EE 6 beteiligt. Ein Vorteil der Verwendung von Java EE 6 besteht darin, dass Sie entsprechend codieren Ein Standard, der in einigen Organisationen für die Unterstützung von Anbietern usw. wichtig sein kann.

GlassFish v3 unterstützt Java EE 6 und ist recht leicht und startet sehr schnell. Ich habe Glassfish v3 für meine Entwicklungen verwendet und es ist wirklich einfach zu konfigurieren. Es wird mit einer sehr benutzerfreundlichen Administrationskonsole geliefert, mit der Sie Ihren Server grafisch verwalten können.

Wenn Sie GlassfishV3 und JSF 2 verwenden, können Sie die CDI-Funktionen von Java EE 6 nutzen, mit denen Sie auf einfache Weise Konversationen (z. B. Seiten wie Assistenten) in JSF erstellen können.

Für die Verwendung von Java EE 6 müssen Sie jedoch auch eine neue API erlernen. Abhängig vom verfügbaren Zeitrahmen ist dies möglicherweise nicht die beste Wahl für Sie. Tomcat gibt es schon seit Ewigkeiten, und die Kombination aus Tomcat und Feder wurde von vielen Webprojekten übernommen, was bedeutet, dass es viele Dokumentationen / Foren gibt.

Ich habe sowohl in Spring als auch in Java EE 6 gearbeitet. Aus meiner Erfahrung kann ich sagen, dass Sie sicher sind, wenn Sie bei Spring bleiben, wenn Sie sich für die uralte JSP oder proprietäre Flex entscheiden.

Wenn Sie jedoch mit JSF fortfahren möchten, ist es an der Zeit, auf Java EE 6 umzusteigen. Mit Java EE 6 wechseln Sie zu Facelets und standardisierten Skriptbibliotheken und Komponentenbibliotheken. Keine Skriptinkompatibilitäten und Komponentenbibliotheksmatrizen mehr.

In Bezug auf Spring MVC ist es gut, solange Ihr Projekt nicht zu groß wird. Wenn es sich um eine große Unternehmensanwendung handelt, bleiben Sie bei Java EE 6. Denn nur so können Sie Ihre eigenen Komponentenbibliotheken und Ressourcenpakete ordnungsgemäß verwalten.

Wenn Sie den Java EE Full Stack benötigen, empfehle ich Ihnen GlassFish 3.1. Es startet sehr schnell im Vergleich zu anderen Java EE-Containern, die einen Teil oder das gesamte Java EE 6 (JBoss 6, WebLogic 10.3.4) implementieren. Die erneute Bereitstellung dauert Sekunden und fast alles kann durch Konvention über Konfiguration durchgeführt werden. Es ist sehr benutzerfreundlich.

Wenn Sie etwas "Leichtes" möchten, können Sie einen Apache Tomcat 7.x mit den gewünschten Funktionen anpassen. Ich habe viel mit den folgenden Bibliotheken verwendet: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - nur ressourcenlokale Transaktionen JSF 2.x (Mojarra) RichFaces 4.0 BIRT-Laufzeit

Java EE 6 ist seit 10 Jahren ein Java EE-Entwickler (ich leide unter frühen EJB-, JSF- und Web-Technologien). Es ist sehr einfach, gut gekoppelt und die aktuelle Hardware läuft reibungslos, sodass die ursprünglichen Gründe, aus denen Spring motiviert ist, nicht mehr gültig sind.

Ich würde immer noch den Frühling bevorzugen.

Und ich würde JSF weitergeben. Ich denke, es ist eine tote Technologie. Spring MVC wäre eine bessere Alternative. Flex würde es auch tun. Denken Sie an die ersten XML-Services für Verträge, und Sie können das Back-End vollständig von der Benutzeroberfläche entkoppeln.

Ich würde Spring + Tomcat empfehlen, es sei denn, Sie können warten, bis Glassfish v3 und Weld reifer werden. Derzeit gibt es einige Probleme mit dem Speicherverbrauch / der CPU-Auslastung, wenn Glassfish mit CDI-fähigen Anwendungen ausgeführt wird.

Ich habe nicht alles gelesen, sondern nur, um zu sagen, dass Sie EJB3 jetzt in einem Krieg gegen Java EE 6 verwenden können, damit Sie EJB3 unter Tomcat verwenden können (glaube ich).

Ich habe dir Tomcat mit Spring empfohlen, weil:

1. Spring kann Backing Beans für JSP erstellen
2. Sie werden Spring verwenden, um Objekte über JPA beizubehalten

Es ist eine gute Wahl, sich für Tomcat zu entscheiden, da Sie keine Schwergewichtsverarbeitung benötigen