Launche update

[Launcher update]

Hallo,
ich habe eine ganz normal aufführbare jar Datei.
Diese wird über einen Launcher gestartet welcher auch gleich dafür sorgt, das die Jar aktuell, zu Not werden halt Sachen über einen Server in der passenden Version gedownloaded. Kein Problem also.

Jetzt möchte ich aber den Launcher updaten.
Habt ihr eine Idee wie man das machen könnte?

Das einzige was mir einfallen würde wäre, in der Jar eine 'Anzeige zu schalten' ala:

[Duke]'Hey dein Launcher ist nicht mehr aktuell, wenn du [ts=Ich bin KEIN Link!][/ts]hier drauf klickst, kannst du einen aktuellen downloaden.'[/Duke]

Naja, oder so ähnlich.

Habt ihr irgendeine bessere Idee

 

[truesoul]

Die SuFu benutzt?
http://www.java-forum.org/allgemeine-java-themen/119902-eigener-updatemechanismus.html

Vielleicht ist das, was du suchst?!

 

[Launcher update]

Das Updaten funktioniert wunderbar, wie gesagt.
Mein Ziel ist es jetzt den 'Update-Mechanismus' up zu Daten.

 

[Chumax]

Aus dem Hauptprogramm schauen, ob der Updater aktuell ist, wenn nicht updaten. Würde überlegen dafür den User gar nicht mit zu nerven, sondern einfach das Updater jar file einfach auszutauschen.

 

[truesoul]

Wärst du auf den Link gegangen hättest du sehen können, das genau das besprochen worden ist.

 

[irgendjemand]

um vielleicht noch mal auf das verlinkte beispiel zurück zu kommen ..

was Kr0e damals schriebe mit minecraft ist so nicht richtig ...

die minecraft.exe ist ein mit launch4j gewarptes jar ... welches auch nur das laden / updaten der eigentlichen game-files *%appdata%/roaming/.minecraft/bin* übernimmt und diese dann läd ... minecraft.exe selbst wird dabei garnicht geupdated ...

wenn man nun "main" und "updater" in seperaten jars ausliefert dann wäre eine mögliche variante das bereits angesprochene : "main" prüft zu aller erst ob der updater aktuell ist ... wenn nicht wird dieser aktualisiert ... und dann halt der updater gestartet der den rest des programms updated ...

alternativ *so mache ich es* stellt "main" selbst fest ob es noch aktuell ist ... wenn nicht wird vom server die aktuelle version des updaters und von "main" geladen ...
der updater hat dann lediglich die aufgabe die alte "main" gegen die neue auszutauschen ...
um das zu ermöglichen brauchst du allerdings eine 2te vm instanz ... ergo : aus "main" muss der "updater" mit ProcessBuilder *bzw Runtime.exec()* in einer neuen VM gestartet werden ... danach beendet sich "main" einfach mit System.exit()

"updater" läuft derweil in einem while

File mainFile=new File("main.jar");
while(!mainFile.delete()) { Thread.sleep(100); }

nach dem "main" erfolgreich gelöscht wurde wird einfach die neue version *z.b. mit .new* umbenannt und dann mit einem weiteren Process call in einer nun 3ten VM gestartet ... "updater" beendet sich dann mit System.exit()

tipp : wenn man will das der updater sich nach dem update selbst löscht kann man folgenden trick verwenden
da es NICHT möglich ist in einem jar mit File.deleteOnExit() zu arbeiten läd man stattdessen nur ein class file runter und startet dieses dierekt ... denn dann funktioniert sogar ein deleteOnExit() und vom updater ist nach dem "update" keine spur mehr zu finden ...

 

[Launcher update]

Vielen Dank, führ die ganzen tipps,

leider, das muss ich gestehen, habe ich mich so in das Problem vertieft, das ich als gegeben vorrausgesetzt habe, das man nicht weiß wo sich der Launcher befindet.

Das heißt das die Main den Launcher updaten fällt schonmal flach.
Auch das der Launcher sich selbst updatet geht nicht, da er nicht dafür ausgelegt ist. (im Launcher 2.0 ist natürlich ein Launcher update Mechanismus vorgesehen (Danke @ irgendjemand))

