Spring 3 vs. Java EE 6

[deamon]

Hallo,

ich überlege, ob ich für ein neues Projekt Spring 3 oder Java EE 6 verwenden soll. Prinzipiell halte ich sowohl Spring als auch Java EE für geeignet, wobei ich gerade leicht zu Java EE tendiere, weil es einem mehr Konfiguration abnimmt, und die Entwickler weniger Möglichkeiten haben, Fehler zu machen (z. B. Transaktionssicherheit zu vergessen).

Folgende Gedanken sind mir zu dem Thema gekommen:

Spring 3
--------
Pro:
- sehr flexibel, es können viele Technologien einfach integriert werden
- einheitliches Programmiermodell mit DI und AOP
- kein "dicker" Application Server nötig, die Anwendung bringt nur das mit, was sie wirklich braucht
- es können leichter einzelne Frameworks aktualisiert werden

Contra:
- mehr Konfiguration
- weniger Komfort; man muss sich z. B. um Transaktionen immer selbst kümmern
- Entwickler werden weniger an die Hand genommen
- mehr Möglichkeiten, Fehler zu machen
- nicht herstellerunabhängig, aber wenigstens Open Source
- Spring wird immer komplexer (Missbrauch von Annotationen, Meta-Annotationen, Spring Expression Language)
- Pseudo-Entkopplung von Spring, die mit proprietären Annotationen dann doch wieder zerstört wird. Der Code würde zwar auch ohne noch übersetzbar und ausführbar sein, würde aber nicht mehr seinen eigentlichen Zweck erfüllen.
- umständliches bzw. gar kein Clustering
- insgesamt vermutlich schwerer als Java EE zu erlernen

Java EE 6
---------
Pro:
- Convention over Configuration nimmt dem Entwickler sehr viel Konfiguration ab; um Transaktionen oder Autorisierung braucht man sich nicht viele Gedanken machen.
- Herstellerunabhängiger Standard
- Entwickler wird stärker an die Hand genommen als bei Spring -> hoffentlich weniger Wildwuchs in der Architektur
- Application Server bieten mehr als ein einfacher Tomcat (z. B. Übewachung)
- tendenzielle einfachere Anpassung an verschiedene Umgebungen (z. B. DB-Verbindung, Mail-Server usw.)
- Man hat alles zusammen und muss sich nicht sein System aus Einzelteilen zusammensuchen
- vermutlich insgesamt einfacher zu lernen als Spring

Contra:
- Fremde Technologien können nicht ganz so einfach integriert werden wie bei Spring
- immer ein "dicker" Application Server nötig
- AOP-Fähigkeiten sind begrenzt

Zusammenfassung
---------------
Spring nutzt DI und AOP einheitlich als mächtige Grundkonzepte, ist sehr flexibel, erfordert aber auch mehr Konfiguration und Gehirnschmalz seitens des Entwicklers. Java EE bringt dagegen alles, was man gewöhnlich braucht, mit und nimmt dem Entwickler die meiste Konfiguration durch Konventionen ab. Dafür benötigt man zwingend einen Application Server und ist nicht ganz so flexibel.

Wie denkt ihr darüber und was fallen euch noch für Argumente ein?

 

[maki]

weniger Komfort; man muss sich z. B. um Transaktionen immer selbst kümmern

Ähm... du kennst die @Transational Annotation? Die reicht...
Dekleratives Transactionhandling war immer schon eine Stärke von Spring, nix mit "selber kümmern".
Der Unterschied ist eigentlich, dass man in einem JEE AppServer globale Transaktionen "umsonst" bekommt, aber diese in Spring eher aufwändig sind.

Ansonsten sind Spring und JEE 6 sich ähnlich, beide unterstützen DI, aber Spring besser als JEE 6, mit Spring 3.0 und der EL hat Spring imho sogar einen Vorteil.

Pseudo-Entkopplung von Spring, die mit proprietären Annotationen dann doch wieder zerstört wird. Der Code würde zwar auch ohne noch übersetzbar und ausführbar sein, würde aber nicht mehr seinen eigentlichen Zweck erfüllen.

Man muss keine Annotationen verwenden, mit ist man eben weniger flexibel, hat dafür aber weniger Konfig Aufwand in XML Dateien. Das gleiche gilt doch für JPA, sobald ich spezielle Annos im Code verwende (weil zB. JPA 1.0 unzureichend ist), war es das wieder mit der unabhängigkeit von der Implementierung..

Beim autom. Testen hat Spring auch die Nase vorn imho, da hinkt JEE 6 meiner Meinung nach noch ein gutes Stück hinterher (test von SessionBeans?)

Das Argument des Industrie-Standards im Falle von JEE ist imho nicht mehr wirklich relevant, früher (vor JEE 5/6) waren EARs nicht auf allen AppServern lauffähig, da zuviel Konfiguration für den eigentlichen Server notwendig war, und mittlerweile ist JEE eine Kopie in großen Teilen von Spring, manche nennen es auch "inspiriert".

