# Framework-Gewusel entwuseln.



## -MacNuke- (11. Nov 2008)

Hallo.

Sry, das ich keinen besseren Thread-Titel gefunden habe. Alle aussagekräftigeren wurden vom Spam-Schutz abgewiesen.

Nachdem ich ja schon mal gefragt habe was es mit der 3-Schichten-Architektur so auf sich hat, will ich mal etwas mehr ins Detail gehen, mit den Fragen.

Mir geht es im Prinzip nun darum zu entscheiden, was ich ausprobiere für eine Web-Anwendung und mir dort entsprechende Literatur besorge.

Ich bin erst mal soweit:

Erst mal gibt es ja die Datenbank, klar. Auf diese greife ich dann mit einem ORM-Framework wie Hibernate zu. Jetzt packt man noch was zur Verwaltung von Hibernate oben drauf:

Das wären einmal die Application-Server (z.B. Glassfish) die quasi EJB3(.1) implementieren und mir einen Webserver liefern ODER ich könnte auch Tomcat und Spring verwenden was im Prinzip das Gleiche ist, nur in Anders. 

So, OK. Ist es bis hierhin korrekt?

*Jetzt fragt sich natürlich nur, was es mit den ganzen "Glassfish+Spring" aufsich hat?!* Laut dem was ich bisher gelesen habe würde sich das doch ausschließen?


Für die Darstellung packt man jetzt noch ein Web-Framework oben drauf. Hier ist noch mein Problem. Da gibt's ja nun verschiedene und ein paar kann ich nicht einordnen.

Es gibt da ja z.B.

- SpringWeb
- Tapestry
- ZK
- GWT

Einige schreiben sich AJAX/DHTML/whatever groß auf die Stirn, andere eher so nebenbei. Mir geht's vor allem darum, dass sich für jede Eingabe nicht gleich das ganze Fenster erneuern muss, sondern nur der Teil der geändert wurde. Beispielsweise wenn ein Datensatz angefügt wurde, oder so. 

*Oder baut man auf diese Frameworks noch etwas oben drauf? Schließen sich  zum Beispiel Tapestry und eine JSF-Implementierung aus? Oder ZK und JSF?* Ist erst mal nur zum Verständnis. 

Jetzt noch nebenbei die Frage wo eigentlich JavaFX anzusiedeln ist. Ist das auch ein Webframework was man dann quasi auf den Server aufsetzt, oder ist das was anderes?

Puh, ich weiß gar nicht wie ich das wirre geflecht aus Abkürzungen in meinem Kopf ordnen soll 

Ich hoffe ihr könnt mir dabei vllt. etwas helfen?

Danke.


----------



## robertpic71 (11. Nov 2008)

-MacNuke- hat gesagt.:
			
		

> Das wären einmal die Application-Server (z.B. Glassfish) die quasi EJB3(.1) implementieren und mir einen Webserver liefern ODER ich könnte auch Tomcat und Spring verwenden was im Prinzip das Gleiche ist, nur in Anders.
> 
> So, OK. Ist es bis hierhin korrekt?


Jein....
Edit: Sorry hab übersehen, dass du vorher bereits Hibernate erwähnt hast.
Ja das ist korrekt. Dein "im Prinzip das Gleiche ist, nur in Anders" triffts.

Nicht umsonst wird Spring + Hibernate auch "J2EE light" genannt. Der Spruch kommt allerdings noch aus EJB 2.1 Zeiten. 



			
				-MacNuke- hat gesagt.:
			
		

> *Jetzt fragt sich natürlich nur, was es mit den ganzen "Glassfish+Spring" aufsich hat?!* Laut dem was ich bisher gelesen habe würde sich das doch ausschließen?


Wie gesagt, man könnte die Persitenzschicht (edit: die JPA-Implentierung) von Glassfisch nehmen. Außerdem: Spring hat viele Module, z.b. Security, WebServices, welche man zusätzlich benötigen könnte. Aber es gibt hier (Spring vs. Glassfish) sicher einige Leistungsüberschneidungen (Injection, Persitenzschichtsteuerung, Transactionsteuerung..). 