Das heißt ich habe den stand das ich ihn nicht aus der Main-jar updaten kann, und leider auch nicht über den veralteten Launcher. Tut mir Leid, ich fürchte ich habe gedacht das wäre selbstverständlich. Entschuldigung!

@truesoul gegen deinen blinden Vorwurf, ich hätte den Link nicht gelesen habe ich nichts, ich denke es gab schon direkt ein Missverständnis bei der Problemstellung. Aber trotzdem, selbst WENN mein Problem im Link gelöst worden wäre, müsste man mir doch nicht Blindlings unterstellen, ich hätte den Link nicht gelesen? Wir kennen uns doch nochnichtmal, wie möchtest du mich da einschätzen? <- Bitte nicht zu ernst nehmen. Ich bin nicht nachtragent, und Blase die Sache gerade auf

 

[irgendjemand]

@TO
hmm ... "nicht wissen wo sich der launcher befindet" ... gut .. sehe ich überhaupt nicht als problem ... da man dies innerhalb des launchers feststellen und dann main als parameter mitgeben kann ... so hat man dann die position des launchers und kann diesen *je nach implementierung* manipulieren ...

das ist also eher eine ausflucht als etwas was man nicht mit ein paar zeilen rausfinden könnte ...

auch wenn man im ersten momment nicht weis wo sich der launcher befindet ... so muss doch zumindest der launcher wissen wo sich das main befindet ...

nun gibt es zwei optionen
1) launcher startet neuen prozess
2) launcher verwendet URLClassLoader

zu 1) wie bereits erwähnt : pfad zum launcher kann als parameter mitgegeben werden
zu 2) da man dann in main als ClassLoader die instanz des URLClassLoader aus dem launcher bekommt ... und dieser als parent den SystemClassLoader ... kann man über einige methoden auch an dessen loading path kommen und damit ermitteln wo die launcher-klasse liegt ... also braucht man nicht mal einen parameter oder sich die arbeit machen im launcher die position zu ermitteln *wobei das nun mal am einfachsten wäre* ... sondern kann diese über die ClassLoader struktur rausbekommen ...

du siehst also : da alleine schon dem launcher bekannt ist wo er sich befindet ... kann man diese info auch entsprechend weitergeben ...


zum "patchen" selbst
ob man nun mit launch4j EXE files draus macht *und sich damit auf WIN beschränkt* oder JARs verwendet ... da man aus einer VM einen völlig neuen unabhängigen prozess starten kann ist es auch kein problem entsprechend aus der aktuellen auszusteigen und so das lock auf das jar freizugeben ... um die dann ersetzen zu können ...
wie genau man das nun umsetzt und ob es überhaupt notwendig ist den launcher zu updaten oder ob man diese von vorn herein so programmiert das dieser kein update braucht ... kommt auf das an was man am ende mit machen will ...

persönlich bevorzuge ich zwar mir die möglichkeit offen zu halten um alle komponenten zu updaten ... aber es gibt auch anwendungsfälle wo dies nicht mal unbedingt nötig ist

 

[Launcher update]

Es tut mir leid, ich fürchte ich habe mich immer noch nicht klar ausgedrückt...
Es ist ja noch der alte Launcher im Umlauf, einer der noch nicht weiß, dass er doch seine Position übergeben könnte. Wie gesagt, bei der Entwicklung vom Launcher in Version 1.0 habe ich nicht daran gedacht, das der Launcher vieleicht auch irgendwann mal ein update braucht.

Ich versuche nochmal mich auszudrücken:

Es sind momentarn ein Launcher und eine Jar im Umlauf.
Die Jar kann problemlos geupdatet werden. Dann gibt es noch den Launcher. Der die Jar updatet usw.
Leider sind bei diesem die ganze von dier vorgeschlagenen Raffinissen noch nicht drinn.

Das Programmieren der eigentlichen 'Update-Logic' ist nicht das Problem, sondern das Bekommen einer Gelegenheit zum Updaten.

Ich hoffe diesmal konnte ich alle missverständniss klären.

(Mir würde nur noch die Idee kommen, den Launcher 2.0 in der Main-Jar mitzuliefern, müsste ja nur einmal geschehen, danach kann der Launcher sich ja selber Updaten)

Viele Grüße

 

[irgendjemand]