Ansonsten kann man Spring auch in einem AppServer einsetzen, JEE (inkl. EJBs) und Spring schliessen sich nicht gegenseitig aus, auch wenn dieser Eindruck öfters in solchen Gegenüberstellugen vermittelt wird.

 

[byte]

Spring hat soviele Helper Klassen, die auf JEE aufsetzen, dass ich auch sagen muss: Das eine schließt das andere überhaupt nicht aus. Ich kann z.B. ein einfaches POJO mittels Spring im laufenden Container als MBean für JMX registrieren. Spring setzt hier also lediglich auf der JMX API auf, statt eine alternative Implementierung zu liefern.

Ich denke, JEE ist viel zu komplex, als das man alles in einen Topf werfen kann. Spontan fällt mir eigentlich nur EJB ein, wo Spring tatsächlich eine Alternative bietet. Und selbst da setzt Spring auf der Servlet Spec. auf, was wiederum Teil von JEE ist.

Ansonsten kann ich nicht viel zu dem Thema beisteuern, weil ich mich bisher weder mit JEE6 noch mit Spring 3 intensiv beschäftigt habe. Es werden noch ein paar Tage ins Land ziehen, bis JEE6 Einzug bei meinem derzeitigen AG hält. Bisher ist hier nicht mal Java 6 genehmigt.

 

[deamon]

Dass Spring und Java EE sich nicht grundsätzlich ausschließen, war mir bewusst, aber ich würde erstmal den einen oder den anderen Ansatz und keine Mischung anstreben. Sollte sich dafür ein guter Grund ergeben, könnte man immer noch beides kombinieren.

Probleme beim Testen von Session Beans sehe ich übrigens nicht, denn das sind ja auch nur POJOs.

Den Grundgedanken meines Beitrags trifft dieser Blogartikel über Spring vs. Java EE reloaded.

 

[byte]

Ein in meinen Augen ziemlich dämlicher Artikel. Nicht nur der letzte Satz ist ziemlicher Schwachsinn in meinen Augen.

SpringSource ist kommerzieller geworden, das Spring Framework ist noch genauso Open Source wie vorher. Ebenso sind die wichtigsten Module von Spring immernoch das selbe, was sie früher auch schon waren. Ich sehe nicht, was das jetzt auf einmal schwergewichtig sein soll. Ich verstehe auch nicht, was er mit Wrapper über Wrapper meint!? Im Grunde ist Spring nicht viel mehr als ein DI Framework mit Haufenweise Helper Klassen, die direkt auf der JEE API aufsetzen oder einfach nur bei der Integration von JEE und verschiedener andere Libraries helfen.

Versteht mich nicht falsch. Spring ist für mich sicher nicht der heilige Gral. Man kann mittlerweile auch vernünftig mit purem JEE arbeiten und ab JEE6 sicher noch besser. Aber dieses Spring Bashing in letzter Zeit ist einfach dämlich.


Edit: Von allen Libs und Frameworks, die ich bisher in 8 Jahren Java gesehen habe, ist das Spring Framework mit Abstand am besten durchdacht, am besten dokumentiert, am fehlerfreiesten + hat mit Abstand das beste OO-Design.

 

[maki]

Probleme beim Testen von Session Beans sehe ich übrigens nicht, denn das sind ja auch nur POJOs.

Ach, Stateless & stateful SessionBeans sollen POJOS sein?
Oder verwechseltst du das mit EntityBeans?

Kann byte nur zustimmen, der sog. "Artikel"/Blog (darf der überhaupt so heissen mit seinen paar Sätzen?) fast inhaltslos und das bisschen Inhalt ist falsch

 

[bronks]

... Man kann mittlerweile auch vernünftig mit purem JEE arbeiten und ab JEE6 sicher noch besser. Aber dieses Spring Bashing in letzter Zeit ist einfach dämlich ...

Ich mache am liebsten JavaSpec Bashing ... ...

Egal ob J2EE, EE5 oder jetzt aktuell EE6 ... ... Es wurde nichts besser sondern nur anders oder einfach nur anders gesagt verschlimmbessert. Mit externen Tools v.a. XDoclet war J2EE schon sehr brauchbar und eigentlich schon wirklich bequem und idiotensichert. Mit EE6 wirft man das ganze jetzt zum mehrfachen mal übern Haufen und trotzdem ist es immernoch nur akzeptabel mit Einschränkdungen was rauskommt.

Ist es von Sun so gemeint und gewollt, daß JEE nur als Unterlage für diverse EeFrameworks akzeptiert und verwendet wird?

