Klasse aus .jar updaten

Hi,

also die Versionisierung läuft bei mir nach dem Schema Version . Update. Patch und Build lasse ich außen vor, denn soviele Unterteilungen benötige ich nicht.

Ich persönlich bevorzuge es, wenn gewisse Dinge einheitlich sind. Ich meine damit, dass ich auf der einen Seite einen Updatemechanismus hab, der Hash-Codes (Anwendungsupdate) zur Identifizierung verwendet und auf der anderen Seite (Datenupdates) plötzlich eine Versionisierung nach dem Schema "Version.Update". Ich habe schon überlegt dein generelles Vorgehen zu verwenden, jedoch nicht den Hash-Code, sondern die Versionisierung zu verwenden.

Wie funktioniert das Datenupdate? Ich versuch es mal zu erklären. Ich habe einen Bereich auf meinem FTP-Server, zu dem genau ein User Zugriff hat. Dieser User ist in der Anwendung hinterlegt. Wenn ich nun (mal einfach ausgedrückt) den Button "Update" drücke, dann wird eine Verbindung zum FTP hergestellt. Auf dem FTP können verschiedene Updates für verschiedene Kunden bereit liegen. In welchen Ordner die Anwendung auf dem FTP wechseln muss, wird vor Auslieferung konfiguriert. Also es wird eine Verbindung zum FTP hergestellt und mit der Konfiguration in einen bestimmten Ordner auf dem FTP gewechselt. In diesem Ordner befindet sich eine Datei mit Update-Informationen (Welche Updates, wo liegen die Updates, wohin müssen die Updates kopiert werden etc.). Diese Datei wird nun verarbeitet und die Updateinformationen extrahiert. Anhand dieser Informationen werden die Updates nun geladen. Ich habe so ein Vorgehen gewählt, denn selbst wenn es verschiedene Versionen für verschiedene User gibt, so sind manche Updates trotzdem gleich und ich möchte die nicht öfter als einmal auf dem FTP haben, also werden die in einen gewissen Ordner gelegt. In der Date mit den Updateinformationen steht eben dann der Pfad, wo das Update abgeholt werden kann. Puhh..ich weiß es ist etwas umständlich zu erklären :). Bei Fragen...einfach fragen.

Nun kann es aber passieren (wir sind alle nur Menschen), dass in dem Datenupdate ein Fehler ist, dann muss dieses Update neu eingespielt werden. Momentan ist mein Update-Mechanismus so aufgebaut, dass nur Updates verarbeitet werden können, bei denen die Versionsnummern der Anwendung und der Datendatei gleich ist. Sollten die Versionsnummer unterschiedlich sein, so kann es u.U. vorkommen, dass das Datenmodell nicht zu den Daten passt und es wird eine Exception ausgelöst. Das möchte ich damit verhinden. Nun kann es aber passieren, dass sich in dem Datenupdate ein Fehler eingeschlichen hat. Um diesen Fehler zu beheben muss ich ein z.B. Update 3_2 (Version 3 Patch 2) nachschieben. Das meinte ich mit Fehler.

Das Vorgehen bei den Datenupdates funktioniert ja soweit, bis auf die Installation eines Patches. Was noch nicht funktioniert ist das Update der Anwendung, wsa ich aber mit deinem Beispiel ganz gut umsetzen könnte.

Ach ja die Underscores waren nur Beispiele. Ich wollte es nur schemenhaft darstellen.

Bei Fragen....einfach fragen :).

Grüße

Sascha

PS: Auch ich arbeite an einem sehr großen Projekt und dieser Updatemechanismus darf auf keinen Fall irgendwelche Fehler verursachen.
 
Hui ... */me ist grad etwas platt*

Also so an sich verstehe ich alles, auch wenn ich persönlich die Lösung via FTP nicht gerade so toll finde.