hmm .. gut .. das ist jetzt etwas kniffliger ... aber auch kein ding der unmöglichkeit

dann mal noch ein paar fragen

1) wie startet der launcher die eigentlich main ? *falls möglich kompletter source des launchers*
2) welches "format" hat der launcher ? JAR ? EXE ? wie lautet der original dateiname ?
3) wo genau wird die main abgelegt das diese position dem launcher bekannt ist ?
4) welche systeme werden unterstützt ?

ich weis ... alles fragen die man eigentlich nicht stellen müsste wenn der launcher von anfang an mit self-update ausgerüstet worden wäre ...

einzige möglichkeit wäre eine art "hack" die du ins nächste update der main einbaust

du holst dir mit File.listRoots() eine list aller laufwerke *unter unix wird nur "/" returned* und arbeitest diese dann rekursiv durch ...
als erstes könnte man ja erstmal nach dem original dateinamen suchen ... ansonsten wird es schon etwas aufwändiger ...
wenn der launcher als JAR verteilt wurde könnte man , wenn die suche nach original-dateinamen erfolglos bleibt , nach allen JAR files des systems suchen ... diese als JarFile laden ... und drin nachsehen ob deine launcher-klasse(n) enthalten sind ...
wenn auch das nicht geht *z.b. weil der launcher mit launch4j zu einer EXE gewrapt wurde* könnte man noch den user mit nem dialog auffordern den pfad zum launcher auszuwählen *JFileChooser* ... oder halt dieses eine update manuell durchführen zu lassen ...

zu dem "unklar ausdrücken" : in der tat ... du hast leider *immer noch* zu wenig informationen zur aktuellen situation preisgegeben ...

das mit "main weis nicht wo launcher ist" würde sich wie gesagt erübrigen wenn launcher so programmiert wäre das man es eindeutig nachvollziehen kann ...

davon das aber der launcher scheinbar vor sich alleine hin vegetiert hast du ja bis jetzt nichts verraten ...

wenn es also nicht möglich ist durch sonst irgendwelche tricks den pfad zum launcher zu bekommen könnte man noch das update-system ändern das der alte launcher beim update-check nicht mehr funktionsfähig ist ... somit kann man user auf eine leider sehr unangenehme art und weise zu einem manuellen update zwingen ...

 

[Launcher update]

1) wie startet der launcher die eigentlich main ? *falls möglich kompletter source des launchers*

Mit:

Runtime.getRuntime().exec(new String[]{"java","-jar",fileName,parameter});

2) welches "format" hat der launcher ? JAR ? EXE ? wie lautet der original dateiname ?

Mit jsmooth zur exe gemachte jar. Die Jar heißt LauncherXX.jar (xx führ die Version), die erstellte exe heißt einfach launcher.exe.

3) wo genau wird die main abgelegt das diese position dem launcher bekannt ist ?

Unter

System.getProperty("user.home")/.XXXXXXX/XXXXXXX.jar

4) welche systeme werden unterstützt ?

Prinzipiell alle, da ich den Launcher allerdings zur exe gemacht habe (Otto Normalverbraucher weiß damit mehr anzufangen ) nur Windows.

ich weis ... alles fragen die man eigentlich nicht stellen müsste wenn der launcher von anfang an mit self-update ausgerüstet worden wäre ...

Wird der nächste von mir geschriebene Launcher haben, selbst wenn es nur ein Tetris werden sollte

Zu deinem Hack: Es handelt sich zwar wirklich um einen, aber die Idee finde ich garnicht so schlecht. Das ganze könnte in einem extra Thread passieren und den Nutzer würde garnichts mitbekommen. Je Nachdem wie gut das klappt, bräuchte man nochnicht einmal ein Meldung an den User. Dieser würde garnicht mitbekommen, das es einen Launcher Update gab.

wenn es also nicht möglich ist durch sonst irgendwelche tricks den pfad zum launcher zu bekommen könnte man noch das update-system ändern das der alte launcher beim update-check nicht mehr funktionsfähig ist ... somit kann man user auf eine leider sehr unangenehme art und weise zu einem manuellen update zwingen ...

Die Idee hingegeb finde ich etwas Fragwürdig

Auf alle fälle vielen dank für deine Mühe und Geduld, ich werde mal 'den Hack' umsetzen und gucken
wie es funktioniert.