Man könnte meinen, daß wir mit den Versionssprüngen und Veränderungen gerade einen schnellen Fortschritt erleben, aber m.E. ist es ein hilfloses Herumpaddeln gegen die Akzeptanz der Kundschaft.

 

[deamon]

Ich mache am liebsten JavaSpec Bashing ... ...

Egal ob J2EE, EE5 oder jetzt aktuell EE6 ... ... Es wurde nichts besser sondern nur anders oder einfach nur anders gesagt verschlimmbessert. [...] Mit EE6 wirft man das ganze jetzt zum mehrfachen mal übern Haufen und trotzdem ist es immernoch nur akzeptabel mit Einschränkdungen was rauskommt.

Das sagt sich leicht, aber welche Fakten lassen dich zu dieser Einschätzung kommen?

 

[deamon]

Ach, Stateless & stateful SessionBeans sollen POJOS sein?

Ja. Siehe auch: Creating the Enterprise Bean - The Java EE 5 Tutorial

 

[maki]

Ja. Siehe auch: Creating the Enterprise Bean - The Java EE 5 Tutorial

Was nutzt das wenn man keinen richtigen Test dafür schreiben kann ohne gleich einen JEE AppServer hochfahren zu müssen?
Sind halt doch Abhängigkeiten drinnen die nicht ins POJO Ürinzip passen.

Jeder sich sich mal ernsthaft & vernünftig mit beiden Themen, JEE & Spring auseinandergestzt hat wird niemals sagen das Spring veraltet, kompliziert oder nicht mehr verwendet werden sollte.

Die sog. "Meinungen" die du hier postest sind imho nix weiter als nachgeplappertes Marketinggeschwätz das nichts mit den eigentlichen Vor- und Nachteilen zu tun hat.

Das Adam Bien nix weiter zu sagen hat als "JEE ist beste von der Welt, Spring ist Teufel!" überrascht genausowenig wie wenn Rod Johnson sagt "Spring ist beste von der Welt, JEE ist Teufel!", das ist Marketing, nix weiter.

Traue keinem der nicht beides gut kennt und verwendet hat... auf alles andere kann ich verzichten

 

[JanHH]

So rein philosophisch betrachtet ist, denke ich, die Zukunftssicherheit der einzig wirklich wichtige Aspekt. Da spring aus der Motivation entstanden ist, eine Alternative zum offenbar kaum brauchbaren J2EE zu schaffen, verliert es immer mehr seine Daseinsberechtigung, je mehr die Mängel bei JEE selber ausgemerzt werden. Irgendwann wird spring einfach überholt und überflüssig. Eine parallele Existenz zweier Techonolgien für quasi denselben Einsatzzweck halte ich hier für eher wenig realistisch.

Wenn man also schon spring kann, und relativ schnell eine Applikation braucht, deren garantierte Zukunftssicherheit nicht so wichtig ist, wäre spring die naheliegende Wahl, wenn es aber ein grosses und wichtiges Projekt ist, welches noch eine lange Zukunft haben soll, dann eher JEE..

 

[tfa]

Irgendwann wird spring einfach überholt und überflüssig.

Warum?
Wieso sollte die Weiterentwicklung hier stehen bleiben?

Eine parallele Existenz zweier Techonolgien für quasi denselben Einsatzzweck halte ich hier für eher wenig realistisch.

So wenig realistisch wie die parallele Existenz von Eclipse und Netbeans? Hibernate und EclipseLink? Windows und Linux? Python, Groovy, Ruby?
Auswahl ist gut! Das belebt die Entwicklung, und letztendlich profitieren alle davon (in diesem Beispiel hat sicherlich JEE mehr von Spring profitiert).

Wenn man also schon spring kann, und relativ schnell eine Applikation braucht, deren garantierte Zukunftssicherheit nicht so wichtig ist, wäre spring die naheliegende Wahl, wenn es aber ein grosses und wichtiges Projekt ist, welches noch eine lange Zukunft haben soll, dann eher JEE..

Aus welchem Grund sollte Spring weniger zukunftssicher sein als reines JEE?

 

[maki]

So rein philosophisch betrachtet ist, denke ich, die Zukunftssicherheit der einzig wirklich wichtige Aspekt. Da spring aus der Motivation entstanden ist, eine Alternative zum offenbar kaum brauchbaren J2EE zu schaffen, verliert es immer mehr seine Daseinsberechtigung, je mehr die Mängel bei JEE selber ausgemerzt werden. Irgendwann wird spring einfach überholt und überflüssig. Eine parallele Existenz zweier Techonolgien für quasi denselben Einsatzzweck halte ich hier für eher wenig realistisch.

Wenn man also schon spring kann, und relativ schnell eine Applikation braucht, deren garantierte Zukunftssicherheit nicht so wichtig ist, wäre spring die naheliegende Wahl, wenn es aber ein grosses und wichtiges Projekt ist, welches noch eine lange Zukunft haben soll, dann eher JEE..

