Wie findet ihr eigentlich Seam?

[JanHH]

Hallo,

ich sehe mich mit zwei Sichtweisen konfrontiert.. die eine ist, dass es langfristig immer vernünftig ist, sich an das zu halten, was sich in der Industrie als Standard durchsetzt, und das ist halt JSF (Facelets), JPA (Hibernate), Seam und JBoss. Grosse Firmen setzen auf diese Technologien, da sie, aufgrund der Standardiesierung, am meisten Zukunftssicherheit bieten.

Andere Leute hingegen sehen das offensichtlich anders, oder bevorzuge ältere Techniken wie struts (2), Spring, Tapestry..

Wie seht ihr das? Bin unschlüssig worauf ich nun setzen soll .

Gruß
Jan

 

[maki]

die eine ist, dass es langfristig immer vernünftig ist, sich an das zu halten, was sich in der Industrie als Standard durchsetzt, und das ist halt JSF (Facelets), JPA (Hibernate), Seam und JBoss. Grosse Firmen setzen auf diese Technologien, da sie, aufgrund der Standardiesierung, am meisten Zukunftssicherheit bieten.

Kenn ich anders, wirklich große Firmen setzen auf Oracle (WebLogic, etc. pp.), IBM (WebSphere, etc.), SAP (NetWeaver, etc.) oder gar MS (.NET, etc.)... JBoss kenne ich ehrlich gesagt nur ein paar kleineren Abteilungen der großen Firmen, aber Tomcat zB. sehe ich fast überall.
Die Entscheidung hat imho übrigens weniger mit Standards & Zukunftssicherheit und mehr mit "Vertriebsschlampen" und deren Präsentation inkl. "Schmiergeld" zu tun.

Andere Leute hingegen sehen das offensichtlich anders, oder bevorzuge ältere Techniken wie struts (2), Spring, Tapestry..

Naja, wenn man keine Lust hat jahrelang zu warten bis ein paar Gremien (die alle aus den "großen" bestehen) endlich soweit sind ihre Lückenhaften Specs. mit den aktuellen Technologien und Modellen (wie zB. Spring sie nutzt ) zu vervollständigen, greift man eben zu Spring

Wie seht ihr das? Bin unschlüssig worauf ich nun setzen soll

Wenn du jetzt zB. auf Spring setzt, kannst du jetzt schon so Entwickeln wie in ein paar Jahren mit JBoss

Mal ernsthaft, ich denke dass alle Seiten Vor- und Nachteile haben, über EJB2.x brauchen wir hoffentlich nicht mehr zu diskutieren (), aber selbst in EJB3.0 ist nicht alles Gold, die DI die es bietet ist Lückenhaft, 3.1 soll Besserung schaffen, aber Spring bietet schon seit Jahren mehr in diesem Bereich.

Bei JEE stören mich immer mehr diese "Expertengruppen", zB JDO, wurde abgesägt, weil Oracle & IBM Angst um ihr RDBMS Geschäft hatten, als Ersatz gab es dann JPA 1.0, was in seiner "reinen" Form gar nicht zu gebrauchen war, jetzt endlich soll JPA2.0 erscheinen...

Mit Seam hab ich mich ehrlich gesagt noch gar nicht auseinandergesetzt(ausser theoretisch), bin schon länger nicht mehr im JBoss Umfeld unterwegs.

 

[Noctarius]

Bei dem Argument "Spring" in Kombination mit "alt" drehte sich mir ja fast der Magen um

Ansonsten sehe ich es eigentlich wie maki, bis auf die JPA / JDO Diskussion
Ich mag JPA, vermutlich weil ich immer das Problem hab, dass ich Daten sauber von XML in die DB bekommen muss und da ist ein Bean mit JAXB und JPA Annotations grandios

 

[JanHH]

