Glassfish broken

#1

Hi,

benutze jetzt seit ca. 4 Jahren den Glassfish für alles und war durchaus immer zufrieden damit - bis diese Woche. Habe nach langer Zeit mal wieder eine neue JDBC Resource anlegen wollen, und bin auf einen Fehler gestoßen den ich auch im Issuetracker und auf Stackoverflow wieder finden konnte: mysql - Glassfish Admin Console throws java.lang.IllegalStateException when creating JDBC Pool - Stack Overflow

Es ist seit mehreren Monaten nicht mehr möglich, eine JDBC Resource im WebAdmin anzulegen, und Oracle kümmert es wohl überhaupt nicht. Es ist klar, dass Oracle keinen Support mehr dafür anbietet, aber das muss ja nicht bedeuten, dass man ein kaputtes Produkt ausrollt und es dann so lässt :confused: Natürlich kann man die Configfiles immer noch manuell anpassen, aber nach der Nummer traue ich mich ehrlich gesagt nicht mal mehr im Hobbybereich etwas mit Glassfish zu hosten. Als Alternative gibt es ja mittlerweile den Paraya (da ist der Bug schon gefixt), aber so wirklich wohl ist mir auch nicht, wenn da ein Drittanbieter den Support macht, dafür ist mir Oracle zu unberechenbar.

Ab jetzt also weiter mit Wildfly, mal sehen was der so kann.

Viele Grüße,
Tim

#2

Hi! :slight_smile:

Mal so in den Raum werf, warum nicht einfach Jetty oder Tomcat embedden? :wink:

Anscheinend kannst du ja einfach so mal von Glassfish auf Wildfly wechseln, da waere das mal einen Versuch wert :wink:

IME skalieren embedded ServletContainer besser, sind produktiv einfacher in der Wartung und ausrollen ist viel einfacher :slight_smile:
Eine Jar die verteilt wird, ein (Java-) Prozess der gestartet/abgeschossen wird, entwickeln & debuggen sind IME auch einfacher, kein extra deployment Schritt usw. usf.

Klar, dagegen spricht dass der JEE Standard nicht eingehalten wird, aber oft wird sowieso nur eine Anwendung pro Server benoetigt/deployed, die Admin Konsole/Tomcat Manager/etc. braucht man auch nicht mehr wenn man nur eine Anwendung ohne externen Server hat, EARs/WebApps deployen/updaten etc. ist nicht gerade angenehm, JDBC ConnectionPools kann man auch anders konfigurieren .

99% der Features die einem ein vollausgewachsener JEE Server bietet bekommt man auch so, ohne den ganzen Rattenschwanz an Komplexität, Spring sei dank :slight_smile: (wer nutzt eigentlich XA Transaktionen?)

“Weil einfach einfach einfach ist” war mal so ein Werbespruch oder so…

#3

Hmm nuja, ich glaube EJB inkl. Message Driven Beans auf Spring zu portieren dürfte ein ziemliches Experiment werden :smiley: Ich muss gestehen, ich bin im Lager der JEE Jünger unterwegs, fühle mich da einfach wohler. Beruflich habe ich viel mit Spring zu tun, weil 90% unserer Kunden darauf setzen, da sehe ich schon, dass das alles gut klappt. Aber EJB hat auch so seine Vorzüge… Sind gerade dabei eine Eigenentwicklung zu starten, die ersten Architekturrunden haben auch einstimmig zu JEE mit EJB tendiert, allerdings hier schon mit dem Wildfly im Auge.

Ich habe zur Zeit leider noch eine relativ große Anwendung, die für einen Bekannten geschrieben ist und bei ihm produktiv läuft, da werde ich wohl wirklich auf den Payara wechseln müssen, alles andere ist mir da zu gefährlich. Wie ärgerlich…

#4

Naja, wenn man so auf eine Implementierung schielt dann schon, ansonsten ist das doch nur Asynchrone Verarbeitung, also MessageQueues eben.

Die ganzen JEE Server sind IME spaetestens in der Produktion “a pain in the ass”, eigentlich schon in der Entwicklung, bin da aber auch voreingenommen :wink:

#5

Ich gebe dir da schon recht, teilweise sind das schon Konfigurationshöllen, das sieht man alleine daran, dass es in größeren Unternehmen ganze Websphere Abteilungen gibt die nichts anderes tun als die Server zu betreuen. Mein Favorit war ein Kunde, der Spring Anwendungen prinzipiell auf Websphere deployed, das spielt genau so gut zusammen wie man denkt! (Aber langsam OT :wink: )

#6

was ist denn mit der antwort auf stackoverflow:

“Just noticed that there is a Glassfish version that has been patched, it is called Payara and available for download here. According to the documentation, it is a GlassFish 4.1 clone, patched and further developed by the community.”

#7

Das ist schon länger nicht mehr so. SpringBoot ist in der Komplexität ähnlich und auch hier muss man die Konfigurationsmöglichkeiten kennen. Ob ich eine jar starte oder ein Shell-Skript sollte doch in der Produktion unerheblich sein. Ein EE-Container bringt allerdings mehr Laufzeitkonfiguration, wie ich finde. Die Shell im Wildfly ist traumhaft. Graceful shutdown ist ein tolles Feature. Und skalierbar ist ein Wildfly auf jeden Fall.

Aber vielleicht bin ich da einfach voreingenommen. :smiley:

#8

Noch mal ein Update: Bin jetzt für meinen bekannten auf den Payara gewechselt, der läuft gut, hat den Bug schon gefixt und bekommt vierteljährliche Updates. Kann jedem die Migration empfehlen.

… aber in Zukunft wird es trotzdem der Wildfly :stuck_out_tongue:

#9

Das muss man so oder so :wink:
Springboot ist eine, aber nicht die einzige Moeglichkeit einen Sever zu embedded.

Ist es auch, aber wenn das Shell Script erst einen Jar Deploy ausfuehren muss auf einem JEE Server/ServletContainer, dann ist es ein Unterschied, naemlich eine SW die zus. gewartet werden muss, man muss sehen ob die Versionen etc. zusammen passen usw. usf.

Wenn man in Test oder Prod mal die Anwendung auf 400 Maschinen installieren will, macht es einen riesigen Unterschied IME.

Eben, oft Dinge die man gar nicht braucht… oder aber Dinge, welche die Anwendung selber auch noch mal zus. macht (JDBC ConnectionPooling zB.)

Mit embedded Servern spart man sich die externen die oft enormen zus. Aufwand brauchen, externe Server machen sie die Anwendung auch nicht schneller, speziell beim deployment, es ist viel einfacher per Puppet/Chef/Ansible einen Process zu killen und einen neuen zu launchen (Shellscript oder Jar starten) als ein Deployment durchzufuehren (inkl. Fehlermoeglichkeiten, zB. Fehlkonfiguration, Timeouts etc. pp.).

Nur so skalierbar wie die Anwendung selber, minus den Einschraenkungen/Ressourcen die ein JEE Server auch nochmals mitbringt/braucht.

Fuer mich sich JEE Server ein Relikt aus den Zeiten als man dachte “mehr als eine Anwendung pro JEE Server klingt toll”, das war einfach so weil JEE Server viel Geld gekostet haben, nun da es nicht immer so ist wie bei den OSS Servern, haben die IMHO keine grossen Vorteile mehr, da ueberwiegen die Nachteile bzw. die zus. Komplexitaet bringt einem kaum etwas.

Wenn ich Entwickler frage “Wozu eigentlich einen ServletContainer/JEE Server” kommt oft nur “Isso in JEE”, dem ist aber nicht wirklich so, ist oft nur Konditionierung :wink:

Dass man funktionierende SW auf viele Arten entwickeln/bauen/deployen kann steht ausser Frage, es ist aber auf keinen Fall einfacher noch eine zus. SW (den Server selber) zu warten.
Embedded Server werden schon sehr lange genutzt (Jahre bevor Spring Boot kam), speziell in hoch skalierbaren Umfeldern.

#10

Vielleicht sollte man die Diskussion abspalten.

Das muss man ohnehin. Betriebssystem, Java Version, eventuelle Datenbankconnections, DNS… Ich hätte noch kein Unternehmen gesehen, das einfach mal auf verschiedenen Umgebungen wild Applicationserver in unterschiedlichen Versionen installiert.

Ich wüsste nicht, wieso eine JEE Applikation sich selbst um Connectionpooling kümmern sollte? Des weiteren starten bei modernen Servern (Wildfly, Liberty) auch nur die benutzten Module mit, was die ganze Geschichte wesentlich leichtgewichtiger macht.

Dass Deployment auf Applicationservern nicht unbedingt die schnellste Sache ist, da sind wir uns sicher einig. Aber wie bringe ich laufende Tasks sicher zu Ende, wenn ich einen Prozess kille? Lang laufende Operationen, z.B.?

Dass man als Entwickler Mist bauen kann ist klar, sehe ich aber nicht als Argument gegen Applicationserver. Da kann ich genau so gut als Argument bringen, dass die Spring Config Files von Entwicklern manipuliert werden können um sich das Leben einfacher zu machen.

Vielen Dank, dass du mein Urteilsvermögen infrage stellst :wink:

Kann es sein, dass wir einfach von unterschiedlichen Anwendungsfällen sprechen? Wenn es auf das letzte Quentchen Performance ankommt und ich meine Hardware bis zum letzten effizient nutzen möchte, dann würde ich dir Recht geben und sagen dass ein Applicationserver vielleicht nicht unbedingt die beste Wahl ist. Niemand würde auch auf die Idee kommen, eine Webanwendung für 50 Personen auf einem Weblogic zu hosten, auf der anderen Seite dürfte das genau die richtige Umgebung für eine Applikation sein, die von einer zweistelligen Entwickleranzahl erstellt wird, bei mehreren tausenden gleichzeitigen Benutzern die ordentlich Requests liefern und mit einem Kunden, der bei einer höheren Last einfach noch einen Server in den Pool schmeißen will. Natürlich geht das auch alles mit Spring Anwendungen die ihre Runtime mitliefern, aber Fakt ist, dass mir da z.B. das Clustering wesentlich schwerer fällt, alleine z.B. das Sessionhandling. Und natürlich wird der Applicationserver hier einen leichten Overhead mitbringen, der aber vom Kunden meistens aus Gründen der Wartbarkeit akzeptiert wird.

#11

Das meiste hat ja inv_zim bereits geschrieben, trotzdem möchte ich auf ein paar Punkte eingehen.

[QUOTE=maki]Das muss man so oder so :wink:
Springboot ist eine, aber nicht die einzige Moeglichkeit einen Sever zu embedded.[/QUOTE]
Ja, aber das ist ja nicht ein Grund dafür, einen Server zu embedden. Man muss beide Möglichkeiten zur Konfiguration kennen.

[QUOTE=maki;127666]
Ist es auch, aber wenn das Shell Script erst einen Jar Deploy ausfuehren muss auf einem JEE Server/ServletContainer, dann ist es ein Unterschied, naemlich eine SW die zus. gewartet werden muss, man muss sehen ob die Versionen etc. zusammen passen usw. usf.

Wenn man in Test oder Prod mal die Anwendung auf 400 Maschinen installieren will, macht es einen riesigen Unterschied IME.[/QUOTE]
Wie inv_zim bereits schrieb muss sowieso alles andere wie Java-Version, Betriebssystem und ähnliches passen. Es gehört meist mehr dazu ein Softwareupdate durchzuführen. Das fängt schon beim graceful-shutdown an. Ob ich nun im Skript ein Artefakt kopiere und den Server starte oder nur ein jar ausführe ist vom Aufwand her zu vernachlässigen. Das ist jedenfalls meine Erfahrung damit.

[QUOTE=maki;127666]
Eben, oft Dinge die man gar nicht braucht… oder aber Dinge, welche die Anwendung selber auch noch mal zus. macht (JDBC ConnectionPooling zB.)[/QUOTE]
Bei aktuellen JEE-Servern muss ich überhaupt nichts machen. Um das Pooling muss ich mich nicht kümmern (in der Regel), allerdings kann ich dies, ohne den Server oder die Applikation neu starten zu müssen. Das ist sehr wohl ein Vorteil, wie ich finde.