Schon wieder dieses Marketing Gerede... Spring ist bis jetzt zukunftssicherer gewesen als EJBs, wenn man sich überlegt was sich bei EJBs seit J2EE 1.3 alles geändert hat, dann ist Spring sehr stabil... und nein, Spring und JEE sind nicht ausschliesslich parellele Technologien, sie können sehr gut kombiniert werden.

Während Spring sich jetzt bereits um die integration aktueller Technologien bemüht (BlaseDS, OSGi, etc) hinkt JEE mal wieder ein paar Jahre hinterher, ist JEE deswegen "böse"? Wohl kaum.. nur rückständig
Mal ernsthaft, ihr solltet aufhören das als "entweder/oder" Situation zu betrachten.

 

[JanHH]

Also auf einen Zeitraum von ca. 15 jahren betrachtet bin ich mir recht sicher dass JEE langlebiger sein wird als Spring.

Ausserdem: Es war ja eine entweder/oder-Frage. Auch wenn man nicht wirklich denkt, dass eins von beiden das andere überleben wird, nach IRGENDWELCHEN Kriterien muss man sich ja entscheiden. Sonst könnt man auch ne Münze werfen. Und das ist der einzige, der mir da überhaupt zu einfällt. Evtl. noch clustering. Hängt halt auch stark von der bisherigen Erfahrung des Programmieres und der Art des Projektes ab.

 

[bronks]

Also auf einen Zeitraum von ca. 15 jahren betrachtet bin ich mir recht sicher dass JEE langlebiger sein wird als Spring ...

Wer verwendet ernsthaft und auch für kritische Angelegenheiten JEE? Studenten, Schüler und Neulinge, die sich einfach mal einarbeiten möchten. Dazu ist es gut geeignet, da man genötigt ist, den Patternkatalog durchzuarbeiten. Wenn man damit durch ist, dann stellt man sich die Frage, ob das ganze Java Enterprise Zeug wirklich nötig ist um, eine EnterpriseApp zu bauen.

Für eigentlich jedes Projekt, in dem ich mitgearbeitet habe, waren JEE-Kenntnisse Voraussetzung. Jedes mal war es eine respektable und bedeutende Software, aber JEE kam nie zum Einsatz (außer ein paar mittelmäßige WebApps). Mit EnterpriseJava beschäftige ich mich privat, soweit es sinnvoll ist, damit ich berechtigt sagen kann, daß ich damit was anfangen kann.

SAP hat auf J2EE gesetzt. SAP hat jetzt deshalb ein doppeltes Problem. Zum einen ist das alte und das neue Javazeug nicht so flexibel, daß man es problemlos modernisieren kann und aus diesem Grund ein verlängertes Leben von Java 1.4 wohl erkauft wurde. Zum zweiten kommt hinzu, daß Java jetzt unterm Pantoffel der schlimmsten Konkurrenz steht. Für die außenstehende Entwicklerwelt stellt sich auch nicht mehr die politische Weltverbesserungsfrage, sondern nur noch ob Oracle oder MicroSoft symphatischer daherkommt.

 

[deamon]

Wir haben festgestellt, dass Spring nicht nur Alternative sondern auch Ergänzung zu Java EE sein kann. Trotzdem würde ich gerne zunächst das ein oder (XOR) andere einsetzen. Bei Spring erscheint mir ingesamt der Lernaufwand höher, gerade Spring Security ist zum Teil fürchterlich komplex. Bei den folgenden Überlegungen hatte ich vor allem die Sicherheit der Anwendung im Kopf.

Warum Spring und nicht Java EE?
-------------------------------

* Mit JAAS besteht zwar ein Java-Standard für Authentifizierung und Autorisierung, aber der wurde in Java EE nicht wirklich integriert. Damit hat man bei Java EE kein durchgängiges Sicherheitsmodell. Die Einbindung von JAAS in Anwendungsserver hängt vom jeweiligen Hersteller ab. Spring bietet mit Spring Security ein durchgängiges Modell und auch JAAS kann eingebunden werden. Using JAAS in Java EE and SOA Environments | Java.net

* GlassFish kann mit beliebigen JAAS-Authentifizierungsverfahren erweitert werden, diese Erweiterungen sind allerdings nicht unabhängig von GlassFish nutzbar. Chapter 2 Securing Applications

* Spring vermeidet geprüfte Ausnahmen.

* Bei Spring ist praktisch jede Implementierung hinter einer Schnittstelle verborgen und kann deshalb durch eigene Implementierungen ausgetauscht werden.

* Spring erleichtert die Integration verschiedener Technologien.

* Eine Anwendungsumgebung in Spring muss zwar erst zusammengestellt werden, ist aber wesentlich modularer als der feste Satz von APIs eines Java-EE-Servers.