Außerdem kann man den Applicationserver auch wegen andere Gründe haben wollen (z.B. Clustering, das von Tomcat hat nicht so viele Möglichkeiten).



			
				-MacNuke- hat gesagt.:
			
		

> Für die Darstellung packt man jetzt noch ein Web-Framework oben drauf. Hier ist noch mein Problem. Da gibt's ja nun verschiedene und ein paar kann ich nicht einordnen.



Ganz grob unterscheide ich die Templatefraktion:
Tapestry 
Velocity
JSP (pure oder was auch immer z.B. JSF)

D.h. es gibt ein html-Dokument, welches durch Variablen oder zusätzliche Namespaces um dynamische Information angereichert werden. Je nach Framework gibt es auch Hilfestellung beim Validieren und Aktualisieren.
Bei JSF können nicht Daten, sondern ganze Komponenten eingebettet werden.

Ajaxerweiterungen für seitenbasierende Frameworks, werden meist auch über einen eigenen Namespace mit der html/JSP Seite verheiratet.

BTW: Spring Web Flow hat übrigens keinen eigenen Viewerteil und ist eher für die Zusammenhänge und Abhläufe hilfreich. 

Alle Ajax-Frameworks die ich kenne, arbeiten komponentenbasierend und verwenden für die GUI-Beschreibung kein HTML mehr als Basis. D.h. man baut die Webseite mit Java Objekten auf (vergleichbar mit Swing) oder mit einer
XML-GUI-Beschreibung.

GWT: Java (wird zu Javascript compiliert und läuft clientseitig)
ZK: Java oder XML-GUI-Beschreibung
Echo2: Java
RAP: Java 

Es gibt noch eine Reihe andere clientseiteiger AJAX-Frameworks. Aber wenn man sich Javascript vom Leib halten will, bleibt da nur GWT über. Man muss sich zwar auch dort mit der Synchronisation der Serverdaten herumschlagen, aber man tut das wengistens in Java und die Toolunterstützung (Spring) wächst.

Die serverseitigen Ajax-Frameworks halten (wie z.B. auch JSF) die Komponentenstruktor weitgehend 1:1 auch im Server. Hier werden keine Daten mit dem Browser synchronisiert, sondern GUI-Elemente. 
Damit arbeitet man weitgehend mit dem Programmiermodel aus dem Desktopbereich. Ich habe auch
direkten Zugriff auf alle Serverresourcen ohne irgendwelche RMI-Dienste dazwischen.



			
				-MacNuke- hat gesagt.:
			
		

> *Oder baut man auf diese Frameworks noch etwas oben drauf? Schließen sich  zum Beispiel Tapestry und eine JSF-Implementierung aus? Oder ZK und JSF?* Ist erst mal nur zum Verständnis.


Technisch gesehen kann man Tapestry und JSF in der selben Anwendung laufen lassen. Aber es sicht nicht besonders sinnvoll, 2 verschieden Validierungslösungen usw. zu haben.
Ähnlich verhält es sich auch JSF und ZK. Wobei man ZK (mit ZK for JSF) auch JSF-Anwendungen um Ajaxkomponenten (z.b. Combobox Autocomplete...) erweitern kann.



			
				-MacNuke- hat gesagt.:
			
		

> Jetzt noch nebenbei die Frage wo eigentlich JavaFX anzusiedeln ist. Ist das auch ein Webframework was man dann quasi auf den Server aufsetzt, oder ist das was anderes?


JavaFX soll eher ein Browser-Plugin werden/sein wie z.b. der Flashplayer. Ich würde das eher als
verbessertes Applet bzw. Adobe Flex Gegenspieler sehen.

/Robert


----------



## Gast (11. Nov 2008)

> Wie gesagt, dafür fehlt Spring noch die Persistenzschicht.


Wieso das denn?

JPA geht mit Spring genauso wie mit EJB3.


----------



## robertpic71 (11. Nov 2008)

Gast hat gesagt.:
			
		