[QUOTE=maki;127666]
Mit embedded Servern spart man sich die externen die oft enormen zus. Aufwand brauchen, externe Server machen sie die Anwendung auch nicht schneller, speziell beim deployment, es ist viel einfacher per Puppet/Chef/Ansible einen Process zu killen und einen neuen zu launchen (Shellscript oder Jar starten) als ein Deployment durchzufuehren (inkl. Fehlermoeglichkeiten, zB. Fehlkonfiguration, Timeouts etc. pp.).[/QUOTE]
Einfach einen Prozess killen ist bei allen Anwendungen mit Queues nicht möglich. Und ob ein Server nun embedded oder direkt läuft ist doch vom Aufwand egal. Und auch das Deployment kann via Tools automatisiert werden. Eine Konfiguration muss bei beiden Varianten gepflegt werden. Und nur weil es embedded läuft, wird die Anwendung nicht schneller.

Im Übrigen gibt es beim JBoss Wildfly die Möglichkeit, mehrere Server als Master-Slave zu verbinden. Hier wird dann das Deployment über den Host an die anderen Server automatisiert nach und nach verteilt. Bei optimaler Konfiguration muss ich beim Deployment dann kaum mehr etwas selbst tun.

[QUOTE=maki;127666]
Nur so skalierbar wie die Anwendung selber, minus den Einschraenkungen/Ressourcen die ein JEE Server auch nochmals mitbringt/braucht.[/QUOTE]
Das spricht doch für alle Varianten. Ich kann auch Jar-Apps so entwickeln, dass eine Skalierung nicht möglich ist. Und moderne AppServer bringen zumindest Möglichkeiten mit.

[QUOTE=maki;127666]
Fuer mich sich JEE Server ein Relikt aus den Zeiten als man dachte “mehr als eine Anwendung pro JEE Server klingt toll”, das war einfach so weil JEE Server viel Geld gekostet haben, nun da es nicht immer so ist wie bei den OSS Servern, haben die IMHO keine grossen Vorteile mehr, da ueberwiegen die Nachteile bzw. die zus. Komplexitaet bringt einem kaum etwas.[/QUOTE]
Ich sehe das eher so, dass man nicht jedem Hype hinterher laufen muss. Ich sehe keine großen Nachteile beim Nutzen eines leichtgewichtigen AppServers. Ich sehe aber auch keine Nachteile beim Nutzen von SpringBoot oder ähnlichem. Mit beidem können die meisten Anforderungen erfolgreich gemeistert werden. Was man einsetzt, hängt dann sicherlich vom Können (oder Interesse) der Entwickler und von den Anforderungen ab.

[QUOTE=maki;127666]
Wenn ich Entwickler frage “Wozu eigentlich einen ServletContainer/JEE Server” kommt oft nur “Isso in JEE”, dem ist aber nicht wirklich so, ist oft nur Konditionierung ;)[/QUOTE]
Mit Entwicklern, die auf so eine Frage so uninteressiert antworten, würde ich mich über so ein Thema überhaupt nicht unterhalten wollen. :slight_smile:

[QUOTE=maki;127666]
Dass man funktionierende SW auf viele Arten entwickeln/bauen/deployen kann steht ausser Frage, es ist aber auf keinen Fall einfacher noch eine zus. SW (den Server selber) zu warten.
Embedded Server werden schon sehr lange genutzt (Jahre bevor Spring Boot kam), speziell in hoch skalierbaren Umfeldern.[/QUOTE]
Ich möchte nicht abstreiten, dass es das vor SpringBoot gab. Allerdings gab es da nur wenig standardisierte Möglichkeiten neben den AppServern. Natürlich dreht sich die Welt weiter und ich sage nicht, dass nur AppServer die Wahrheit sind. Im Grunde wurde auch in diesem Bereich gelernt, deshalb sind auch die AppServer nun (wesentlich) leichter zu pflegen und man spricht auch hier von leichtgewichtig.