Vielen Dank

 

[bygones]

sorry nicht alles gelesen, aber schonmal ueberlegt Java Webstart zu nehmen, da ist der update mechanismus schon integriert

 

[Launcher update]

Vielen Dank für deinen Tipp, leider ist das Problem ein anderes.

Viele Grüße

 

[Launcher update]

Ok, ich habe 'den Hack' jetzt umgesetzt und er funktioniert wunderbar.

Er durchläuft alle Laufwerke rekursiv, und schreibt sämtliche exe dateien (die Pfade) in eine List.

Im nächsten Schritt wird dann die Liste durchlaufen, und alle meine Launcher herrausgesucht.
(dazu gucke ich zuerst ob die Größe einigermasen stimmt, dann bilde ich einen Hash-Wert ,ich habe ja Zeit , und wenn es sich um meinen Launcher handelt, schreibe ich ihn wider in eine Liste)

Und im nächsten Schritt werden alle meine Launcher mit Version 2.0 überschrieben. Sollte der Launcher in xyz umbenant worden sein, heist er wider xyz.

Viele Grüße

 

[irgendjemand]

ja ich weis ... es ist nicht gerade super ... vor allem weil es natürlich auch leistung frisst im hintergrund den gesamten rechner nach einer datei abzusuchen ... aber es ist so ziemlich die einzige möglichkeit die ich mir jetzt so praktikabel vorstellen kann ...
das andere wäre höchstens noch das man dem user einen dialog öffnet in dem er dierekt den pfad zum launcher angibt ...

naja ... freut mich aber das du jetzt ne lösung gefunden hast ...

ich hoffe dein neuer launcehr 2.0 ist besser programmiert =D

 

[Paddelpirat]

Ist es nicht leichter den Leuten zu sagen, dass sie eine neue Launcher Version "installieren" sollen?
Also ich als Kunde würde so etwas auf jeden Fall bevorzugen gegenüber einem Programm was meine Festplatte nach exe Dateien durchsucht. Außerdem kann ja auch jemand z.B. so eine exe auf dem Desktop liegen haben und umbenannt haben oder sowas. Dann wird sie gar nicht erkannt.

Und dann halt in der neuen Launcher Version mit Webstart oder so arbeiten.

 

[JohannisderKaeufer]

Boah, dass ist echt übel.

Nein, wirklich, das ist echt übel.

[IRONIE]Und wenn jemand sich die exe per mail zugeschickt hat und nun jedesmal Outlook öffnet um das Programm zu starten?
Durchstöberst du dann auch die emails?
[/IRONIE]


Es gibt Programme, die sollen die Festplatte durchsuchen können, aber irgendein x-beliebiges Programm, das darf von mir aus in seinem Programme-Ordner lesen! (ich meine wirklich nur lesen! und nicht schreiben!) und ansonsten in einem selbst angelegten user.home-Applications-Programmname-Ordner schreiben. Auch noch auf temp, aber das wars dann auch.

Sollte ein Programm so einen Mist versuchen, dann sollte jeder auch nur ansatzweise vernünftige Virenscanner, dass Ding auf den Mond verbannen. Ansonsten solltest du dein Geld zurückverlangen.

Das sich UAC bei solchen Geschichten (Schreiben im Programmverzeichnis) meldet, sollte allerdings klar sein. Selbst unter Windows XP (als nicht Admin-Surfer) dürfte das nicht problemlos gehen.


Ich kann bygones nur beipflichten und sich tatsächlich zu überlegen ob ein Umstieg auf Webstart nicht die vernünftigste Lösung wäre.

Sprich einmalig eine jar herunterladen, die ein Fenster öffnet und den Benutzer ermuntert sich das Ding als Webstart zu installieren.

 

[irgendjemand]

Boah, dass ist echt übel.

Nein, wirklich, das ist echt übel.

[IRONIE]Und wenn jemand sich die exe per mail zugeschickt hat und nun jedesmal Outlook öffnet um das Programm zu starten?
Durchstöberst du dann auch die emails?
[/IRONIE]