> > Wie gesagt, dafür fehlt Spring noch die Persistenzschicht.
> 
> 
> Wieso das denn?
> ...



Ich habe den Satz erst nach dem Posten gesehen und sofort verbessert, du warst anscheinend schneller.
Spring hat zwar trotzdem keine eigene Persitenz-Engine, kann aber, wie du richtig sagst, natürlich auch EJB3 steuern.

/Robert


----------



## Gast (11. Nov 2008)

> Ich habe den Satz erst nach dem Posten gesehen und sofort verbessert, du warst anscheinend schneller. 
OK.

> Spring hat zwar trotzdem keine eigene Persitenz-Engine, kann aber wie, wie du richtig sagst, natürlich auch EJB3 steuern. 
Nicht einverstanden.

EJB != JPA

Spring kann genauso JPA verwenden wie EJB3s, kein UNterschied, einfach den EM nehmen, wird auch so empfohlen von Spring:


> NOTE: JpaTemplate mainly exists as a sibling of JdoTemplate and HibernateTemplate, offering the same style for people used to it. For newly started projects, consider adopting the standard JPA style of coding data access objects instead, based on a "shared EntityManager" reference injected via a Spring bean definition or the JPA PersistenceContext annotation


----------



## robertpic71 (11. Nov 2008)

Gast hat gesagt.:
			
		

> Spring kann genauso JPA verwenden wie EJB3s, kein UNterschied, einfach den EM nehmen, wird auch so empfohlen von Spring:


Außer einer nicht ganz richtigen Formulierung (die JPA-Implentierung ist nur ein Teil von EJB3) sehe ich keinen Fehler bei meiner letzten Aussage.

Meine Kernaussage war ja: Spring hat keine eigene Persitenzschicht, sondern verwaltet diese nur.

/Robert


----------



## byte (11. Nov 2008)

Ich würde nicht sagen, dass JPA ein Teil von EJB ist. Eine JPA Implementierung wie Hibernate hat schließlich nichts mit Enterprise Java Beans zu tun. Ich brauche keinen EJB-Container, um JPA zu benutzen.
Vielmehr ist doch sowohl JPA als auch EJB schlicht ein Teil von JEE. Genauso wie Serlvets und JSP ein Teil von JEE ist. Deswegen kann man Spring auch problemlos als JEE-Framework bezeichnen, auch wenn Spring häufig konträr zu EJBs gesehen wird. 
Denn: JEE != EJB


----------



## maki (11. Nov 2008)

> die JPA-Implentierung ist nur ein Teil von EJB3


JPA ist kein Teil von EJB3 (mehr), man hatte sich zu diesem Schritt entschieden, um sowohl unter JSE als auch im JEE Umfeld diesselbe Peristenzlösung möglich zu machen (one size fits all).

Die Tatsache das die JPA 1.0 Spek. noch teil der EJB3 Spek ist verleitet aber dazu,  die JPA als teil von EJB3 zu sehen, was aber nciht richtig ist.

JPA kann man komplett ohne JEE App. Server betreiben, ein JEE Server der JPA anbietet ist auch nicht besser in JPA als eine App. die weder Spring noch EJB3 nutzt, sondern nur JSE und JPA.

Kurz: JPA ist vollkommen unabhängig von EJB3 und JEE.

Es ist aber richtig, das in den vorläufigen Speks die JPA Teil von EJB3 und damit JEE war, hat man aber vor rausgabe der final Spek für EJB3.0 und JEE5 geändert.



> Meine Kernaussage war ja: Spring hat keine eigene Persitenzschicht, sondern verwaltet diese nur.


Richtig, aber genauso verwaltet ein JEE App Server die Peristenz nur, und stellt sice nicht selbst zur Verfügung 

Also sind Spring und EJB3 gleichwertig, was JPA und Persitenz betrifft.


----------



## ps (12. Nov 2008)

maki hat gesagt.:
			
		

> Kurz: JPA ist vollkommen unabhängig von EJB3 und JEE.



das ist richtig. aber andersrum nicht: EJB3 ist nicht unabhängig von JPA.



