Webstart Kopierte Verknüpfungen

[inv_zim]

Hallo,

wir haben in unserer Firma angefangen, Software über Webstart zu verteilen (z.Z. ein kleineres Programm, ein Telefonbuch). Ein Kollege von mir hat es sogar geschafft, die Software über Baramundi zu verteilen, aber das dürfte keinen Einfluss auf die Funktion haben. Es wird ein Desktop-Icon angelegt.

Jetzt habe ich letzte Woche Version 2 verteilt, mit großen Änderungen, der Code wurde von Grund auf neu geschrieben. Die Dateien auf dem Server wurden ausgetauscht, der Link auf die JNLP blieb der selbe.

Der erste Programmaufruf der Nutzer verlief wirklich gut, sie klickten auf ihr Icon, oder das Programm lag im Autostart, es wurde neu heruntergeladen, installiert, und es lief. In den nächsten Tagen lief aber mein Telefon heiß, da Webstart sich wohl einen neuen Cache für die Software anlegte. Das Desktop-Icon wurde neu angelegt, ebenso der Eintrag im Startmenü, aber kopierte Verknüpfungen (z.B. in der Taskleiste oder im Autostart) zeigten immer noch auf den alten Cache.

Wann wird bei Webstart ein neuer lokaler Cache angelegt? Dass die Verknüpfungen nicht mit aktualisiert werden ist ja vollkommen logisch (naja, für die Anwender war es das nicht), aber ich habe seitdem noch ein paar kleinere Änderungen eingespielt, und die waren allesamt erfolgreich und problemlos, kein neuer Cache.

Gruß,

Tim

 

[inv_zim]

Ich habe mal ein wenig die Oracle Dokumentation gewälzt. Folgendes konnte ich rausziehen:

• Eine Anwendung wird durch die URL zur JNLP Datei identifiziert
• Wenn es keine URL zur JNLP gibt, zählt die URL zum Haupt-Jar
• Wenn mehrere Anwendungen die selbe Haupt JAR verwenden, muss eine URL zum JNLP existieren

Immerhin mal ein Anfang. Schön und gut, das Desktop Icon wurde von Webstart auch immer wieder schön überschrieben, das heißt wohl dass er die verschiedenen Versionen wirklich als eine Anwendung erkennt. Aber auf die Caching Strategien geht die Doku leider nicht ein, so technisch wird es nicht.

 

[hansmueller]

Hallo,

die Software über Baramundi zu verteilen

Was soll den das werden? Ich kenne zwar Baramundi nicht, aber ich denke nicht, daß das gut mit WebStart zusammenarbeitet.

Normalerweise geht das mit WebStart so:
Man legt die JNLP-Datei zusammen mit den Programmdateien auf einen WebServer.
Der Anwender bekommt nur einen Link zu der JNLP-Datei.
Wenn der Anwender auf den Link klickt, sollte die JNLP-Datei heruntergeladen und mit dem WebStartLauncher (javaws.exe) gestartet werden.
WebStart ließt die JNLP aus und lädt vom WebServer alle benötigten Dateien auf den Clientrechner. Diese werden in einem eigenen Cache für Java abgespeichert. (Kann man über das Java Control Panel oder über die Property-Dateien einstellen.)

WebStart überprüft bei jedem Programmstart, ob es aktuellere Programmdateien auf dem Server gibt, als die auf dem Anwenderrechner. Sollte dies der Fall sein, werden die neuen Dateien (je nach Einstellung in der JNLP-Datei) heruntergeladen und verwendet.

Bei älteren JRE-Versionen kann es zu Problemen führen, wenn man die JNLP-Datei ändert. Teilweise besteht dieses Problem immer noch. Z. B. wird die JNLP-Datei bei einem Start über die Desktop-Verknüpfung (welche von WebStart angelegt wurde) nicht aktualisiert, d. h. man benutzt in diesem Fall immer die alte Version der JNLP-Datei. Wenn man es aber über einen Link zur JNLP-Datei startet, wird diese aktualisiert. Auch das nachträgliche Einfügen von Resourcen macht oft Probleme.
Über den Java Cache Viewer kann man sich die JNLP-Datei anschauen, die der Client momentan verwendet.

Wenn die Anwender auf Ihren Rechner eine aktuelle Version der JRE haben und die Verknüpfungen mit Hilfe von WebStart erstellt wurden (also über z. B. den Java Cache Viewer oder über die Einstellungen in der JNLP-Datei und nicht irgendwie händisch) dann sollte es eigendlich ausreichen, wenn die Anwender das Programm einmal über den Link zur JNLP-Datei starten und nicht über die Verknüpfung.

Im Netz habe ich mal das hier gefunden: Do jnlp file updates itself (JNLP and Web Start forum at JavaRanch)
Irgendwo habe ich mal gelesen, daß jemand dieses Problem umgangen hat, in dem er bei allen Anwendern den Cache auf einen Pfad ohne Leerzeichen gelegt hat. Diese Cache-Änderung wurde bei allen Anwendern irgendwie automatisch vorgenommen (frag mich jetzt nicht wie, ist mehr so eine Admin-Sache).

Ich hoffe die Infos helfen dir.

MfG
hansmueller

 

[inv_zim]

Hi,