Es gibt Programme, die sollen die Festplatte durchsuchen können, aber irgendein x-beliebiges Programm, das darf von mir aus in seinem Programme-Ordner lesen! (ich meine wirklich nur lesen! und nicht schreiben!) und ansonsten in einem selbst angelegten user.home-Applications-Programmname-Ordner schreiben. Auch noch auf temp, aber das wars dann auch.

Sollte ein Programm so einen Mist versuchen, dann sollte jeder auch nur ansatzweise vernünftige Virenscanner, dass Ding auf den Mond verbannen. Ansonsten solltest du dein Geld zurückverlangen.

Das sich UAC bei solchen Geschichten (Schreiben im Programmverzeichnis) meldet, sollte allerdings klar sein. Selbst unter Windows XP (als nicht Admin-Surfer) dürfte das nicht problemlos gehen.


Ich kann bygones nur beipflichten und sich tatsächlich zu überlegen ob ein Umstieg auf Webstart nicht die vernünftigste Lösung wäre.

Sprich einmalig eine jar herunterladen, die ein Fenster öffnet und den Benutzer ermuntert sich das Ding als Webstart zu installieren.

bleib doch erstmal ganz gechillt

1) egal ob unix oder win ... es wird keine benachrichtigung kommen ... java wird lediglich eine exception werfen *welche man einfach unterdrücken kann* ...
wenn java also nicht bewusst mit erhöten rechten gestartet wird ... dann wird es von sich aus auch nicht danach fragen und bei allem wo es dann nun mal keinen zugriff hat eine exception auslösen ...

2) was bitte hat es damit zu tun ob du das file umbennenst ? größe prüfen ... hash bilden ... und fertig ... egal wie das file heißt *wobei wenn man sich schon die mühe macht einen exe-wrapper zu verwenden *hab mir mal jsmooth angesehen ... eig ganz gutes grund-konzept und mehr funktionen als launch4j ... aber : last modified : 2007 ... danke ... aus* sicher kein 0-8-15 **** drauf kommen würde das EXE am ende zu ändern *so fern überhaupt fähig dazu**

3) das mit e-mails halte ich für einen self-pwn ...
ganz erlich : nutzt du überhaupt ein e-mail programm ? und lädst du dir deine mails via POP3 / IMAP runter ... OHNE das eine kopie auf dem server bleibt ? ... nein ? ... naja egal ... diejenigen die sowas machen sind selbst schuld ...
generell : wozu brauche ich ein e-mail programm was meinen rechner mit mails zu müllt , die originale auf dem server löscht ... und dann auch noch verdammt unsicher ist ? ....

ich halte daher die anspielung auf e-mails als übertrieben ... wer sowas macht ist selbst schuld ...
*btw : binär-daten werden in emails nach MIME in Base64 dargestellt ... ergo : müsste man die mail erstmal durch n Base64-decoder laufen lassen um an die "eigentlichen" daten zu kommen*

4) web-start
hmm .. halte ich persönlich für noch dümmer ...
begründung : außer M$ IE ist KEIN browser in der lage java zu laden und zu installieren wenn es nicht vorhanden ist -> ActiveX ...
alle anderen browser müssen ziemlich dumm mit JS in nem loop warten bis der browser das neue plugin als registriert anzeigt ... was meist erst nach nem re-launch verfügbar ist ...
die meisten exe-wraper sind dazu in der lage zu checken ob auf dem system java vorhanden ist ... und ob es in der richtigen mindest-version installiert ist *sogar bis aufs update genau* ... sollte java nicht gefunden werden ... oder die vorhandene version niedriger als die mindest-version ... so wird eine meldung ausgegeben und meist auch gleich im browser eine seite geöffnet *bzw bei jsmooth wenn ichs richtig verstanden habe sogar dierekt runtergeladen* ...

auch kann man einer EXE durch ein entsprechendes manifest UAC ermöglichen ... ohne das man selbstständig "Als Admin Starten" wählen muss ...

außerdem ist web-start in meinen augen nichts weiter als die verlagerung von applets in den applet viewer ... denn es läuft eh alles in einer sand-box ... um das zu umgehen braucht man ein signiertes JAR ...

eine APP hingegen hat keine sand-box und kann mit den user-rechten alles machen ... was in den meisten fällen benötigt wird *schreib-rechte , hardware-zugriff , etc* ...