* AOP ist nicht auf wenige Spezialfälle beschränkt, sondern überall verfügbar.

Nachteile von Spring
--------------------

* Mehr Konfigurationsaufwand

* APIs sind zum Teil so abstrakt und umfangreich, dass das Verständnis nicht einfach ist (z. B. bei Spring Security).

* Spring erfindet teilweise das Rad neu, statt bestehende (Standard-)APIs zu verwenden, z. B. hätte Spring Security auf JAAS aufbauen können.

* Weniger Komfort als Java EE. Bei Java EE kann man z. B. mit zwei Annotationen beschreiben, dass eine Methode nur über eine sichere Verbindung (SSL) und nur von Nutzern einer bestimmten Rolle ausgeführt werden dürfen - um die Umsetzung kümmert sich der Container. Bei Springe wäre viel mehr Konfigurationsaufwand nötig.

Konkreter Anwendungsfall
------------------------

Ich will eine von außen über Servlets erreichbare Anwendung absichern. Den allgemeinen Zugriff könnte man mit URL-Mustern einschränken, aber diese Konfiguration stößt mit Frameworks wie Wicket oder JSF an seine Grenzen, wo die URLs nicht mehr so einfach und aussagekräftig sind. Es sollte auf jeden Fall also auch eine Absicherung auf Methodenebene möglich sein. Die Absicherung soll prinzipiell bis hinunter zu einzelnen fachlichen Objekten ("Bestellung") möglich sein. Und es soll ein externer Single-Sign-On-Dienst (SSO) verwendet werden. Der SSO-Dienst stellt also sicher, dass ein Nutzer mit einem bestimmten Namen authentifiziert ist; in der Anwendung wird dieser Name dann mit einer anwendungseigenen Repräsentation des Nutzers verbunden. Die Zuordnung des Nutzers zu seinen rollen soll getrennt von der Authentifizierung möglich sein.

URL-Muster wären weder bei Spring Security noch Java EE ein Problem. Die Absicherung von Methoden erfolgt bei Java EE mit einer einfach Annotation und der Rest macht dann der Container. Bei Spring sind die Java-Security-Annotationen scheinbar nicht vorgesehen, aber auch da könnte man mit entsprechender Konfiguration Annotationen nutzen. "Auspacken und einschalten" geht aber nicht wie bei Java EE.

Um die Sicherheit von einzelnen Objekten sicherzustellen, bieten sowohl das Portfolio von Sun also auch Spring Security Access Control Lits (ACL). Die Implementierung von Spring sieht wesentlich komplizierter aus, bringt dafür aber auch alles mit, was man für die praktische Umsetzung braucht - inkl. Schnittstelle zur DB, zur performanten Abfrage der ACLs. Genau an dieser Stelle hört der Funktionsumfang bei Sun auf (jedenfalls habe ich nichts mit der Spring-Implementierung vergleichbares gefunden).

Bei der Sache mit Single-Sign-On und austauschbaren (bzw. mehreren parallelen) Authentifizierungsverfahren schaue ich bei Java EE nicht ganz durch. Einerseits wird JAAS unterstützt, andererseits auch wieder nicht so richtig. Letztlich scheint es darauf hinauszulaufen, dass man für den jeweiligen Container eine Implementierung für ein bestimmtes Authentifizierungsverfahren braucht, wobei letztlich wohl doch JAAS genutzt wird. Bei Spring Security läuft die Authentifizierung (bzw. Schnittstellen zu externen Diensten) dagegen in der Anwendung und nicht im Container ab. Dementsprechend einfach ist es, beliebige Authentifizierungsverfahren einzubinden, ohne sich dabei an einen bestimmten Container zu binden. Wenn man die Authentifizierung gelöst hat, stellt sich mir bei Java EE aber immer noch die Frage, wie man seine authentifizierten Nutzer dann unabhängig vom Container mit Rollen versieht.
Wie gesagt, so richtig durchschaue ich das noch nicht und lasse mich gerne berichtigen.

Die größere Flexibilität spricht für Spring und der größere Komfort und "den Entwickler führen" für Java EE. Bei einer Entweder-Oder-Entscheidung tendiere ich gerade eher zu Spring, weil ich fürchte, mit Java EE früher oder später doch Spring nutzen zu müssen und dann könnte ich es auch gleich von Anfang an nehmen.

Wie seht ihr das?

 

[byte]

Gute Zusammenfassung. Könnte man so wohl unterschreiben.

Spring Security ist in der Tat am Anfang relativ komplex. Es gibt sehr viele Abstraktionsschichten, die man erstmal durchschauen muss. Hat man dann aber verstanden, wie das Ganze zusammenhängt, wie AuthenticationManager, AuthenticationProvider, AuthorizationManager, RoleVoter usw. funktionieren, dann entpuppt sich das Ganze als gut durchdachtes und extrem mächtiges und flexibles Werkzeug.