ich glaube, da hast du ein wenig an mir vorbeigelesen. Vielleicht habe ich mich auch nicht klar ausgedrückt, will ich nicht ausschließen.
die Funktion von Webstart ist mir durchaus bekannt, auch wie man es installiert, und die Strategien dazu. Die Installation über Baramundi "simuliert" dieses Verhalten, das Programm wird ordnungsgemäß installiert. Natürlich liegt das ganze auch bei uns auf einem Webserver. Dieser Weg ist nur einfacher als 300 unbedarften Anwendern zu sagen, sie sollen jetzt auf diesen Link klicken, dann auf Öffnen, dann den Haken bei der Sicherheitswarnung setzen und auf okay klicken... Auf einmal war das Desktop-Icon da, und es war gut.

Die verwendete JRE ist aktuell, und die mit Webstart erzeugten Verknüpfungen sind nicht das Problem. Das Problem ist einfach, dass die Anwender sich die Verknüpfungen in den Autostart schieben, und diese natürlich von Webstart nicht ausgetauscht werden können, und dann irgendwann auf einen veralteten Cache zeigen. Darum wollte ich verstehen, wann Webstart es für nötig hält Dateien neu zu cachen.

Gruß und danke,

Tim

 

[hansmueller]

Ach so...
Nach meinen Erfahrung wird die Verlinkung nur geändert, wenn die JNLP-Datei geändert wird.
Wenn einfach nur neuere Jars hochgeladen werden, ändert sich da glaube ich nichts.

Ich wüßte jetzt auch nicht, wie man dieses Cache-Verhalten von WebStart beeinflussen könnte. Besonderst bezogen auf die JNLP-Datei.

Es ist vielleicht etwas weit hergeholt, aber... ich weiß, das es da einige "freie" WebStart-Launcher gibt. Vielleicht kannst du mit Hilfe von so einem Launcher das Cache-Verhalten besser steuern. Der Oracle-Launcher versteckt ja die Dateien vor dem Anwender. Und ich schätze mal, das genau diese Versteckaktion zu diesem Problem führt. In den ersten Versionen soll das nicht der Fall gewesen sein.

Mit diesem Baramundi sollte es auch leicht sein, dafür zu sorgen, das bei allen Anwendern für WebStart-Programme nur noch der "freie" WebStart-Launcher verwendet wird. (Natürlich nur, wenn du einen findest, der das so macht, wie du willst.

MfG
hansmueller

 

[inv_zim]

Hm, gestern abend hatte ich das Main-Jar "<Programmname>-2.0.1.jar" gegen "<Programmname>-2.0.2.jar" getauscht -> Neuer Cache, Anrufe, verwirrte Anrufe, grande drama und Verderben

Ich schaue mir das mit den "freien" Launchern mal an, danke für den Tipp! Wusste gar nicht, dass es sowas gibt.

 

[hansmueller]

Benutzt du die Versionierung von WebStart (sieht eher nicht so aus) oder hast du die JNLP-Datei bzgl. der Versionsnummer geändert?

Für die Launcher habe ich folgende Links:
OpenJNLP | Free software downloads at SourceForge.net
Netx - NETwork eXecute

Ich habe das Zeugs noch nie verwendet. Würde mich aber schon interessieren, wie die Teile sich verhalten.

MfG
hansmueller

 

[tuxedo]

Ja, das mit Webstart ist eine verzwickte Sache. Bei uns gibt's das gleiche Problem. Wir haben das wie folgt gelöst (nicht schön, aber war schnell realisiert und funktioniert):

Wir haben ein Java-Anwendung gebastelt die sich die Software als ZIP vom Webserver zieht, die ZIP entpackt und die Daten auf der Platte gegen die neuen austauscht. und schließlich die eigentliche Anwendung startet. Die Links sind fest auf die auf der Platte liegende Anwendung eingestellt.

Per Webstart wird nur noch diese Java-Anwendung gestartet.

Hat natürlich den Nachteil dass der Webstart-Update-Mechanismus umgangen wird. Und da unsere "Installer-Anwendung" nicht sonderlich schlau ist, wird bei einem Update immer alles vom Server gezogen.

Alles in allem: Ich fänd's schöner wenn die Sortcuts auf dem Desktop und im Menü nicht auf einen Cache-Eintrag zeigen würden, sondern immer auf ein und dieselbe Location. Erst beim start kann Webstart dann ja checken ob nicht doch schon eine aktuelle Version der Anwendung lokal gecached ist und diese nutzen, oder eben im Update-Fall die lokale JNLP ersetzen und den Cache erneuern. Aber warum immer alles neu angelegt wird und auf eine neue Location zeigen muss ist mir schleierhaft.

Bei Ubuntu hat das bei mir sogar zur Folge, dass den Shortcut auf dem Desktop nach einem Update nicht mehr ausführbar ist. Ich muss erst wieder das executeable flag setzen... sehr lästig.

- Alex

 

[inv_zim]

Benutzt du die Versionierung von WebStart (sieht eher nicht so aus) oder hast du die JNLP-Datei bzgl. der Versionsnummer geändert?

Tatsache, das Versionsflag ist gar nicht gesetzt. Könnte helfen :autsch:

Ich werde mal schaun, ob ich hier mal Zeit habe in OpenJNLP reinzusehen. Da die Software aber noch in 17 Tochterfirmen zum Einsatz kommt, wäre mir eine Lösung mit dem Standard-Webstart doch deutlich lieber

Danke euch beiden, das hat mir schonmal geholfen!

 

[inv_zim]

Nachtrag: OpenJNLP ist wohl seit längerem tot, Netx noch nicht ganz so lange.