Es ist halt schwer abzuschätzen, in welche der vielen vielen Technologien man sich nun einarbeiten sollte. Es kommt ja eigentlich nur eine in Frage, wenn man sich nicht immer nur neu einarbeiten, sondern auch mal wirklich arbeiten möchte. Ich habe zwar kompetente Ratgeber, aber die sagen alle eindeutig "JBoss, Facelets, Seam". Spring sei gut aber veraltet, die Konzepte würden alle in Seam/EJB3 Einzug finden und das wäre dann der Standard, der weiterentwickelt wird. Ich möchte ja auch noch möglichst in fünf Jahren mit der Technologie arbeiten können, die ich jetzt lerne. Allein daher scheint mir ein sich-halten an den offiziellen java-Standard schon sinnvoll.

Frage mich allerdings auch.. wenn man gar keine EJBs braucht (und wozu brauche ich die, bei einer relativ normalen Webanwendung, die nun nicht gerade ein megagrosses Shoppingsystem werden soll?), kann man dann nicht ganz einfach mit JSF und JPA/Hibernate arbeiten, sich ein paar Hilfsfunktionen zum aneinanderkleben der beiden Schichten programmieren, und gut ist? Gleich ein EJB-System zu benutzen oder sich in komplexe Dinge wie Spring oder Seam einzuarbeiten kommt mir da etwas wie "mit Kanonen auf Spatzen schiessen" vor. Ich komme gut mit JSF klar, ich komme gut mit JPA klar, kann ich mich dann nicht einfach erstmal darauf beschränken?

 

[FArt]

Mit Seam ist man relativ flexibel. Es gibt einen relativ einfachen Workflow und man kann schnell anspruchsvolle Enterpriseapplikationen erstellen, besonders mti der aktuellen IDE Unterstützung.

Wenn man möchte, hat man die Möglichkeiten beliebig komplex zu werden (inklusive JBoss Clustering). Seam versteckt viel Komplexität und nimmt einem viel Standardarbeit ab. Die Verknüpfung von View, Businesslogik und Daten ist relativ magisch, generisch abgekapselt. Und genau dieses Stärke ist auch eine Schwäche: wenn man vom Standard abweichen muss, dann braucht man das Wissen über die Magie und sollte fit sein in der Anwendung der verschiedensten Pattern.

Die Ansätze sind aber nicht neu und: MVC, IoC, contextual environment, ...

 

[maki]

Ansonsten sehe ich es eigentlich wie maki, bis auf die JPA / JDO Diskussion
Ich mag JPA, vermutlich weil ich immer das Problem hab, dass ich Daten sauber von XML in die DB bekommen muss und da ist ein Bean mit JAXB und JPA Annotations grandios

Annotations gibt es mittlerweile auch in JDO, das war aber nicht der Punkt, auf den ich raus wollte: Du musst Erweiterungen deiner JPA Implementierung nutzen, oder? Dann bist ja schon nicht mehr Standardkonform zu JPA

 

[Noctarius]

Nö muss ich nicht. Bisher bin ich mit dem Spec Umfang auch zum Ziel gekommen. Einziges echt großes Manko ist Lazy-Fetching bei m:n Zuordnungen

 

[byte]

JPA 1.0 kennt keine echte List-Semantik, das alleine machts schon unbrauchbar in meinen Augen. Oder kennt jemand ein JPA-Lösung zu Hibernates @IndexColumn?

 

[JanHH]

@FArt genau das wurde mir bisher auch immer über seam gesagt. Scheint eine erhebliche Vereinfachung zu sein, wenn man ganz normale, relativ komplexe Webapplikationen schreiben will.

JPA kann man da aber ganz normal benutzen, ausserdem ist seam vom gleichen Menschen wie Hibernate, das wird also sicher passen. Und ob JPA nun eine List-Semantik hat (was ist das überhaupt?), ist mir total egal..

 

[byte]

Und ob JPA nun eine List-Semantik hat (was ist das überhaupt?), ist mir total egal..

Wie mapst Du denn Listen mit Hibernate? Hast Du schonmal die Reihenfolge der Listen-Elemente verändert bzw. Elemente in die Liste eingefügt und Dir das erzeugte SQL angeguckt? Offenbar nicht...

 