> Also sind Spring und EJB3 gleichwertig, was JPA und Persitenz betrifft.



auch nicht ganz richtig. die integration von JPA in EJB geht viel weiter als das bei Spring der Fall ist.


----------



## robertpic71 (12. Nov 2008)

Das war ja zu befürchten: Ein vereinfachter (Versuch) einer Übersicht ruft sofort jede Menge "Haarspaltereien" auf den Plan.

Wobei es ein Streit um des "Kaisers Bart" ist ob EJB die Persistenzschicht nur verwaltet oder mitbringt. 



> Kurz: JPA ist vollkommen unabhängig von EJB3 und JEE.
> ..
> Richtig, aber genauso verwaltet ein JEE App Server die Peristenz nur, und stellt sice nicht selbst zur Verfügung



*Praktisch* ist es aber so, dass jeder, mir bekannten, (Sun-Spez.)JEE-Applikationsserver auch eine JPA-*Implementierung *(Persistenzschicht) mitbringt. 

Daher bleibe ich bei meiner Behauptung:


> Spring hat keine eigene Persitenzschicht, sondern verwaltet diese nur.



Auch wenn JPA nicht mehr Teil EJB3 ist, so es zwingend dafür erforderlich. Praktisch bekomme ich (vom Server) kein EJB3 ohne JPA-Implentierung geliefert. Bei Spring muss/kann ich mir die Persitenzschicht dazuholen.

/Robert


----------



## byte (12. Nov 2008)

JEE-ApplicationServer werden mit *einer* JPA-Implementierung ausgeliefert (GlassFish z.B. mit TopLink), das Spring-Framework unterstützt hingegen *alle* JPA-Implementierungen und liefert verschiedene Utility-Klassen dafür mit. 
Im übrigen sind bei Spring auch direkt die Hibernate und TopLink Jars mit dabei. Im Gegensatz zu EJB-Containern wird Dir aber nicht aufgezwungen, was Du zu benutzen hast und was nicht. Spring ist wie ein großer Baukasten, an dem sich der Entwickler beliebig bedienen kann.


----------



## -MacNuke- (12. Nov 2008)

Gut, ich habe auch nicht wirklich erwartet, dass der Thread mir bei der Entscheidung "EJB oder Spring" hilft. 

Bei den Webframeworks ist mir jetzt noch eines eingefallen:

Ich habe in fast allen Beispielen gesehen, dass zum Ändern von Datensätzen immer gleich ganz neue Seiten aufgemacht werden. Ich habe aber auch JavaScript-Beispiele gefunden, wo es editierbare Tabellen gibt.

In den Beispielanwendungen zu den einzelnen Frameworks ist sowas nicht dabei bzw. wird nicht gezeigt. Können die sowas überhaupt?


----------



## HLX (12. Nov 2008)

Für GWT gibt es eine Bibliothek "Ext GWT". Die hat mittlerweile auch editierbare Tabellen.

extjs.com/products/gxt/


----------



## robertpic71 (12. Nov 2008)

-MacNuke- hat gesagt.:
			
		

> Gut, ich habe auch nicht wirklich erwartet, dass der Thread mir bei der Entscheidung "EJB oder Spring" hilft.


Ja, bei diesem Thema geht es immer heiß her..



			
				-MacNuke- hat gesagt.:
			
		

> In den Beispielanwendungen zu den einzelnen Frameworks ist sowas nicht dabei bzw. wird nicht gezeigt. Können die sowas überhaupt?


Da müsste ich schon das Framework wissen um das zu kommentieren. Möglicherweise sind die Beispiele (bei den Ajaxzusätzen/Frameworks) nur vereinfacht.

Hier Beispiele von ZK.
In der Version 2 wird die Tabelle ganze aktualisiert (durch das binder.loadAll() werden alle databindings neu gelesen). In der Version 3 wird nur der neue Satz zum GUI-Model (funktioniert ähnlich Swing) hinzugefügt, damit wird automatisch nur der eine Satz im Browser aktualisiert.