ACLs unterstützt Spring Security auch. Ein enstprechendes DB Schema + Vorgehensweise ist in der Doku. beschrieben. Die ist übrigens sehr gut und umfangreich beschrieben. Spring halt. Man kommt wohl kaum drum herum, da ein wenig drin zu lesen.

 

[JanHH]

Hatte ich schon seam erwähnt, wo das ganze Thema mit Authentifizierung, Sicherheit usw. hervorragend abgedeckt wird? ;-)

Ansonsten, ohne das wirklich beurteilen zu können, hatte ich den Gedanken, ob der ganze Ansatz mit so komplexen Frameworks nicht viel zu umständlich ist, wenn es nur darum geht, eine Servlet-basierte Anwendung abzusichern. Vielleicht lässt sich das auch mit simplen Servlet-Filtern machen.

 

[byte]

Klar lässt sich das auch mit ServletFiltern machen. Aber ob es dadurch einfacher wird, weiss ich nicht. Und so kompliziert sind die Frameworks nun auch nicht. Klar, man muss sich erstmal einlesen. Aber wenn alles auf Knopfdruck ohne nachdenken funktionieren würde, dann könnte man unseren Berufsstand auch abschaffen und einen Affen hinsetzen, der die Anwendungen schreibt.

Ich hab mich damals mal 3 Tage hingesetzt und die wichtigsten Kapitel der Spring Security Doku. gelesen. Danach lief die Geschichte. Im übrigen ist Seam doch genau so ein Framework!? Sehe da keinen Unterschied, ob ich mich nun in Spring oder in Seam einarbeite. Spring mag umfangreicher sein, das liegt aber nur daran, dass es fassettenreicher ist. Während Seam ganz spezielle Technologien unter einem Dach vereint (JSF, Hibernate, ...), unterstützt Spring halt alles. Der Trugschluss ist aber, dass man alles lernen muss. Man pickt sich halt das raus, was man haben will.

 

[deamon]

Seam ist ein guter Hinweis, als Schlagwort ist es mir schon länger bekannt, aber vielleicht sollte ich es mir mal näher ansehen.

Wenn die Anwendung tatsächlich nur aus ein paar einfachen Servlets bestehen würde, wären Servlet-Filter wohl tatsächlich ein guter Ansatz. Aber Servlets sind hier nur die grundlegende Infrastruktur und darauf wird alles mögliche aufsetzen, z. B. Web-Services oder Wicket-Anwendungen. Wenn es mal fertig ist, wird es ein ziemlich umfangreiches System.

 

[9xklug]

Was nutzt das wenn man keinen richtigen Test dafür schreiben kann ohne gleich einen JEE AppServer hochfahren zu müssen?
Sind halt doch Abhängigkeiten drinnen die nicht ins POJO Ürinzip passen.

Naja, es gibt ja nun sowas wie einen embedded EJB-Container der prima zum Testen ist:
Embedding EJB 3.1 Container Into Your Unit Tests - Boot Time: 5 Seconds : Adam Bien's Weblog
Ob ich nun Spring initialisieren muss oder den embedded Container macht keinen großen Unterschied.

 

[maki]

Naja, es gibt ja nun sowas wie einen embedded EJB-Container der prima zum Testen ist:
Embedding EJB 3.1 Container Into Your Unit Tests - Boot Time: 5 Seconds : Adam Bien's Weblog
Ob ich nun Spring initialisieren muss oder den embedded Container macht keinen großen Unterschied.

Oh, seit ein paar Wochen (28. Sept. 2009) geht das anscheinend auch in EJB 3.1 mit einer Beta vom Glassfish EJB Server und einer Beta der IDE, oder waren es doch Alphaversionen?

Erwähnte ich den Begriff "Rückständig" schon? Ach ja, hatte ich schon erwähnt...

Der Unterschied ist eben die Erprobheit & Stabilität von Spring, klar, irgendwann kommt JEE 6 da auch hin, hoffentlich.
Abgehsehen davon dauert es keine 5 Sek. um Spring zu initialisieren
Man konnte schon immer einen AppServer per Build Script starten um seine Komponeneten per Integrationstest zu starten, war nur eine Frage des Aufwandes & der Zeit die es dauert.

Wie gesagt, beides ist nicht der heilige Gral, aber oft nützlich, sehe keinen Grund (ausser Marketing Gerede) das eine oder andere Kategorisch auszuschliessen.

 

[MQue]

Spring Security ist in der Tat am Anfang relativ komplex.

Bin auch gerade beim Kapitel String Security im Buch Spring in Action und hab ein bisschen den Überblick verloren, mit ist das Zwiebelschalenmodel ansich geläufig aber welche Bean ich da in welcher injizieren muss, da hab ich absolut den Durchblick verloren.
Du schreibst auch, dass du dir die Doku von Spring durchgelesen hast, vielleicht ist es dort übersichtlicher dargestellt. Werd mir auch den Programmcode mal ansehen der beim Buch dabei ist, vielleicht steig ich da besser durch,
habt ihr noch einen Tipp wie ich den Überblick über Spring Security am besten erlangen kann.