Das du gerne sowohl für Anwendungs- als auch Datenupdate lieber ein und dasselbe System nutzen willst kann ich durchaus nachempfinden. Würde mir ähnlich gehen.
Wo du jedoch differenzieren musst *mal als Pseudocode veranschaulicht* :
versionAnwendung != versionDaten
Du solltest diese Beziehung das nur die Daten verwendet werden können deren Version der der Anwendung selbst gleicht lösen, denn es hat nichts damit zu tun wie aktuell die Daten im Vergleich zur Anwendung sind so lange das Format (das Datenmodell selbst) passt.
Du könntest es natürlich so lösen das du für die Datenupdates das Patchlevel mit in die Versionsnummer aufnimmst um einerseits anhand der Versionsnummer und dem Update zu prüfen ob die Daten zur Version der Anwendung passen und andererseits anhand des Patchlevels die Daten-Version an sich prüfen.
Eine andere Variante zum Prüfen nur anhand der Versionsnummer fällt mir gerade nicht ein.
 
Hi,

du bist gerade etwas platt? Ich hoffe nicht von meiner Beschreibung!

Also mir persönlich gefällt es auch nicht, das sich auf einen FTP zugreifen muss, aber die Datenupdates sind etwas sensibel. Ich könnte natürlich alle Updates in eine MySQL-Datenbank packen und dann auf die MySQL-Datenbank zugreifen. Das ginge natürlich auch und der FTP könnte sterben. Muss ich mal genauer verfolgen.

Du hast natürlich recht, dass ich die Datenupdates von der Anwendung her lösen muss. Das ist ein echt guter Vorschlag, denn ein Anwendungsupdate bedeutete ja nicht immer, dass sich auch das Datenmodell geländert hat. Also echt guter Vorschlag.

Ich hätte dann eben folgende Versionisierung:

Anwendung = Version . Update
Datenupdate = Version . Update

Beim Datenupdate müsste eben dann die Version (Datenupdate) = Update (Anwendung) sein und ich hätte die Beziehung Version (Anwendung) = Version (Datenupdate) aufgelöst. Ich könnte dadurch natürlich auch Updates der Anwendung nach außen geben, ohne ein neues Datenupdate bereit zu stellen. Auch eine Fehlerbehebung der Datenupdates könnte ich bereit stellen, indem die Version gleich und sich nur die Update /Nummer/ID/etc. ändert. Den Patch in der Versionisierung würde ich hierbei gar nicht benötigen und mir würden eben Version . Update ausreichen.

Hmm..das gefällt mir gerade echt gut :).

Sehr gute konstruktive Diskussion :).

Dennoch werde ich natürlich deinen Vorschlag bzgl. Update der Anwendung (Jar-Files) verfolgen und dann auch ggf. etwas abgeändert in meine Anwendung integrieren. Werde wohl auch bei der Anwendung dann auf eine Versionisierung setzen müssen. Anfangs hatte ich mir mal einen Zeitstempel ausgedacht, nur reicht der bei meinen Updates leider nicht mehr aus.

Viele Grüße

Sascha
 
Nein ... platt war ich wegen etwas anderem .. nicht wegen deinem Post *meiner war ja noch länger xD*.

Hmm ... also über eine solche Verbindung habe ich persönlich noch nie nachgedacht , aber es ist eine sehr saubere Varainte wenn gleich auch ohne diese ausführliche Erklärung nicht verständlich.

Was die "sesibilität" der Daten angeht : wenn wir hier beide von der selben Bedeutung von "sensibel" reden dann hätte ich einen zweiten Grund warum FTP hier eine schlechte Wahl wäre : alle Daten werden PLAIN übertragen. Gut ... das ist zwar bei HTTP oder einer sonstigen nicht verschlüsselten Verbindung ebenfalls der Fall , jedoch lässt sich HTTP mit nur wenig aufwand durch SSL / TSL sichern. Um etwas änliches mit FTP zu erreichen bräuchtest du einen SSH-Zugang zum Server *das Protokoll wäre dann FTPS*.

Wenn es also wirklich um sensible Daten geht kann ich dir noch das RSA/AES-hybrid-Kryptosystem aus meinem Blog empfehlen. Es ist zwar nicht mehr "up-to-date" da ich mitlerweile einige Verbesserungen daran vorgenommen habe , aber da ich vor hatte in ein paar Minuten eh mal mit dem Blog zum App-Patch anzufangen kann ich das dabei gleich mit auf den neusten Stand bringen.