Auch das ist natürlich ein einfaches Beispiel. Normalerweise läßt man sich den Controller oder zumindest den DAO/Manager-Klasse "injecten" (im Fall von ZK arbeiten die meisten mit Spring).

Editierbare Tabellen hat man bei ZK mit Grids. Da das Databinding mit den echten Domainklassen verbunden ist, bräuchte man bei eingeschaltetem "Dirty Checking" und "Open Session in View" einfach nur die Gridtabelle
mit laden und jede Änderung landet sofort in der Datenbank - und fertig.


/Robert


----------



## Gast (12. Nov 2008)

> Ja, bei diesem Thema geht es immer heiß her..


Speziell wenn Leute falsche Infos verbreiten und darauf beharren.


----------



## robertpic71 (13. Nov 2008)

Gast hat gesagt.:
			
		

> > Ja, bei diesem Thema geht es immer heiß her..
> 
> 
> Speziell wenn Leute falsche Infos verbreiten und darauf beharren.



Ein letztes Mal noch:
Man bekommt von den Servern keine EJB3-Implementierung ohne JPA-Implementierung geliefert. Also wenn man (wie in diesem Thread) von Applikationsservern spricht, kann man die beiden nicht als gänzlich unabhängig zueinander hinstellen.

Im Spring Corepaket ist erstmal keine Persitenzengine dabei. Gleich mehrere sind dafür bei den Spring Dependencies drinnen. Für mein Projekt muss ich mir trotzdem die Perstinezschicht meiner Wahl dazuholen (aus den Dependencies oder woher auch immer).   

/Robert

PS Und keine Sorge: Das Forum wird nicht mehr viel von mir hören.


----------



## ps (13. Nov 2008)

robertpic71 hat gesagt.:
			
		

> PS Und keine Sorge: Das Forum wird nicht mehr viel von mir hören.



Lass dich nicht ärgern. Die Leute hier sind ein bisschen Spring-biased, frag mich nicht warum. Umso mehr unterschiedliche Meinungen vertreten sind, umso qualitativer werden die Threads -- meist gibt es halt doch nicht nur Schwarz und Weiss, die Grautöne ergeben sich erst wenn man sich seine eigene Meinung bildet


----------



## byte (13. Nov 2008)

robertpic71 hat gesagt.:
			
		

> Man bekommt von den Servern keine EJB3-Implementierung ohne JPA-Implementierung geliefert. Also wenn man (wie in diesem Thread) von Applikationsservern spricht, kann man die beiden nicht als gänzlich unabhängig zueinander hinstellen.


Wenns danach geht, bekommst Du auch keinen AppServer ohne JAXB-Implementierung. Ist JAXB deswegen gleich fester Bestandteil von EJB? Ich glaube nicht.

Im Grunde ist JEE nichts anderes als eine Vielzahl von Spezifikationen, für die ein JEE AppServer Implementierungen liefern muss: http://java.sun.com/javaee/technologies/
Mit JEE 6 wird sich dieses starre Gerüst ja etwas lockern durch die Einführung der JEE Profile.


----------



## ps (13. Nov 2008)

byto hat gesagt.:
			
		

> Wenns danach geht, bekommst Du auch keinen AppServer ohne JAXB-Implementierung. Ist JAXB deswegen gleich fester Bestandteil von EJB? Ich glaube nicht.



Ist es nicht. Aber du übersiehst hierbei doch einen wesentlichen Punkt: EJB3(.1) ohne JPA ist nicht möglich. Das heisst die EJB Spezifikation erfordert zwingend das Vorhandensein von JPA. Das ist zwangsläufig so, da sonst ein Großteil der EJB Spezifikation nicht sinnvoll wäre (JPA Injections, Transaktionssteuerung, etc).

JAXB hingegen ist eine völlig eigenständige Spezifikation. Dein Vergleich hinkt also doch ein wenig


----------



## byte (13. Nov 2008)

Ich stimme Dir voll und ganz zu ps. Aber es stand ja ursprünglich genau die andere Richtung zur Diskussion. JPA ist nicht abhängig von EJB, sondern ist für sich eine eigenständige Spezifikation. Das wollte ich mit dem Beispiel JAXB veranschaulichen.


