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 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
485 Aufrufe

referenziert von
...nobody

© 2022 Intersult GmbH | Jobs | Kontakt | Presse | AGB | Impressum | Cookies | Datenschutz | Serverzeit 2024.05.09 15:18:05 GMT