[Noctarius]

	@OneToMany(targetEntity = ParameterImpl.class, fetch = FetchType.EAGER, cascade = { CascadeType.ALL })
	@JoinTable(
			name = "jobparameters",
			joinColumns = @JoinColumn(name = "job_id"),
			inverseJoinColumns = @JoinColumn(name = "parameter_id")
	)
	private List<IJobParameter> parameter = new ArrayList<IJobParameter>();

So Unschön aber geht

 

[maki]

JPA kann man da aber ganz normal benutzen, ausserdem ist seam vom gleichen Menschen wie Hibernate, das wird also sicher passen. Und ob JPA nun eine List-Semantik hat (was ist das überhaupt?), ist mir total egal..

Hmm... "ganz normal benutzen", nicht in meiner Erfahrung, aber die kann anders als deine sein, Noctarius scheint ja auch zurechtzukommen (obwohl ich keine Ahnung habe wie, ich komm mit JPA 1.0 nicht weit).

Was aber unzweifelhaft ist, ist das JPA 1.0 sehr Lückenhaft ist, und nicht annähernd an den Funktionsumfang von Hibernate selbst oder Toplink kommt, von JDO ganz zu schweigen.

 

[Noctarius]

Das stimmt allerdings maki, JPA 1.0 lässt noch vieles, was Toplink (bzw EclipseLink) oder Hibernate bereits implementiert haben, als Standard noch fehlen.

Dann muss man sich mit Dingen behelfen, wie obigem Beispiel. Eine Semantik für Liste aus Table-Joins von Hand zu bauen sollte eigentlich (zu mindestens in diesem Fall) absolut überflüssig sein, aber JPA 2.0 wird ja das Meiste nachreichen.

Ich bin mal gespannt, bisher sieht JPA 2.0 absolut viel versprechend aus.

 

[byte]

	@OneToMany(targetEntity = ParameterImpl.class, fetch = FetchType.EAGER, cascade = { CascadeType.ALL })
	@JoinTable(
			name = "jobparameters",
			joinColumns = @JoinColumn(name = "job_id"),
			inverseJoinColumns = @JoinColumn(name = "parameter_id")
	)
	private List<IJobParameter> parameter = new ArrayList<IJobParameter>();

So Unschön aber geht

Das ist halt Bag Semantic und da ist das erzeugte SQL halt teilweise furchtbar. Angenommen Du hast eine Liste mit 500 Elementen. Nun fügst Du ein neues Element irgendwo ein. Hibernate macht daraus 500 DELETEs und 501 INSERTs. Prost Mahlzeit...

 

[Noctarius]

EclipseLink macht daraus eins

 

[byte]

Und ignoriert demnach die Reihenfolge der Elemente in der Liste => keine List Semantik

 

[Noctarius]

Nö ich glaub es wird eine Sortierfolge mitgespeichert. Will es aber nicht beschwören und bin gerade zu faul in der Datenbank nachzusehen.

edit: Nee vergiss es wird es nicht Es hat mich dann doch interessiert.

 

[JanHH]

Also ich kann nur aus meiner bescheidenen Erfahrung berichten dass ich mit JPA überhaupt keine Probleme habe, alles sehr klar und logisch scheint, gut dokumentiert und gut zu benutzen ist. Bei Listen keine Reihenfolgen mitzuspeichern scheint mir keine JPA-Schwäche, sondern allgemeines SQL-Konzept zu sein, wo man ja auch nie weiss, in welcher Reihenfolge die Ergebnisse eines Select-Statement kommen. Wenn die Reihenfolge wichtig ist, kann man doch einfach einen per Hand generierten Zähler mitspeichern (sofern einem die automatisch generierte ID nicht ausreicht), was ich gar nicht schlimm finde, denn ohne JPA hätte man es eh tun müssen..