----------



## ps (13. Nov 2008)

und ich dachte schon es ginge wieder um unser lieblingsthema: Spring vs. EJB3 ;-)


----------



## byte (13. Nov 2008)

Eigentlich nicht, auch wenn Du genau deswegen hier zu sein scheinst. :bae:


----------



## robertpic71 (13. Nov 2008)

byto hat gesagt.:
			
		

> Ich stimme Dir voll und ganz zu ps. Aber es stand ja ursprünglich genau die andere Richtung zur Diskussion. JPA ist nicht abhängig von EJB, sondern ist für sich eine eigenständige Spezifikation. Das wollte ich mit dem Beispiel JAXB veranschaulichen.



Kannst du mir die Spezifikation auch nennen?

Ich kenne nur JSR 220: Enterprise JavaBeansTM 3.0 Status: *final*
und JSR 317: JavaTM Persistence 2.0 Status: *In Progress*.

Ich kann natürlich nicht ausschließen, dass mir etwas entgangen ist, aber ich saug mir das ja auch nicht aus den Fingern - ich habe sogar noch das Magazin (Print + Link) gefunden:


			
				Java Magazin hat gesagt.:
			
		

> Die Java Persistence API (JPA) ist als Teil von EJB 3.0 für die Persistierung im Framework zuständig.



Siehe auch den grauen Kasten (erste Seite) im Artikel.

Nachtrag: 
Im JEE-Link gibt es zwar 2 Zeilen (1xEJB,1xJPA) aber beide verweisen auf diese selbe Spezifikation.

/Robert


----------



## byte (13. Nov 2008)

Sun hat gesagt.:
			
		

> The Java Persistence API was developed by the EJB 3.0 software expert group as part of JSR 220, *but its use is not limited to EJB software components*. It can also be used directly by web applications and application clients, and even outside the Java EE platform, for example, in Java SE applications.


----------



## robertpic71 (13. Nov 2008)

byto hat gesagt.:
			
		

> ... JPA ist nicht abhängig von EJB, sondern ist für sich eine eigenständige Spezifikation.





			
				Sun hat gesagt.:
			
		

> The Java Persistence API was developed by the EJB 3.0 software expert group as *part of JSR 220*, but its use is not limited to EJB software components. It can also be used directly by web applications and application clients, and even outside the Java EE platform, for example, in Java SE applications.



Auch wenn sich eine JPA-Implentierung ohne EJB betreiben läßt: JPA hat (noch) keine eigenständige Spezifikation. Im PDF (JPA 1.0) titelt auch noch Überschrift "JSR 220: *E*nterprise *J*ava*B*eansTM 3.0".

Also zumindest EJB3 ist von JPA abhängig und die beiden sind in der gleichen Spezifikation. Richtig falsch wird der Satz "JPA ist ein Teil von EJB3" erst wenn JPA 2.0 final ist. Bis dahin kann man der Formulierung nur ankreiden, dass sie suggieriert, für JPA auch EJB zu benötigen (was ich aber eh nicht bebauptet habe).   

/Robert


----------



## byte (14. Nov 2008)

Meine Güte, jetzt gehts aber vom Hundersten ins Tausendste. :roll:

Mit JPA-Spezifikation meine ich die persistence.jar, also die JPA-Interfaces und nicht den JSR. Die persistence.jar hat mit EJB nix am Hut. Dass JPA aus EJB heraus entstanden ist, haben wir ja schon auf Seite 1 festgestellt. 

Aber da es Dir offenbar so wichtig ist: Du hast Recht... und ich meine Ruhe. :bae:


----------



## -MacNuke- (14. Nov 2008)

Mal so eine Frage nebenbei von jemandem, der da noch nicht so drinnen steckt...

... bringt euch die Antwort auf die Frage, um die ihr euch hier so kloppt, eigentlich in irgend einer Weise weiter? Oder würde die Antwort "42" zum gleichen Ergebnis führen?


----------



## robertpic71 (14. Nov 2008)

-MacNuke- hat gesagt.:
			
		

