Hallo,

ich möchte mein Java prog beim Starten updaten. Das Programm ist als .jar zusammengefasst und ausführbar. Kann mir jemand verraten, wie man jetzt eine einzelne Klasse updaten kann?


Danke

JAR steht für Java Archiv. Du kannst .jar-Dateien z.B. auch mit winrar öffnen. Du kannst in .jar-Dateien auch einzelne Dateien laden und schreiben. Wenn mich nicht alles täuscht lassen sich einzelne Dateien austauschen indem du so tust als würdest du sie neu anlegen. Die nltigen Klassen dazu findest du hier.

Hallo
Dafür gibt es das Paket java.util.jar mit folgenden Klassen:
Attributes
Attributes.Name
JarEntry
JarFile
JarInputStream
JarOutputStream
Manifest
Pack200

Du kannst (analog zu ZipFile/ZipEntry/Zip...) vorgehen. Unter http://download.oracle.com/javase/tu...jar/index.html gibts ein tutorial zu den Jar-Files. Natürlich kannst du Dateien hinzufügen und entfernen. Falls dein Jar-File signiert ist, geht diese Signatur aber vermutlich verloren.

Hi,

meinst du mit "updaten beim start" das Hinzufügen eines .class-Files?
Da würde nämlich folgendes Kommando passen:
jar u MyJar.jar MyClassToAdd.class

Gruß

Ich glaube TO will etwas ganz anderes, nämlich das hier : http://www.tutorials.de/java/365360-...n-updaten.html
Wir haben damals dieses Thema so breitgetreten das darin wirklich alles zu finden ist um eine Applikation beim starten zu updaten. Wenn du weitere Fragen zu diesem Thema hast bin ich dir gerne behilflich da ich mitlerweile *dieser Thread ist schon sehr alt* eine etwas verbesserte Variante habe und diese auch gerne zur Verfügung stelle.

Hi SpiKEe,

ich bin selber gerade auf der Suche nach Anregungen für einen Updater beim Start einer Anwendung. Hab mir auch den "alten"-Thread durchgelesen.

Da du schreibst, dass du bereits eine verbesserte Variante hast, würde ich gerne mehr über diese Variante erfahren.

Grüße

Sascha

Hey MS-Tech,
kein Problem ... ich werde diese heute noch in meinem Blog veröffentlichen.
Um dir allerdings hier und jetzt schon mal schnell ne Einführung zu geben wie das ganze dann genau Funktioniert beschreib ichs mal schnell :

Beim Starten deiner App startest du nicht direkt deine Hauptklasse sondern einen vorgeschalteten Launcher. Daher kann

Code java:

1	public static void main(String[])

aus deiner Hauptklasse verschwinden da diese über den Launcher gestaret wird *WIE weiter unten*.
Der Launcher kann auch im selben Paket oder sogar im selben JAR liegen wie deine eigentliche Hauptklasse.

Wird nun dein JAR gestartet wird erst der Launcher gestartet. Wichtig hierführ ist das

Code java:

1	public static void main(String[])

aus deiner Hauptklasse in den Launcher wandert. Auch muss der Main-Class-Eintrag im Manifest geändert werden.
Der Launcher prüft bei einem dazu passenden Server *kann ich dir gerne auch zur Verfügung stellen wenn du möchtest* oder das aktuelle JAR überhaupt noch aktuell / gültig ist.

Das kannst du entweder mit einer Versionsnummer im Launcher machen *was aber *aus Erfahrung* eher schlecht ist da wenn du es mal vergisst dieser Nummer zu ändern eine Endlos-Schleife entsteht*.

Oder über einen Hash-Wert des JAR-Files.
Hier sind Hashverfahren nach dem SHA-2 Standard *SHA-256 , SHA-512* zu empfehlen da MD5 und SHA-1 sehr schnell zu kollisionen führen KÖNNEN *hier mal nicht als Brute-Force Angriff sondern als Zufälliger Treffer gesehen*. SHA-256 bietet hier schon eine sehr gute Sicherheit bei kleinem Aufwand. Außerdem wird SHA-256 vom SUN -Provider unterstützt. Du brauchst also noch nicht mal eine extra LIB dazu.

Nun baut der Launcher eine Verbindung zum Update-Server auf und Fragt nach für das JAR-File "abc.jar" der Hash "aabbccddeeff" noch aktuell ist. Der Update-Server beantwortet diese Frage entweder durch "wissen" *weil er beim Start das aktuelle JAR-File eingelesen und gehashed hat *sehr schelcht da bei jedem Update der Update-Server neu gestartet werden muss** oder Fragt eine Datenbank nach den nötigen Infos. *Meine Variante bezieht sich auf eine bereits lauffähige MySQL-Datenbank mit entsprechendem User , Rechten und Tabellen.*