lg

 

[byte]

Ich hab mir die Spring Security Dokumentation genommen und dort erstmal Part I und Part II durchgearbeitet. Hab mir dabei ein paar Notizen gemacht, welche Komponenten des Frameworks welche Aufgaben erfüllen und wie diese zusammenspielen. Wenn man das kapiert hat, dann kann man sich gezielt die Teile in Part III angucken, die einen interessieren, also z.B. Form Based - oder LDAP Authentication. In meinem Fall war PreAuthentication Scenarios interessant, weil es bei meinem AG ein proprietäres Login System gibt, das wir nutzen. Das heisst, wenn eine Connection zum Server kommt, dann fand der Login schon statt und es sind gewisse Informationen über den User als Cookie gesetzt. Diese lese ich dann nur noch aus und setze die Authentication im SecurityContext.

Autorisierung ist dann imo wieder recht simple. Mache da allerdings kein ACL, sondern kombiniere Method Security (per Annotation mit @Secured) zusammen mit ein paar eigenen AfterInvocationProvidern, die nochmal prüfen, ob das Result des Method-Calls gemäß den Rechten des Users ok ist.

 

[JanHH]

Hier ist ein grober Überblick:

http://www.pdbm.de/skripte/seam-kapitel-4-print.pdf

 

[9xklug]

Oh, seit ein paar Wochen (28. Sept. 2009) geht das anscheinend auch in EJB 3.1 mit einer Beta vom Glassfish EJB Server und einer Beta der IDE, oder waren es doch Alphaversionen?

Erwähnte ich den Begriff "Rückständig" schon? Ach ja, hatte ich schon erwähnt...

Der Unterschied ist eben die Erprobheit & Stabilität von Spring, klar, irgendwann kommt JEE 6 da auch hin, hoffentlich.
Abgehsehen davon dauert es keine 5 Sek. um Spring zu initialisieren
Man konnte schon immer einen AppServer per Build Script starten um seine Komponeneten per Integrationstest zu starten, war nur eine Frage des Aufwandes & der Zeit die es dauert.

Wie gesagt, beides ist nicht der heilige Gral, aber oft nützlich, sehe keinen Grund (ausser Marketing Gerede) das eine oder andere Kategorisch auszuschliessen.

Versuchst Du jetzt ernsthaft zu verkaufen, dass Java EE jünger als Spring ist? Mal davon ab, dass es wohl keine Rolle spielt, ob das Feature gestern verfügbar war. Es ist heute verfügbar und seit kurzem eben auch in der Implementation Glassfish (es gibt mehr als eine Java EE Implementation - openEJB kann schon länger embedded genutzt werden).

@byte Ich hoffe Dein AG liest nicht mit oder hat zumindest genug Humor und kein Problem damit, dass Du Details über seine "Security" Features ausplauderst. :toll:

 

[tfa]

Versuchst Du jetzt ernsthaft zu verkaufen, dass Java EE jünger als Spring ist?

Versuchst du ersthaft anzuzweifeln, dass Spring älter ist als EJB3.1 oder JEE 5 (bzw. 6)?

Mal davon ab, dass es wohl keine Rolle spielt, ob das Feature gestern verfügbar war.

Und was, wenn dein Projekt schon seit gestern entwickelt wird? Dann kann man nicht bis morgen warten. Warum sollte man nicht etwas nehmen, was die Features schon bietet, stabil funktioniert und etabliert ist? Überflüssig zu warten, bis JEE in die Strümpfe kommt. Nur weil man damit einen (vermeindlichen) Standard hat?

 

[byte]

@byte Ich hoffe Dein AG liest nicht mit oder hat zumindest genug Humor und kein Problem damit, dass Du Details über seine "Security" Features ausplauderst. :toll:

Mal abgesehen davon, dass wir keine Security by Obfuscation betreiben, welche Details sollten das denn sein, die ich ausgeplaudert habe? :noe:

 

[maki]

Versuchst Du jetzt ernsthaft zu verkaufen, dass Java EE jünger als Spring ist? Mal davon ab, dass es wohl keine Rolle spielt, ob das Feature gestern verfügbar war. Es ist heute verfügbar und seit kurzem eben auch in der Implementation Glassfish (es gibt mehr als eine Java EE Implementation - openEJB kann schon länger embedded genutzt werden).

Ja, JEE6 ist viel jünger als zB. Spring 2.5
Die Features von denen du sprichst sind nur als Beta bzw. Nightly Build verfügbar, oder willst du das abstreiten?
Und OpenEJB verhält sich nunmal doch etwas anders als JBoss oder WebSphere...

 

