Framework-Gewusel entwuseln.

[-MacNuke-]

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]

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.

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).

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.

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.

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]

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

Wieso das denn?

JPA geht mit Spring genauso wie mit EJB3.

 

[robertpic71]

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

Wieso das denn?

JPA geht mit Spring genauso wie mit EJB3.

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]

> 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]

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]

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]

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]

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]

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]

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-]

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]

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

extjs.com/products/gxt/

 

[robertpic71]

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..

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]

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

Speziell wenn Leute falsche Infos verbreiten und darauf beharren.

 

[robertpic71]

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]

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]

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]

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]

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]

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

 

[byte]

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

 

[robertpic71]

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:

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]

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]

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

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: Enterprise JavaBeansTM 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]

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-]

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]

... 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.

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

"42" ist auch keine Lösung.

/Robert

 

[ps]

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

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

 

[byte]

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

PS: 23 > 42

 

[ARadauer]

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]

Ja.

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

 

[byte]

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]

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]

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]

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.