Java Web Start speichert die JNLP-Datei immer unter Windows XP
In meinem Unternehmen verwenden wir Java Web Start, um Client-Software an die Kunden zu verteilen. Sie verwenden verschiedene Windows-Versionen: XP, Vista und 7.
Wir haben eine Version über JWS mit minimalen Problemen in der Vergangenheit bereitgestellt. Unsere neueste Version enthält mehrere Dateiänderungen, einige Gläser sind weg, andere erschienen, etc.
Wir haben festgestellt, dass das Upgrade auf Windows XP-Rechnern fehlschlägt, weil JWS immer noch versucht, JAR-Dateien nachzuschlagen, die auf dem Webserver nicht mehr verfügbar sind. Ich habe das Protokoll meines HTTP-Servers überprüft, und die JNLP-Datei wird während des Anwendungsstarts niemals von XP-Maschinen aus aufgerufen. Wenn ich das gleiche unter Vista oder Windows 7 versuche, funktioniert alles einwandfrei, JWS holt den JNLP-Deskriptor und lädt die Unterschiede herunter, wenn ein Update verfügbar ist. Auf XP-Rechnern werden nur die bekannten JAR-Dateien aktualisiert, und JWS gibt einen Fehler aus, wenn in der zwischengespeicherten JNLP-Dateigruppe kein Fehler gefunden wird.
Ich habe ein Servlet geschrieben, das die JNLP-Datei manuell generiert. Ich benutze die folgende Header-Konfiguration in meinem Servlet-Code.
%Vor%Dies bewirkt, dass die JNLP-Datei immer veraltet ist, was jedes Mal, wenn der Client durch JWS gestartet wird, eine erneute Prüfung der Datei auslösen sollte. Ich kann dieses Datum sogar im Cache-Viewer unter XP sehen:
Ich habe auf der Bugreport-Website von Oracle ein Problem gefunden, dass sich niemals löst: Bug-ID: 6189106 Habe das gleiche mit Java7 unter Windows XP getestet, aber dieses Problem besteht immer noch. Aber nur unter XP wegen der Leerzeichen im Pfad des Deployment-Caches ("Dokumente und Einstellungen"). Jemand sagt dort, dass wenn ich den Pfad des Deployment-Caches zu etwas ändere, in dem keine Leerzeichen enthalten sind, wird es das Problem lösen. Nun, es ist keine wirkliche Lösung, weil Benutzer kaum an Orte schreiben können, die nicht ihr Profil sind.
Da dieser Fehler so lange existiert, sollte es eine Art Workaround geben. Ich möchte dem Kunden nicht jedes Mal sagen, dass er den Java-Cache löschen und die Anwendung aus dem Internet neu installieren soll. Wir möchten in Zukunft auf einen schnelleren Release-Zyklus umstellen, der dies noch verschlimmern wird. Ich hoffe, dass jemand eine gute Idee dafür hat. : |
2 Antworten
Das Problem liegt im Pfad zum Cachedir des Java-Webstarts. Wenn es Leerzeichen enthält (das ist genau der Fall in XP), wird der Pfad in einem falschen Format an die Java-Dateien übergeben und dies wird die Aktualisierungsprüfung der jnlp-Datei blockieren.
Ändern Sie diesen Pfad in der Datei deployment.properties wie folgt:
deployment.user.cachedir = C \: \ Ihr \ Pfad - Dieser Pfad darf keine Leerzeichen enthalten.
P.S. säubere vorher den Java Cache.
Hinzugefügt: Das Problem scheint nach Update 21 aufgetreten zu sein.
Ich habe eine Art Hacky-Lösung gefunden:
-
Fügen Sie eine Versionsnummer in Ihre JNLP-Datei ein und übergeben Sie sie als Argument an Ihre Hauptmethode (z. B.
<argument>1.0</argument>). Alternativ könnten Sie einen expliziten Zeitstempel übergeben. -
Überprüfen Sie a) die Systemeigenschaft
java.versionoderjavawebstart.version, um zu sehen, ob Ihre App zwischen 1.6.0_22 und 1.7.0_2 (einschließlich) läuft; und b) überprüfen Sie die Systemeigenschaftdeployment.user.cachedir, um festzustellen, ob darin Leerzeichen enthalten sind. Wenn a) und b) nicht beide wahr sind, ist es wahrscheinlich nicht sinnvoll, die folgenden Schritte auszuführen, da Java Web Start die JNLP-Datei selbst auf Aktualisierungen überprüft haben sollte. -
Laden Sie Ihre JNLP-Datei beim Start vor dem Anzeigen von Formularen in den Speicher (z. B. mit
new URL(jnlpUrlString).openStream()usw.). Ich übergebe die URL der JNLP-Datei in meiner App als Argument aus der JNLP-Datei selbst, wie für die Versionsnummer. -
Überprüfen Sie die JNLP-Datei, um festzustellen, ob sie die Versionsnummer enthält, die an Ihre Hauptmethode übergeben wurde (z. B. eine einfache Suche nach
"<argument>" + versionNumberPassedIntoMainMethod + "</argument>"). Wenn dies der Fall ist, sind Sie gut, da Sie die neueste Version ausführen. Wenn nicht, fahren Sie fort: -
Speichern Sie die JNLP-Datei im temporären Verzeichnis (z. B. mit
File.createTempFile(...)). -
Lassen Sie das System die JNLP-Datei aus dem temporären Verzeichnis öffnen, z. mit
java.awt.Desktop.getDesktop().open(jnlpFile), wenn Sie auf Java 1.6 + abzielen. -
System.exit(0), um die veraltete Version der App zu schließen und die aktualisierte Version übernehmen zu lassen.
Ich speichere und überprüfe auch das Datum des letzten Downloads in der Registry (mit java.util.prefs.Preferences ), um mehrfache Downloads zu verhindern oder in kurzer Folge wieder zu öffnen. Die Idee ist, die Wahrscheinlichkeit eines Fehlers in meinem Code zu reduzieren, der etwas zu Unangenehmes wie eine Endlosschleife von Open-Check-Reopen-Check-Reopen-Check etc. verursacht. Und ich lade die JNLP-Datei mit einem Timeout herunter, so dass eine langsame Verbindung ' t verhindern, dass die App zu lange geöffnet wird. Aber das sind nur optionale Extras.
Da meine App mit <security><all-permissions/><security/> läuft, hat sie keine Probleme, die JNLP-Datei herunterzuladen, sie auf dem Computer zu speichern und sie mit dem Standardprogramm zu öffnen. Es könnte möglich sein, Workarounds für jeden dieser Schritte mithilfe der Bibliothek javax.jnlp zu finden, sodass Sie nicht alle Berechtigungen benötigen, aber ich bin mir nicht sicher.
Insgesamt scheint mir dieser Ansatz sehr gut zu funktionieren. Aber ich hoffe immer noch auf einen Tag, an dem Java Web Start Fehler wie diese der Vergangenheit angehören, da diese Art von hacky Unsinn wirklich nicht notwendig sein sollte.
Tags und Links java java-web-start distribution