Mich beschleicht allerdings das Gefühl, dass es die Tendenz gibt, immer grundsätzlich alles schlechtmachen zu wollen, vor allem das, was langweiliger offizieller Standard geworden ist. Sicherlich geht es immer noch irgendwie besser, aber man kann doch auch mal das, was JSF, JPA usw einem an Erleichterungen (gegenüber dem, wie es ohne diese Technologien wäre) bringt, wertschätzen und damit zufrieden sein..

 

[byte]

Keine Ahnung, warum Du Dich so ereiferst. Ich habe überhaupt nix gegen JPA, benutze es selber, aber brauche an einigen Stellen eben Erweiterungen, weil JPA 1.0 halt bestimmte Probleme nicht zufriedenstellen lösen kann.

Sicherlich geht es immer noch irgendwie besser, aber man kann doch auch mal das, was JSF, JPA usw einem an Erleichterungen (gegenüber dem, wie es ohne diese Technologien wäre) bringt, wertschätzen und damit zufrieden sein..

Moment. Hast Du nicht grade nach Seam gefragt? Also bist Du doch offenbar mit JSF auch nicht ganz zufrieden.:bahnhof:

 

[JanHH]

Na, ereifern ist übertrieben.. aber ist so eine allgemeine Tendenz, die ich hier manchmal empfinde.

Mir fehlt es an Vergleichsmöglichkeiten, JSF ist das erste Web-Framework, welches ich überhaupt benutze (bin relativ neu in der Materie). JPA ist dann ja die naheliegende Lösung für Datenbank-Anbindung. Die Frage ist dann, dabei bleiben, oder gleich noch seam hinzuziehen, weil ich den Eindruck habe, erst dadurch wirds "richtig rund". Aber ich bin da auf das Urteil einiger weniger Personen angewiesen und kann selber kaum vergleichen. Daher die eigentliche Frage, siehe Threadtitel.

Oder halt.. von vielen Leuten gesagt bekommen dass eine ganz andere Variante (Spring?) die eigentliche erste Wahl ist.

Mir erscheint allerdings JSF mit seam, Facelets und JPA schon ziemlich leistungsfähig zu sein.

 

[maki]

Also ich kann nur aus meiner bescheidenen Erfahrung berichten dass ich mit JPA überhaupt keine Probleme habe, alles sehr klar und logisch scheint, gut dokumentiert und gut zu benutzen ist.

Vielleicht weisst eben bestimmte Dinge noch nicht... ???:L
Eine Meinung zu haben ist ja gut und schön, aber man sollte schon ein bisschen Erfahrung mitbringen und vor allem vergleichen können mit dem was es sonst so gibt.

Bei Listen keine Reihenfolgen mitzuspeichern scheint mir keine JPA-Schwäche, sondern allgemeines SQL-Konzept zu sein, wo man ja auch nie weiss, in welcher Reihenfolge die Ergebnisse eines Select-Statement kommen.

Ähh, nein, ganz und gar nicht.
Das ist eine direkte "Schwäche von JPA 1.0, JPA 2.0 kann es ja auch, Hibernate und Toplink sowieso.
Zum Thema SQL, [c]order by[/c] sagt dir etwas?

Mich beschleicht allerdings das Gefühl, dass es die Tendenz gibt, immer grundsätzlich alles schlechtmachen zu wollen, vor allem das, was langweiliger offizieller Standard geworden ist.

Der Eindruck täuscht, liegt imho einerseits an deiner mangendeln Erfahrung und andereseits daran, dass deine Kollegen auch schon polarisiert sind.

Die Probleme mit JPA 1.0 sind doch hier angesprochen worden, diese Probleme sind weit verbreitet, liegt eben an JPA 1.0, und du kennst/verstehst sie nicht also müssen alle die diese Probleme haben grundsätzlich gegen Standards sein??

Sorry, aber du hast doch schon in deinem ersten Post Spring etc. als "ältere Technik" abgestempelt, ohne dich je damit auseinandergesetzt zu haben, und weil wir nicht auf den Zug "Standards sind am besten, Seam forever!" aufspringen, sind wir grundsätzlich gegen JEE?