5) deine persönlich einstellung gegenüber sicherheit
persönlich finde ich eine solche haltung ziemlich affig ... und wie oft musste ich schon lesen : "ich gestatte keinem programm schreibrechte" ...
schön ... dann formatier deine kiste ... reis alle laufwerke raus ... und schmeißt es einzeln von ner brücke ...
ganz erlich ... du erlaubst KEINE programm schreibrechte ... frage : wie kommt dann dein OS auf die platte ? merkste was ? wenn man so "phreaky" ist ... und einer software nicht die rechte gibt die diese braucht um ordentlich zu arbeiten ... dann sollte man diese nicht nutzen ...

beispiel : dein browser hat auch schreib-rechte auf deine platte : cache , verlauf , cookies ... und da kann meist noch ne ganze menge mehr müll bei sein als in ner java app von nem hobby-progger ...

erlich ... was sich manche denken ... und was bringt es am ende : nichts ... leute hört einfach mit dieser kindergartens*****e auf ... es wird langsam lächerlich


@topic
klar wäre es an sich besser den user mit nem dialog zu fragen wo der launcher ist ...
klar wäre es besser am besten alles zu ändern ... und von anfang an richtig zu machen ...
aber kann es sein das die meisten die hier flamen die posts von TO nicht gelesen haben ? *bzw verstanden ?*
TO hat *nach mehrfacher nachfrage* folgendes problem *mal ganz grob zusammengefasst*

TO hat eine app ... welche über einen "externen" launcher gestartet wird ...
dieser launcher verwendet "Runtime.exec()" um unabhängig von der app zu sein ...
auch hat TO gesagt das der launcher leider nicht über eine möglichkeit verfügt diesen selbst zu updaten oder irgendeine verbindung zur restlichen app hat ...
nun die frage : wie updated TO den launcher ?

und die meisten bekommen das einfach nicht auf die reihe ... zu verstehen was TO will ... stattdessen kommen so lustige posts wie : "nimm web-start" ... oder : "mein gott ist das ein s*****t" ... aber erlich : das ist TOTSCHLAG-argumente ...
und erlich : ich wette das JEDER von euch ähnliche fehler gemacht hat ... und daraus genau so lernen musste wie TO ...
also bleibt gechillt und regt euch nich drüber auf was TO mit seiner software macht die eh nur ein paar freunde von ihm nutzen werden ...

 

[Paddelpirat]

Verstanden hat das Problem wohl jeder, aber die vorgeschlagene Lösung auf der gesamten Festplatte nach einer exe oder ähnlichem zu suchen und dabei evtl. noch die Größe und den Hashcode der Datei abzufragen, um auch ja die richtige zu erwischen, ist nun mal dirty ohne Ende.

Die anderen Vorschläge um das Problem anzugehen waren Optionen um das Problem auf eine saubere Art und Weise anzugehen. Das du mit Web Start nichts anfangen kannst ist deine Sache. Fakt ist aber das sich da einige Leute drüber Gedanken gemacht haben und es eigentlich alles bereitstellt, was man zum Deployen eines Java-Programms benötigt inkl. Update Funktion. Wieso es nicht möglich ist dem Kunden zu sagen, dass er seinen Launcher aktualisieren soll wurde leider nicht beantwortet.

 

[Launcher update]

Hallo, es tut mir Leid, dass ich solange nicht geantwortet habe.

Ich denke zu Web Start habe ich schon gesagt, weshalb es nicht GING.

Und zum Dialog: Direkt meine erste Aussage:

Das einzige was mir einfallen würde wäre, in der Jar eine 'Anzeige zu schalten' ala:

'Hey dein Launcher ist nicht mehr aktuell, wenn du hier drauf klickst, kannst du einen aktuellen downloaden.'
Schilder-Duke


Naja, oder so ähnlich.

Würde überlegen dafür den User gar nicht mit zu nerven, sondern einfach das Updater jar file einfach auszutauschen.

Aber ich wollte eigentlich garkeinen Diskussion starten, sondern nur mitteilen, das alles geklappt hat. Der neue Updater kann sich jetzt auch selbst Updaten. Fals es irgendwo noch einen Alten geben sollte, wird dieser eine Meldung schalten

Achja: Das die Lösung häslich ist, weiß ich!

Viele Grüße.