Nun sendet der Server an den Clienten ein Kommando in dem entweder "HASH OK" / "FILE UP-TO-DATE" oder eben "HASH FAIL" / "FILE OUT-OF-DATE" steht.

Wenn der Hash OK ist dann läd der Launcher die Hauptklasse einfach in dem ein neues Objekt dieser Klasse erzeugt wird. Desshalb brauchst du bei meiner Variante auch mindestens einen public Konstruktor deiner Hauptklasse. *Wenn der Launcher im selben "package" wie die Hauptklasse liegt reicht auch ein protected Konstruktor.*

Wenn vom Server allerdings ein FAIL kommt fragt der Launcher nun nach den aktuellen Daten. Da sich der Hash auf das gesamte JAR bezieht sollte auch das komplette JAR heruntergeladen werden. Das macht sich am einfachsten wenn du mit binären Streams *also den ganz einfachen InputStream / OutputStream* arbeitest. Wenn du mit String-basierten Streams arbeiten willst musst du das JAR vor dem Senden natürlich BASE64 kodieren und nach dem empfangen wieder dekodieren. Da BASE64 aber im package sun.* liegt würde ich dir von dessen Verwendung abraten *wenn unbedingt BASE64 dann selbst implementieren oder eine Lib von einem Drittanbieter nutzen*.

Die Daten des "neuen" JAR werden nun als "abc.new" gespeichert.

Damit hast du erstmal das neue JAR auf dem Rechner.
Was musst du jetzt aber machen um das alte gegen das neue zu tauschen ?
Nun ... wie du ja in meinem Post gelesen hast geht es nicht einfach so da die aktuelle Instanz der JVM auf das aktuelle "abc.jar" zugreift und es "gesperrt" hält. Um das jetzt zu ändern musst die die JVM beenden. Aber dann bist du ja raus aus deiner App ... und nun ?
Tja ... um das zu verhindern musst du vor dem Beenden der aktuellen JVM eine neue Instanz starten. Da es nicht einfach reicht eine 3te Klasse zu nehmen musst du einen komplett neuen Prozess anstoßen. Der Einfachheit halber habe ich das mit einem simplen

Code java:

1	Runtime.getRuntime().exec()

gelöst. Dieser Aufruf veranlasst das System *mit entsprechendem String als Übergabewert* eine komplett neue Instanz der JVM zu starten welche von deiner ursprünglichen unabhängig ist.

Nun kannst du beruhigt aus der ursprünglichen JVM mit System.exit(int) aussteigen.

Was macht die neue JVM jetzt ?

Nun ... natürlich startest du nicht einfach eine neue JVM mit dem neuen JAR als Parameter. Stattdessen wird eine Helper-Klasse verwendet. Diese Helper-Klasse hat nichts weiter zu tun als mit einem

Code java:

1 2	File file=new File("abc.jar"); while(!file.delete()) { }

darauf zu warten das die alte JVM endlich aussteigt und die Sperrung des JAR aufhebt. So bald das alte JAR gelöscht ist kannst du nun mit der Methode

Code java:

1	File.renameTo(File)

das neue JAR "abc.new" in "abc.jar" umbennen.

Nun startest du aus dieser Helper-Klasse ebenfalls eine neue JVM-Instanz mit "abc.jar" als Parameter. Das ganze läuft nun wieder von vorne ab ...

mit einem Unterschied : der Server meldet jetzt das der Hash OK ist ... und der Launcher fährt mit dem Laden der Hauptklasse fort.

Ich weis ... so ausführlich beschrieben hört sich das ganze unglaublich kompliziert an ... ist es aber nicht. Im Gegenteil : es ist sogar so einfach das du es sogar mit normalen HTTP-Server machen kannst. Alles was du dafür brauchst ist nur ein wenig Einarbeitung in HTTP oder nutzt die Apache Commons Lib dafür *sehr beliebt hier im Forum ... daher auch viele die dir dabei helfen können*.

Als Anmerkung : wenn du an deine App Parameter übergibst kannst du diese "durchreichen" in dem die die Helper-Klasse so umschreibst das sie die von der ersten JVM erhaltenen Parameter an die neue übergibt. Das ist nur jeweils eine Zeile Code sowohl im Launcher als auch in der Helper-Klasse.

Wie gesagt : ich werds nachher noch alles schön zusammen stricken und dann in meinem Blog veröffentlichen. Ich werde auch gleich die Server-Klassen dazulegen.

Hi SpiKEe,

also so eine ausführliche Antwort hätte ich ehrlich gesagt nicht erwartet . Klasse****** Großes Lob******

Ich muss mir deinen Beitrag jetzt erst mal durchlesen und dann kann ich ein Feedback abgeben. Ich muss bei mir grundsätzlich 2 verschiedene Update-Varianten unterscheiden. Es gibt Update´s der Anwendung und es gibt sogenannte Datenupdates, die eben die Daten in der Datenbank updaten. Diese Daten kommen meistens als XML, CSV oder Excel in die Anwendung. Hierbei kann ich natürlich keinen HashCode abfragen, sondern muss mit einer Versionisierung arbeiten. Außerdem muss man bei diesen Datenupdates auch auf Fehler reagieren können...kurzes Beispiel...

Anwender hat z.B. die Version 3 der Anwendung auf seinem Rechner und nun zieht er sich ein neues Datenupdate. Das Datenupdate ist für die Version 3 gedacht (Datenmodell sowie Daten aus dem Update müssen zusammen passen). Irgendwo in diesem Datenupdate hat sich ein Fehler eingeschlichen und wir müssen ein neues Update nachschieben. Das neue Update ist auch für die Version 3 gedacht. Hierbei entsteht das Problem, dass mir eine Versionsnummer nicht reicht, also benötige ich darüber hinaus noch eine Versionsnummer innerhalb dieser Updates, also gibt es Update 3_1 und Update 3_2, sprich 2 Versionsnummern.

Die Anwendung selber kann ich ja z.B. nach deinem Schema updaten und so wäre auch mein Vorgehen gewesen, also Update über die Update-Maske runterladen, dann Anwendung neu starten und Update installieren.

Ich werde jetzt mal in deinen Blog gucken .

Viele Grüße

Sascha

Ja sorry,
ich bin gestern einfach nicht mehr dazu gekommen mein System zu bloggen. Werde das im Verlauf des Nachmittages nachholen.

Was du schon richtig angesprochen hast sind die zwei grundlegenden Arten von Updates : Anwendung und Daten
Da sich meine Variante nur auf die Anwendung selbst bezieht kann es sein das es für das Daten-Update nicht funktioniert. Da ich mich selbst aber noch in der Anfangsphase meines großen Projektes befinde *wird noch nicht verraten ... aber zum Public Beta lade ich euch dann noch mal ein wenns soweit ist xD* und jetzt mit Java7 auch einiges leichter umsetzen kann *ich arbeite mit Java7 seit Build43* werde ich bestimmt auch an diesen Punkt stoßen wo ich mir gedanken über die Daten machen muss.

In wie fern du das allerdings mit dem "Fehler" meinst verstehe ich nur halb. Wenn du einen Logik-Fehler meinst : ja sowas passiert ... aber was noch ? Das musst du mir dann doch noch mal erklären.

Was die Versionierung angeht : es ist üblich Punkte oder Begriffe zu nutzen , underscores sind eher unüblich. Auch unterteilt man zwischen verschiedenen Stufen der Versionierung. Das bekannteste Schema ist das hier :

MajorMajorVersion . MajorMinorVersion . MinorMajorVersion . MinorMinorVersion

auch kann man es wie folgt deuten :

Version . Update . Patch . Build

wobei beide Varianten ungefähr gleich oft vertreten sind. Will man es kürzer so lässt man in der Regel die letzte oder die letzten zwei Angaben weg.
Außerdem sieht es nicht schön aus wenn du da mit sowas wie

Version 5.2.17 Update 9.3 Patch 2

ankommst ... da sollte man sich dann doch an die bekannten Konventionen halten. Wobei erlich gesagt habe ich bisher noch nichts gesehen welches noch eine fünfte Unterteilung hat. Ich wüsste auch erlich gesagt nicht wozu man es nun noch weiter spezifizieren sollte als bis runter zum Build.

Wenn du so etwas im größeren Stile machen willst, solltest du dir mal OSGi https://secure.wikimedia.org/wikipedia/en/wiki/OSGi und dessen Referenz-Implementierung Equinox https://secure.wikimedia.org/wikiped...i/Equinox_OSGi ansehen. Das wird verwendet, um in Eclipse (und Eclipse-basierten Anwendungen) verschiedene Versionen von Klassen verwalten willst.
Interresant ist auch das Spring Framework, https://secure.wikimedia.org/wikiped...ring_Framework

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