Mag ja sein dass wir die Dinge nicht genauso sehen wier deine Kollegen, aber wenn wir schon über konkrete Probleme Diskutieren (s.o.), dann können wir doch auch zu konkreten Ergebnissen kommen, ob eine Spek./Framework etwas taugt oder nicht, unäbhängig davon ob es ein offizieller Standard ist oder nicht.

 

[byte]

Auf Standards bauen doch alle hier genannten Frameworks auf, sehe da echt keinen Unterschied. Seam benutzt JSF und setzt noch was oben drauf. Hibernate implementiert JPA und setzt noch was oben drauf, ebenso TopLink. Spring benutzt ettliche Standard Specs (Servlets, EJB, JPA, JMX, JMS, um mal ein paar zu nennen) und setzt noch was oben drauf.

 

[Noctarius]

Ihr und euer TopLink! TopLink gibt es nicht mehr als aktives Projekt ^^ Das heißt jetzt EclipseLink tztztztz Kinnaz Kinnaz ;-) (bzw es basiert nur noch auf EclipseLink)

Ich persönlich kann nichts zu seam und JSF sagen da ich noch nicht genug damit gearbeitet habe, finde aber (was ich so sah an JSF Kram) nicht sonderlich ansprechend.

Ich persönlich bin Verfechter der älteren Technik Spring (die gerade voll in der Entwicklung steckt und den ersten Milestone von Version 3 freigegeben hat). Übrigens älter heißt meistens ausgereifter und nicht umbedingt vom alten Eisen

 

[JanHH]

Na ich stempel gar nichts ab.. ich hab halt bestimmten Input und frage hier ja gerade deswegen nach anderen Meinungen, um nicht zu unreflektiert auf eine Schiene zu geraten.

Das mit der mangelnden Erfahrung ist sicherlich richtig, wobei ich schon reichlich Erfahrung mit Programmieren an sich hab, auch schon seit Jahren eine Java-Webanwendung auf Basis eines Servlets programmiere, aber diese Web-Frameworks für mich jetzt halt etwas neues sind, und auch meine Erfahrungen mit Datenbanken halten sich in Grenzen.

Frage mich nur, wie man noch Zeit zum eigentlichen Arbeiten haben soll, wenn man sich "nebenbei" so intensiv in diverse Frameworks einarbeiten soll.. wie macht ihr das? Daher auch meine Motivation, mich für eins zu entscheiden, und das dann zu vertiefen. Wobei, wie gesagt, JSF+JPA läuft schon sehr gut.

Naja und alles in allem.. in Bezug auf seam+jsf+jpa scheint ja zumindest keine explizit negative Meinung zu bestehen. Wird dann wohl nicht das verkehrte sein.

 

[JanHH]

Hm und noch was.. die besagten, schon vorgeprägten Kollegen machen durchaus grosse Projekte für grosse Firmen (die jeder der Leute hier auch kennt), und bekommt daher mit, auf welche Technologien in so einem Umfeld gesetzt wird. Und nach dem was ich da so höre werden da ganz eindeutig die standartisierten Sachen (also JSF, JPA usw.) gegenüber Struts, Spring usw. bevorzugt. Einfach deshalb weil man sich von der Tatsache, dass es der offizielle Standard ist, eine grössere Zukunftssicherheit verspricht, und es werden da ja nicht gerade geringe Summen in die Entwicklung investiert.

Mir gehts also auch gar nicht unbedingt um das "beste", sondern eher darum, sich nicht in etwas einzuarbeiten, was zwar überlegen sein mag, aber immer mehr ins Abseits gerät und kaum noch verwendet wird. Finde es daher nicht gerade abwegig, sich auf die JEE-Standards zu konzentrieren.

 

[Noctarius]

Wie bereits gesagt kann ich nur für Spring sprechen:
Spring hat eine eigentlich recht steile aber manchmal hollperige Lernkurve. Im Nachhinein sind aber auch die Hubbel doch immer logisch und nachvollziehbar gelöst, manchmal sieht man es nur auf den ersten Blick nicht.

So groß ist also die Einarbeitung in Spring nicht, zumal es sehr gut in Module (Einzelteile) geteilt ist und nur auf den ersten Blick viel größer wirkt als es ist. Oft braucht man viele der Module garnicht.
Das reine Spring-Core ist recht einfach zu beherrschen, der Rest kommt nach dem Verständnis vom Core vollkommen alleine. Spring-Connectoren oder Spring-Integration gibt es auch in vielen anderen externen Projekten. Damit ist gewährleistet, dass Interoparabilität mit anderen Frameworks (z.B. JDO oder JPA) gewährleistet ist.

 

[maki]

Hm und noch was.. die besagten, schon vorgeprägten Kollegen machen durchaus grosse Projekte für grosse Firmen (die jeder der Leute hier auch kennt), und bekommt daher mit, auf welche Technologien in so einem Umfeld gesetzt wird. Und nach dem was ich da so höre werden da ganz eindeutig die standartisierten Sachen (also JSF, JPA usw.) gegenüber Struts, Spring usw. bevorzugt. Einfach deshalb weil man sich von der Tatsache, dass es der offizielle Standard ist, eine grössere Zukunftssicherheit verspricht, und es werden da ja nicht gerade geringe Summen in die Entwicklung investiert.

Mir gehts also auch gar nicht unbedingt um das "beste", sondern eher darum, sich nicht in etwas einzuarbeiten, was zwar überlegen sein mag, aber immer mehr ins Abseits gerät und kaum noch verwendet wird. Finde es daher nicht gerade abwegig, sich auf die JEE-Standards zu konzentrieren.

EJB 1.x bis 2.x waren auch mal Standards, die heute nicht mehr relevant sind für neue Projekte.

Die Annahme "Standard = Zukunftssicher" ist leider nicht immer wahr, die Annahme jedoch "Kein Standard != Zukunftsicher" dagegen ist meist falsch, es kommt auf das eigentliche Projekt/Framework an. So einfach ist das leider nicht...
Einige Standards sind eben in ihrer Form so nicht nutzbar/lückenhaft oder einfach nur viel umständlicher als andere verbreitete Framework/APIs (BMP/CMP vs. Hibernate, EJB 2.1 vs. Spring, schon mal mit JSF 1.0/1.1 gearbeitet? Willkommen in der Hölle *g*), jedenfalls schadet es nicht wenn man sich auskennt, speziell Spring hat einige sehr gute Ansätze und stellt mittlerweile sein eigenes Ökosystem dar, dass natürlich in vollem Umfang auch sehr komplex ist. Aber wer braucht schon alles von einem Framework...

Spring & Hibernate wurde übrigens regelmässig mit EJB 2.x eingesetzt, um dessen Unzulänglichkeiten abzumildern. (Ganz abgesehen davon das Spring "jünger" als EJB ist.)
Man kann diese Dinge kombinieren, spart viel Code & Ärger und ist dabei Zukunftssicher

Schon klar dass man im JEE Umfeld vor allem Anfangs oft von schieren Ausmass der Speks/Standards/Frameworks/Server etc. pp. erschlagen wird, aber nach 'ner Weile sieht man dass dann klarer.

Nebenbei gefragt, wer Implementiert den Seam Standard eingentlich ausser JBoss? feif: Ich mein so ein Standard ist erst wirklich einer wenn es mehrere Umsetzungen gibt... ansonsten ist ja nur abhängig von diesem einem Hersteller... ist das "Zukunftssicher"?

 

[JanHH]

So wie ich es verstanden habe in diversen Unterhaltungen werden einzelne unabhängige Frameworks nach und nach in den JEE-Standard integriert. Aus dem Strust-Konzept wurde JSF (ist ja auch vom gleichen "Vater"), aus Hibernate wurde JPA, und nun finden Konzepte von Seam Einzug (Stichwort Webbeans). Ich denke mal, dass Seam in absehbarer Zeit nicht mehr ein separates Framework ist, sondern fester Bestandteil von JEE wird.

JSF mit Facelets, JPA und seam scheint mir dann doch schon eine recht leistungsfähige Konfiguration zu sein.

Wo hier so viel von Spring geredet wird.. mir erschliesst sich bisher nicht, worum es bei spring im Kern eigentlich geht. Hat aber eher mit Beans und Persistenz zu tun als mit dem Web-Frontend, oder?

 

[byte]

Spring beinhaltet auch ein Webframework, siehe dazu Spring WebMVC + Spring WebFlow.

 

[Noctarius]

Spring kennt folgende Komponenten:
- Spring Framework (oder Core) => Das eigentliche Dependency Injection und Bean-Lifecycle Management inklusive den gesammten Kernkomponenten wie dem MVC Handler, der Datenbankanbindung über Module für JDBC, JTA, JDO, JPA, usw.
- Spring Webflow => Ein einfach zu bedienendes, aber nicht minder Funktionsreiches Workflow und BPM Framework
- Spring WebServices => Ein Config oder Annotation driven WebService Framework auf Basis der SpringBeans
- Spring Security => Ein Sicherheitsframework zur Authorisierung von und gegen Benutzern oder anderen Servern mit automatischer Rollen-Injektion und Role-Voter
- Spring Dynamic Modules => Ein OSGi SpringBeans Configurator und Lifecycle Management Framework
- Spring Batch => Wie der Name schon sagt ein Batch Framework zur automatischen Ausführung von Prozession, Tasks auf einem oder mehreren Hosts
- Spring LDAP => Framework zum Zugriff auf LDAP Systeme (inkl Active Directory) und als Datenquelle z.B. für Spring Security
- Spring IDE => IDE für Eclipse zur Verwaltung der Möglichkeiten und Konfigurationsdateien der einzelnen Spring Module

Und noch einige mehr mit denen ich selbst auch noch nicht groß gearbeitet habe (zu mindestens nicht bewusst):
- Spring Integration
- Spring BlazeDS Integration
- Spring Extentions
- Spring Java Config
- Spring .NET
- Spring BeanDoc
- usw.

Wie du siehst ist Spring sehr modular und trotzdem extrem mächtig vom Funktionsumfang. Doch gerade diese Modularität macht es ansich sehr einfach zu lernen.

 

[JanHH]

Danke für die Erklärungen!

Dann könnte man einen Abstimmungsthread starten: Spring oder JSF/JPA/Seam? Man hat ja kaum die Zeit, sich in beides gründlich einzuarbeiten..

Wobei man, denke ich, davon ausgehen kann, dass die "Spring-Lastigkeit" der geäusserten Meinungen auch daran liegt, dass Spring sehr viel bekannter und verbreiteter, da älter ist. Kaum jemand scheint seam so gut zu kennen wie viele Leute spring. Bin nach wie vor unschlüssig was ich nun lernen soll. Aber wird wohl doch auf die JSF-Variante hinauslaufen.

 

[Noctarius]

Also ich persönlich behaupte jetzt: Die Abstimmung kannst du dir sparen.

Aus deinen vorran genannten Gründen wird definitiv Spring gewinnen, da es mehr Leute gibt die es kennen und benutzen (nicht nur im Webapp Bereich, sondern auch im Application Development), es älter ist, es sich immer noch aktiv in der Entwicklung befindet und es bereits extrem viele Spring Anwendungen gibt. Auch durch Spring Dynamic Modules werden in der OSGi-Zukunft viele Spring Anwendungen entstehen, auch wenn (ich das richtig verstanden habe) ein neuer OSGi Spec etwas ähnliches bringen soll wie die Spring DM.

 

[JanHH]

Tjo, so ist das wohl.. aber da ich JSF+JPA schon recht gut kenne und beherrsche, ist der Schritt zu seam natürlich naheliegend.