Das bei deiner Art von Updates kein herkömmliches System greift *Timestamp , Hash* sondern du wirklich einen eindeutigen Identifier brauchst musst du es leider so machen *man könnte im schlimmsten Fall immer noch über eine Datenbank die Timestamps / Hashes mit der jeweiligen Versionsnummer verknüpfen ... aber das würde mehr Aufwand machen als es gleich so zu machen wie du es beschrieben hast*.
 
Hi,

naja es ist schon so, dass die Daten zwar auf dem FTP liegen und diese Plain übertragen werden, die Daten jedoch serialisiert, gezipped und mit einem Passwort verschlüsselt.

Gibst du mir bitte Bescheid, wenn dein Blog fertig ist? Wäre klasse.

Viele Grüße

Sascha
 
Zuletzt bearbeitet:
Ok ... also aus einem verschlüsseltem , gezipptem serialisiertem Java-Objekt kann man so natürlich mit den PLAIN-Daten die man eventuell abfangen könnte nichts anfangen. Selbst wenn man das Passwort knackt bräuchte man immer noch die entsprechenden Java-Klassen und das Wissen wie diese Funktionieren um aus den serialisierten Objekten wieder an die Informationen zu kommen.

Punkt für dich =D
 
Hi,

so ohne alles bekommt nicht jeder die Daten :).

Was natürlich schön wäre, wäre natürlich ein Log auf dem Server, indem Clients geloggt werden, die das Update geladen haben oder bei denen es Probleme gab.

Das ist aber alles für die Basisversion, die bald fertig werden muss, nicht mehr angedacht. Gibt ja auch verschiedene Weiterentwicklungen. Der Updatemechanismus muss jedoch zu 100% stehen :).

Grüße

Sascha
 
So ... habe den Launcher schon mal fertig in meinem Blog stehen.
Den Server werde ich morgen machen da es ja mitlerweile fast um 10 ist und mir die Augen zufallen.
 
Hi,

okay dann werde ich mir da mal ein bisschen was abgucken, wenn ich auch nicht alles so verwenden kann :).

Viele Grüße

Sascha
 
Hi,

ich hab nun meinen Updateservice etwas erweitert und mir aus deinem BLOG ein paar Denkanstöße geholt. Es funktioniert soweit auch schon mal ganz gut (Start der heruntergeladenen Anwendung mit dem Starter etc.). Ein paar kleinere Programmierunschönheiten hab ich noch drin, aber die werden auch noch beseitigt.

Ich habe die Installation der Programmupdates noch etwas erweitert und zwar gibt es für jede heruntergeladene jar (oder auch sonstiges) eine Updateinformation in Form einer XML-Datei. Darin gibt es z.B. das Propertie "InstallPath", also einen Installationspfad. Es kann ja gut möglich sein, dass ich nur eine Bibliothek updaten möchte, die sich in irgend einem Unterverzeichnis befindet oder ich eine Bibliothek in einem speziellen Verzeichnis benötige. Ist kein InstallPath angegeben, so sucht sich der Anwender eine bereits vorhandene Bibliothek und überschreibt die alte mit der neuen, ansonsten wird die Bibliothek eben in ein neues Verzeichnis kopiert. Funktionert schon mal ganz gut.

Für die Verwaltung der Updates habe ich mir eine Anwendung geschrieben (ist natürlich speziell für meine Situation ausgelegt), inder ich eben alles einstellen und erzeugen kann. Durch Validierungen/Konsistenzbedingungen konnte ich auch so einige Fallstricke überwinden :). Bisher funktionierts, aber ich möchte das noch weiter ausbauen, dass wirklich nichts mehr schiefgehen kann :).

Ach ja ich gebe noch eine Info an die Anwendung weiter. Sollte ein Update nicht installiert werden können, so wirft die Anwendung eine Meldung aus "Ein Update konnte nicht installiert werden. Bitte wenden Sie sich an den Softwarehersteller" oder wenn alles funktioniert hat "Ihre Anwendung wurde erfolgreich aktualisiert". Es kann ja immer wieder mal vorkommen, dass ein Update nicht kopiert werden kann (Zugriffsrechte etc.). In diesem Fall muss man die Log-Dateien auswerten.

Soviel erst mal zu meinem Updateservice :).

Vielen Dank nochmal für deine Denkanstöße :).

Grüße

Sascha
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück