Java Web Start memorizza sempre nella cache il file JNLP su Windows XP

Question

Nella mia azienda stiamo utilizzando Java Web Start per distribuire il software client ai clienti. Stanno usando diverse versioni di Windows: XP, Vista e 7.

Abbiamo distribuito una versione tramite JWS con problemi minimi in passato. La nostra ultima versione include diverse modifiche ai file, alcuni vasi sono andati, altri sono comparsi, ecc.

Abbiamo scoperto che l'aggiornamento su macchine Windows XP non riesce perché JWS cerca ancora di cercare i file jar che non sono più disponibili sul web server. Ho controllato il registro del mio server HTTP e il file JNLP non è mai accessibile dalle macchine XP durante l'avvio dell'applicazione. Se provo lo stesso su Vista o Windows 7, tutto funziona correttamente, JWS recupera il descrittore JNLP e scarica le differenze quando è disponibile un aggiornamento. Quindi su macchine XP vengono aggiornati solo i file jar conosciuti e JWS genera un errore se non trova qualcosa dal set di file di JNLP memorizzato nella cache.

Ho scritto un servlet che genera manualmente il file JNLP. Sto usando il seguente header config nel mio codice servlet.

response.setDateHeader("Last-Modified", lastModification); 
// IE won't download JNLP file if Cache-Control header presents 
//response.setHeader("Cache-Control", "no-cache, must-revalidate"); 
response.setHeader("Expires", "Mon, 26 Jul 1990 05:00:00 GMT"); 

Questo rende il file JNLP sempre obsoleto che dovrebbe far scattare ricontrollo del file ogni volta che il client viene avviato tramite JWS. Posso anche vedere questa data nel visualizzatore di cache su XP:

ho trovato un problema mai risolvere su questo sul sito bugreport di Oracle: Bug ID: 6189106 appena testato lo stesso con Java7 su Windows XP, ma questo problema esiste ancora. Ma solo su XP a causa dei caratteri di spazio bianco nel percorso della cache di distribuzione ("Documenti e impostazioni" si sa). Qualcuno dice che se cambio il percorso della cache di implementazione in qualcosa che non contiene spazi, risolverà il problema. Beh, non è una soluzione reale perché gli utenti non possono quasi mai scrivere in posizioni diverse dal proprio profilo.

Poiché questo errore esiste per così tanto tempo, credo che ci dovrebbe essere una sorta di soluzione alternativa. Non mi piace dire al cliente ogni volta di svuotare la cache Java e reinstallare l'applicazione dal web. Ci piace passare a un ciclo di rilascio più rapido in futuro che renderà questo ancora più difficile. Spero che qualcuno abbia una buona idea per questo. : |

Answer 1

Il problema è nel percorso del cache del java webstart. Se contiene spazi (che è esattamente il caso in XP), il percorso viene passato in un formato errato a javaws e questo bloccherà il controllo di aggiornamento del file jnlp.

modificare questo percorso in deployment.properties file in questo modo:

deployment.user.cachedir = C \: \ tua \ percorso - questo percorso non deve contenere spazi.

P.S. pulire prima la cache java.

Aggiunto: Il problema sembra essere apparso dopo l'aggiornamento 21.

Answer 2

mi è venuta in mente una soluzione hacky di sorta:

1. mettere un numero di versione nel file JNLP, passandolo come argomento del metodo principale (ad es. <argument>1.0</argument>). In alternativa potresti passare un timestamp esplicito.

2. Controllare a) la proprietà di sistema java.version o javawebstart.version per verificare se l'app è in esecuzione su qualsiasi dispositivo compreso tra 1.6.0_22 e 1.7.0_2 (compreso); e b) controllare la proprietà di sistema deployment.user.cachedir per vedere se contiene spazi. Se a) eb) non sono entrambi veri, probabilmente non è necessario proseguire con i passaggi seguenti, poiché Java Web Start dovrebbe aver controllato il file JNLP per gli aggiornamenti stessi.

3. All'avvio, prima di mostrare qualsiasi modulo, scaricare il file JNLP in memoria (ad esempio utilizzando new URL(jnlpUrlString).openStream() ecc.). Trasmetto l'URL del file JNLP nella mia app come argomento dal file JNLP stesso, come per il numero di versione.

4. Controllare il file JNLP per vedere se contiene il numero di versione passato nel metodo principale (ad esempio una semplice stringa di ricerca per "<argument>" + versionNumberPassedIntoMainMethod + "</argument>"). Se lo fa, sei bravo, dato che stai utilizzando l'ultima versione. In caso contrario, continuare:

5. Salvare il file JNLP nella directory temp (ad esempio utilizzando File.createTempFile(...)).

6. Ottenere il sistema per aprire il file JNLP dalla directory temp, ad es. con java.awt.Desktop.getDesktop().open(jnlpFile) se hai come target Java 1.6+.

7. System.exit(0) per chiudere la versione obsoleta dell'app e consentire a quella aggiornata di prendere il sopravvento.

Ho anche deposito e per controllare l'ultima data-download nel Registro di sistema (utilizzando java.util.prefs.Preferences) per evitare download multipli o ri-apre in rapida successione. L'idea è di ridurre le possibilità di un bug nel mio codice causando qualcosa di troppo brutto come un ciclo infinito di open-check-riaprire-check-riaprire-controllo ecc. E scarico il file JNLP con un timeout in modo che una connessione lenta possa ' t impedire che l'app si apra troppo a lungo. Ma quelli sono solo extra opzionali.

Poiché la mia app funziona con <security><all-permissions/><security/>, non ha problemi a scaricare il file JNLP, salvarlo sul computer e aprirlo con il programma predefinito. Potrebbe essere possibile trovare soluzioni alternative per ognuno di questi passaggi utilizzando la libreria javax.jnlp in modo da non aver bisogno di tutte le autorizzazioni, ma non ne sono troppo sicuro.

Nel complesso per me questo approccio sembra funzionare molto bene. Ma sto ancora sperando in un giorno in cui i bug di Java Web Start come questo sono una cosa del passato, in quanto questo tipo di assurdità hacky in realtà non dovrebbe essere necessario.