Nach der Übernahme von Sun Microsystems durch Oracle steht die Frage im Raum wie es denn nun mit Java eigentlich weitergeht?
Einerseits ist Oracle eine große Firma mit riesigen Ressourcen zur Verbesserung des Java Ökosystems. Außerdem besitzt Oracle nun einen kompletten Stack von der Server Hardware, über das Betriebssystem (Solaris), Datenbank, Middle-Ware bis hin zu Unternehmenssoftware (E-Business-Suite). Dies kann ein großer Vorteil für Oracle Kunden werden, da die Produktpalette perfekt aufeinander abgestimmt werden kann. Hier kann Java als Basis-Technologie dienen und dadurch an Bedeutung gewinnen.
Andererseits besteht die Gefahr, dass sich Oracle vom Open-Source-Gedanken, der seit jeher eine Kernidee von Java ist und hervorragende Technologien hervorbrachte (wie z. Beispiel die Projekte von apache.org oder hibernate.org) verabschiedet. Mein Eindruck ist, dass Oracle nicht so Community freundlich sein wird, wie Sun:
Google sieht in Oracle Klage Angriff auf Open Source Java
Java unter Oracle ein Worst-Case-Szenario
Man darf also gespannt sein, wann sich Oracle endlich zu seiner Java-Strategie äußert und wie diese dann aussieht. Eines dürfte aber schon jetzt klar sein: Oracle wird seine Entscheidungen ganz nüchtern nach wirtschaftlichen Zielen ausrichten und nicht danach, was die Open-Source Gemeinde als ideologisch angebracht empfindet.
On this blog I am collecting information that might hopefully be useful to other java developers. My profile can be found on my website. Please feel free to comment and discuss any topic if you like.
Dieses Blog durchsuchen
Samstag, 28. August 2010
JBoss und Hot-Deployment
Immer wieder gibt es ja Probleme mit dem Hot-Deployment "Feature" vom JBoss AS. In vorherigen Versionen traten in diesem Zusammenhang häufig Speicherprobleme auf. So wurde beispielsweise bei jedem Hot-Deployment einer Anwendung mehr Speicher allokiert, so dass irgendwann ein Neustart unerlässlich wurde.
Nun dachte ich, dass diese Probleme mit der aktuellen (produktiven) Version 5.1 nun endlich einmal behoben sein könnten. Zunächst funktionierte das Prozedere auch ohne Probleme. Eine schlanke Web-Anwendung konnte in das Deploy-Verzeichnis des JBoss kopiert werden und schon waren die Änderungen im Programmcode verfügbar.
Aber die Freude währte nicht lange. Nachdem einige Bibliotheken hinzukamen und das Projekt wuchs, trat folgendes Phänomen auf: Nachdem das war-Archiv ins Deploy Verzeichnis kopiert wurde, wurde prompt ein "undeploy" der Anwendung durchgeführt. Anschließend passierte aber leider gar nichts mehr. Es war jedoch zu beobachten, dass der Java-Prozess des JBoss immer mehr Arbeitsspeicher allokierte, und zwar bis zu der mit -Xmx eingestellten Höchstgrenze von einem Gigabyte. Dann brach der Prozess anscheinend ab und der Speicher wurde wieder freigegeben. Der Vorgang begann dann wieder von vorne.
Nach einigem Probieren war dann die Lösung klar: Der JBoss hat anscheinend Probleme damit, ein Hot-Deployment mit war Archiven durchzuführen. Sobald das war Archiv wiederum in ein ear-File gepackt wurde, funktionierte es ohne jegliche Probleme. Leider hat mich die Lösung dann doch einige Zeit gekostet, von nun an werde ich wohl nicht mehr probieren, ein schlankes war-Archiv im JBoss zu verwenden.
Noch ein Tipp: Bitte für den JBoss 5.1.0 Facelets in der Version 1.1.14 verwenden. Denn bei Version 1.1.13 wurden die Facelet-Seiten schlichtweg ignoriert, sodass keinerlei Facelet-Tags interpretiert wurden. Das traurige dabei: Facelets 1.1.13 wird standardmäßig mit dem JBoss ausgeliefert.
Nun dachte ich, dass diese Probleme mit der aktuellen (produktiven) Version 5.1 nun endlich einmal behoben sein könnten. Zunächst funktionierte das Prozedere auch ohne Probleme. Eine schlanke Web-Anwendung konnte in das Deploy-Verzeichnis des JBoss kopiert werden und schon waren die Änderungen im Programmcode verfügbar.
Aber die Freude währte nicht lange. Nachdem einige Bibliotheken hinzukamen und das Projekt wuchs, trat folgendes Phänomen auf: Nachdem das war-Archiv ins Deploy Verzeichnis kopiert wurde, wurde prompt ein "undeploy" der Anwendung durchgeführt. Anschließend passierte aber leider gar nichts mehr. Es war jedoch zu beobachten, dass der Java-Prozess des JBoss immer mehr Arbeitsspeicher allokierte, und zwar bis zu der mit -Xmx eingestellten Höchstgrenze von einem Gigabyte. Dann brach der Prozess anscheinend ab und der Speicher wurde wieder freigegeben. Der Vorgang begann dann wieder von vorne.
Nach einigem Probieren war dann die Lösung klar: Der JBoss hat anscheinend Probleme damit, ein Hot-Deployment mit war Archiven durchzuführen. Sobald das war Archiv wiederum in ein ear-File gepackt wurde, funktionierte es ohne jegliche Probleme. Leider hat mich die Lösung dann doch einige Zeit gekostet, von nun an werde ich wohl nicht mehr probieren, ein schlankes war-Archiv im JBoss zu verwenden.
Noch ein Tipp: Bitte für den JBoss 5.1.0 Facelets in der Version 1.1.14 verwenden. Denn bei Version 1.1.13 wurden die Facelet-Seiten schlichtweg ignoriert, sodass keinerlei Facelet-Tags interpretiert wurden. Das traurige dabei: Facelets 1.1.13 wird standardmäßig mit dem JBoss ausgeliefert.
Abonnieren
Posts (Atom)