JavaRebel Erstbericht
Your trail: 

This page (revision-5) was last changed on 20-Dec-2010 11:11 by Dieter Käppel

This page was created on 03-Oct-2009 13:01 by Dieter Käppel

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
5 20-Dec-2010 11:11 8 KB Dieter Käppel to previous JavaRebel ==> JavaRebel Erstbericht
4 20-Dec-2010 11:11 8 KB Dieter Käppel to previous | to last
3 05-Oct-2009 09:41 8 KB Dieter Käppel to previous | to last
2 03-Oct-2009 13:03 7 KB Dieter Käppel to previous | to last
1 03-Oct-2009 13:01 6 KB Dieter Käppel to last

Page References

Incoming links Outgoing links
JavaRebel Erstbericht ...nobody
JavaRebel Erstbericht

Version management

Difference between version and

At line 4 changed 2 lines
!Evaluierung
Grundsätzlich funktioniert das angepriesene Hot Replacement von Klassen und Ressourcen für einfache Projekte. Innerhalb eines realistischen Projekts in der aktuellen Zeit, finden eine Menge Zugriffe auf Resourcen über verschiedene Mechanismen geladen. Alleine die Lademechanismen der Application Server finden nur zum Teil über ClassLoader statt, zum anderen auch über URLs vom Typ http, file oder gar jar. Hinzu kommen Frameworks wie Spring, Seam, Facelets etc. Weite Lademechanismen kommen oft durch spezielle Projektanforderungen hinzu.
!Zusammenfassung
Grundsätzlich funktioniert das angepriesene Hot Replacement von Klassen und Ressourcen für einfache Projekte. Innerhalb eines realistischen Projekts in der aktuellen Zeit, finden eine Menge Zugriffe auf Resourcen über verschiedene Mechanismen geladen. Alleine die Lademechanismen der Application Server finden nur zum Teil über ClassLoader statt, zum anderen auch über URLs vom Typ http, file oder gar jar. Hinzu kommen Frameworks wie Spring, Seam, Facelets etc. Weitere Lademechanismen kommen oft durch spezielle Projektanforderungen hinzu.
At line 7 changed one line
Für die meisten der Application Server und einige der Frameworks bietet Zero Turnaround auch Plugins an, sodass diese vollständiger unterstützt werden oder zum Teil überhaupt noch korrekt arbeiten. Ich habe ca. 12 Stunden investiert, ein Projekt mit Maven, Glassfish, Seam, Facelets und einigen Facelet-Libraries unter Rebel zum Laufen zu bekommen. Nach einiger Recherchearbeit war ich mir nicht im Klaren, wie die vom empfohlene Vorgehensweise wäre.
Für die meisten der Application Server und einige der Frameworks bietet Zero Turnaround auch Plugins an, sodass diese vollständiger unterstützt werden oder zum Teil überhaupt noch korrekt arbeiten. Ich habe ca. 12 Stunden investiert, ein Projekt mit Maven, Glassfish, Seam, Facelets und einigen Facelet-Libraries unter Rebel zum Laufen zu bekommen. Nach einiger Recherchearbeit war ich mir nicht im Klaren, wie die vom Hersteller empfohlene Vorgehensweise wäre und ob meine Anforderungen damit überhaupt erfüllbar wären.
At line 9 added one line
!Bericht
At line 25 changed one line
Entmutigt experimentierte ich noch etwas mit dem Eintragen verscheidener Pfade herum, indem ich den Code der Plugins studierte. Den Gedanken ein Plugin zu entwickeln schlug ich mir auch wieder aus dem Kopf. Diese waren zum Teil zwar sehr klein und einfach, allerdings bezogen diese sich auch auf Schnittstellen des JavaRebel Kerns von dem ich keinen Code hatte.
Entmutigt experimentierte ich noch etwas mit dem Eintragen verscheidener Pfade herum, indem ich den Code der Plugins studierte. Den Gedanken ein Plugin zu entwickeln schlug ich mir auch wieder aus dem Kopf. Diese waren zum Teil zwar sehr klein und einfach, allerdings bezogen diese sich auch auf Schnittstellen des JavaRebel Kerns von dem ich keinen Code hatte. Nach einem ganz großen und sinnlosen Turnaround und Zero Erfolg, strecke ich also die Waffen nieder ;-)
At line 27 changed one line
Nach einem ganz großen Turnaround von 12 Stunden und Zero Ergebnis strecke ich also die Waffen nieder ;-)
!Fazit
Für die Zeit so ein Projekt mit JavaRebel aufzusetzen, selbst wenn es erfolgreich ist, kann man viele, viele Redeploys machen. Langfristig wäre das schon eine interessante Sache, daher bin ich auch bereit das Thema irgendwann nochmals anzugreifen. Nur in ein Tool von einem kommerziellen Hersteller würde ich nicht mehr viel Zeit investieren, da durch den Mangel an Source Code sehr schwer abzuschätzen ist wie weit man vom Erfolg noch entfernt ist, ob es überhaupt möglich ist und an die Informationen heran zu kommen, die für den erfolgreichen Einsatz überhaupt möglich wären.
!Vision
Da das Thema schon wichtig ist, langfristig ein kritischer Faktor für den Geschäftserfolg ist, spiele ich auch mit dem Gedanken selbst so einen Hot Deployer zu implementieren. Eigentlich ist es keine große Sache, über die Instrumentation API einen Wrapper um die Klassen zu bauen, der über einen Timestamp den Bedarf zur Aktualisierung prüft. Die xml Config Datei ist grundsätzlich auch eine gute Idee, um flexibel auf Anforderungen im Einsatz reagieren zu können.
Dazu würde ich noch Prüfen, in wie weit man in den URL Lademechanismus zB. durch URL.setURLStreamHandlerFactory eingreifen kann. Damit könnte man relativ einfach Umleitungen für alle Arten von Resource-Loader definieren. Einzig das Caching der Frameworks wird ein Problem sein, dass nur durch individuelle Plugins in den Griff bekommen werden kann. Für 90% der Aufgaben sind keine Plugins erforderlich. Die Haupthindernisse sind Code-Changes und die Änderung von Ressourcen wie XHTML-Dateien.
This page (revision-5) was last changed on 20-Dec-2010 11:11 by Dieter Käppel Top
Übersicht
Startseite
Das Unternehmen
Produkte
Consulting
Referenzen

Jobmarkt
Jobangebote
Profile

Hilfe
Suche
Seitenindex
Letzte Änderungen
Sichere Verbindung

Systeme
Tickets
Jenkins
Nexus
SVN
Email Client
686 Aufrufe

referenziert von
...nobody

© 2022 Intersult GmbH | Jobs | Kontakt | Presse | AGB | Impressum | Cookies | Datenschutz | Serverzeit 2024.11.24 06:16:40 GMT