Was mich auch interessiert.. ab welchem Komplexitätslevel der Applikation braucht man all diesen EJB-Kram eigentlich? Kann man nicht auch einfach mit JSF und dem managed beans container sowie JPA vernünftige Applikationen schreiben? Mir ist nicht ganz klar was sowas wie Spring da dann noch erheblich vereinfachen soll (und bei seam auch nur teilweise). Klar, wenn man riesengrosse Unternehmens-Portale programmieren will, ist das alles sicher sinnvoll, aber bei einer eher kleinen Web-Anwendung? Ist das nicht "mit Kanonen auf Spatzen schiessen"? Immerhin will der ganze Kram ja auch installiert und konfiguriert werden, und man kommt nicht mit mit dem tomcat aus, sondern braucht gleich einen AS.. Oder lieg ich da voll daneben und EJBs sind eigentlich immer sinnvoll?

 

[Noctarius]

Prinzipiell mach ich auch kleinere Sachen mit Spring, da diese meist irgendwann wachsen.

Spring in ein Webprojekt zu bekommen ist für mich:
- neues Maven-Webapp-Project erzeugen
- pom.xml (Maven) um Dependencies erweitern
- Konfigurationsdatei für den Applicationcontext anlegen (nur wenige Zeilen)
- Meistens ein paar Annotations setzen und Beans konfigurieren
- Webapp starten

 

[maki]

Dann könnte man einen Abstimmungsthread starten: Spring oder JSF/JPA/Seam? Man hat ja kaum die Zeit, sich in beides gründlich einzuarbeiten..

Wie gesagt, in EJB2.1 war es nicht unüblich Spring & EJBs zu kombinieren, das geht übrigens immer noch

Aber denk dir nix, bis jetzt war jeder JEE Beginer total verwirrt von den ganzen Standards, APIs, Frameworks etc. pp.

Was mich auch interessiert.. ab welchem Komplexitätslevel der Applikation braucht man all diesen EJB-Kram eigentlich? Kann man nicht auch einfach mit JSF und dem managed beans container sowie JPA vernünftige Applikationen schreiben?

Ja, denn EJBs gibt einem nix was man nicht auch ohne EJBs machen könnte, bis auf EJBs selbst eben
Als ich 2001 einen Kurs bei Sun hatte, hies es ab 1000 Usern von denen 100 eingeloggt sind und arbeiten lohnen sich EJBs... naja, die Zeiten haben sich geändert.
Man kann mit EJB3.x prinzipiell jede Mehrschichtanwendung umsetzen, kann man aber auch mit Spring Oder mit beiden... oder eben ganz anders.

Wobei man, denke ich, davon ausgehen kann, dass die "Spring-Lastigkeit" der geäusserten Meinungen auch daran liegt, dass Spring sehr viel bekannter und verbreiteter, da älter ist.

Naja, EJB ist älter als Spring, aber nicht verbreiteter, das hat schon etwas mit der Qualität und Komplexität zu tun, JSF ist von Sun zum Standard für WebApps erkoren worden, aber nicht jeder hat Lust auf JSF, speziell die ersten Versionen waren sehr entäuschend für die meisten erfahren Entwickler, etwas das leider bei den JEE Standards immer wieder passiert, aber seitdem mehr erfolgreiche OS Projekte standartisiert werden ist das auch besser geworden.
Wenn Seam allerdings das versprechen einhält, das gnaze wirklich einfacher zu machen, dann gibt es wohl keine Gründe die dagegen sprechen wenn man sowieso schon den JBoss einsetzen wollte.

Sich mit Spring IoC (dem DI Modul, auch Core genannt) auseinanderzusetzen ist auf jedenfall nicht verkehrt, denn das DI Prinzip ist auch in EJB3.0 eingeflossen, allerdings wieder nicht so richtig "korrekt", das bessert EJB3.1 aus.

 

[JanHH]

Danke danke für die vielen Infos.