> ... bringt euch die Antwort auf die Frage, um die ihr euch hier so kloppt, eigentlich in irgend einer Weise weiter?


Nein, nicht wirklich.  Die Funktionsweise der einzelnen "Streitpunkte" (EJB, JPA, JEE-Server, Spring) ist wohl allen Beteiligten klar. Die Diskussion ging eigentlich nur um die Formulierung der Zugehörigkeiten bzw. Abhängigkeiten. 

Dafür ist mein Wissen um die Spezfikationen jetzt wieder geschärft. :idea: Meine erste Formulierung (EJB3 mit JPA gleichzusetzen) war aber definitiv falsch. 



			
				-MacNuke- hat gesagt.:
			
		

> Oder würde die Antwort "42" zum gleichen Ergebnis führen?


"42" ist auch keine Lösung.  

/Robert


----------



## ps (14. Nov 2008)

-MacNuke- hat gesagt.:
			
		

> Oder würde die Antwort "42" zum gleichen Ergebnis führen?



Wenn du mir die Frage verrätst? ;-)


----------



## byte (14. Nov 2008)

Eigentlich haben wir uns alle lieb, wir verraten es nur niemandem. 

PS: 23 > 42


----------



## ARadauer (14. Nov 2008)

allgemein eine frage zum thema, wenn ich jetzt spring für meinen server einsetze, die kommunikations über rmi läuft brauch ich ja eigentlich keine tomkatze oder j2ee server, die serverapplikation wär dann einfach eine java anwendung die auf den rmi port hört und bei bedarf meine anfragen abarbeitet oder?


----------



## maki (14. Nov 2008)

Ja.

Wehe es fragt einer nach Spring vs EBJ3 mit und ohne JPA... *g*


----------



## byte (14. Nov 2008)

Jo, bei Spring Remoting mit RMI brauchst Du gar keinen JEE Container. Erst wenn Du z.B. HTTP Invoker benutzt, brauchst Du einen Servlet-Container wie den Tomcat oder jeden beliebigen JEE AppServer.


----------



## ps (17. Nov 2008)

Boaaaaaaaah. Hammer 
Mein Webframework der Wahl ist bisher ja immer Struts2 gewesen (und es wird wohl noch ewig Toolbox sein).

Dieses Wochenende hatte ich mir aber vorgenommen mich mal umzusehen und auszuprobieren (ja, ich hab sogar mal eine Webapp ohne EJB3 gebaut.. aber das ist der andere thread ^^). Jedenfalls war zuerst Wicket dran. Gefällt mir gut, erinnert mich ein bisschen an Seaside. Zumindest von der Art und Weise wie man seine Anwendungen zusammenbaut. Störfaktor: Sehr viel code. Wird finde ich sehr schnell unübersichtlich... aber vielleicht gibt sich das wenn man mit der Zeit seine generischen Komponenten gebaut hat. Auf jeden Fall macht es Spaß es zu benutzen  Eindrucksmäßig aber eher für kleinere Projekte.

Nun.. danach musste ich mir Tapestry 5 auch noch anschauen.. Und oha! Wieso habe ich das nicht schon viel früher gemacht?! Geniales Framework, ausführliche, sehr detaillierte doku auch der Interna. Die Codebase scheint sehr solide und qualitativ hochwertig zu sein.. und man kommt fast noch schneller zu Ergebnissen als mit Wicket... mal sehen ob die Begeisterung anhält


----------



## byte (17. Nov 2008)

Tapestry 5 ist ja noch Beta. Läuft es schon soweit stabil oder gibts noch viele Baustellen? Weisst Du, wann Version 5 produktiv gehn soll?


----------



## ps (17. Nov 2008)

byto hat gesagt.:
			
		

> Tapestry 5 ist ja noch Beta. Läuft es schon soweit stabil oder gibts noch viele Baustellen? Weisst Du, wann Version 5 produktiv gehn soll?



Gestern hat 5.0.16 das Voting als Release Candidate bestanden. Sieht alles sehr stabil aus, Baustellen habe ich keine entdecken können.


----------