[9xklug]

Wenn Dein Projekt gestern schon entwickelt wurde, stellt sich üblicherweise die Frage nach der zu verwendenenden Technologie nicht mehr.
Und OpenEJB verhält sich an welcher Stelle anders als ein WebSphere? (openEJB ist die EJB Implementation von Websphere CE). Von mir aus kannst Du auch JBOSS embedded nehmen oder EasyBeans oder sonstwas. Es gibt ziemliche viele Implementationen vom Standard. Das macht den Charme eines Standards aus.
Und klar ist Java EE 6 jünger als Spring 2.5. Aber das macht die Argumentation ziemlich albern, oder? Oracle 11g ist auch jünger als z.B. MySQL 5.
Mal davon ab, dass für mich persönlich die Möglichkeit einen embedded Container zu nutzen nicht gerade ausschlaggebend wären.
Was mir an Java EE gefällt ist, dass ich weniger schreiben muss, weniger konfigurieren muss, verteilte Transaktionen und Thread Management habe. Meist komme ich sogar mit dem Standard so weit hin, dass ich keine weiteren Abhängigkeiten habe. Je weniger externe libs ich habe, desto geringer die Gefahr eines Versionsclashes.
Ja, ich weiß, bei Java EE sind die ganzen Abhängigkeiten in externe libs im AppServer. Da sind sie aber nicht mein Problem sondern die des AppServer Herstellers. Wen ich sie aber mit meiner Spring App mit ausliefere, sind sie sehr wohl mein Problem.
Ob ich nun den alten Tomcat installiere oder nen Glassfish, Geronimo, JBoss, WebLogic (der übrigens intern Spring nutzt) oder nen Websphere macht nicht so wahnsinnig viel Unterschied - außer dass ich bei den AppServern das Ressourcemanagement schon mitkriege.
Wenn jedoch "embedded" ganz oben auf meiner Prio Liste steht, ok, dann kann ich nen jetty nehmen und da dann halt Spring oder openEJB Kram mit meiner App reinembedden und gut. Meist sind solche Apps aber eher einfach, so dass man auch kann ohne EJB und Spring hinkäme und oft auch muss, weil auf dem Endgerät einfach der Speicher begrenzt ist. Ich glaube in so einer Konstellation würde ich generell eher zu was coolem wie Lift Web greifen. Lift 1.0 ist glaube ich auch älter als Spring 3.

 

[maki]

Wenn die tests auf einem OpenEJB Server erfolgreich sind, ist das noch keine Garantie dass es sich auf dem richtigen Server auch so verhält, da hat man mit Spring schon einen Vorteil wenn es um Integrationstests geht, diese laufen nämlich sehr schnell und es gibt keine Implementierungsunterschiede.

Wenn man bedenkt wie sehr sich die JPA 1.0 Implementierungen unterscheiden und wie lückenhaft JPA 1.0 ist, kommt man sehr schnell an den Punkt an dem man sich nicht mehr nur an den Standard halten kann und dann wieder gegen eine best. Implementierung entwickelt.
Schlimm? Nein, finde ich nicht.

Und klar ist Java EE 6 jünger als Spring 2.5. Aber das macht die Argumentation ziemlich albern, oder?

Du hattest mit "jünger" angefangen
Jedenfalls ist JEE6 noch nicht mal veröffentlicht... hier so zu tun als ob JEE6 Spring schon eingeholt hätte wäre etwas weit hergeholt.

Versionskonflikte von externen libs löst man am besten mit einem Buildsystem, sehr wichtig bei AppServer zB. in Verbindung mit Hibernate, wenn die SerialUID der Proxyklassen nicht übereinstimmt wundert man sich sonst..

Naja, ich kann nochmals wiederholen was ich schon ein paar mal sagte, Spring & JEE 6 schliessen sich nicht aus, ausser man ist Vertreter für einer der beiden und würde an derem Einsatz mitverdienen.

IMHO wird JEE6 und Spring sehr ähnlich sein, sodass selbst eine Migration von einem zum anderen nicht mehr soviel Aufwand wie früher bedeutete.

Wenn man globale Transaktionen & Clustering braucht, sind EJBs wohl der Weg, wenn man dagegen für OSGi entwickeln will, bietet Spring Möglichkeiten dafür.

 

[JanHH]

Ihr sollte aber alle nicht weiterdiskutieren bevor ihr euch seam angeschaut habt!

 

[byte]

Seam ist ein Framework für Webanwendungen. Das ist nur bedingt mit Spring oder JEE im Allgemeinen vergleichbar.

Ich schreibe zur Zeit z.B. eine EE Anwendung mit Richclient als Frontend. Was nützt mir da Seam?

 

[JanHH]

War auch ein wenig ironisch/augenzwinkernd gemeint.