Java Web Start siempre almacena en caché el archivo JNLP en Windows XP

Question

En mi empresa utilizamos Java Web Start para distribuir software cliente a los clientes. Están usando diferentes versiones de Windows: XP, Vista y 7.

Implementamos una versión a través de JWS con problemas mínimos en el pasado. Nuestra última versión incluye varios cambios de archivos, algunos archivos se han ido, otros han aparecido, etc.

Descubrimos que la actualización en máquinas con Windows XP falla porque JWS aún intenta buscar archivos jar que ya no están disponibles en la web servidor. Revisé el registro de mi servidor HTTP y nunca se accede al archivo JNLP desde las máquinas con XP durante el inicio de la aplicación. Si intento lo mismo en Vista o Windows 7 todo funciona bien, JWS busca el descriptor JNLP y descarga las diferencias cuando hay una actualización disponible. Por lo tanto, en las máquinas XP solo se actualizan los archivos jar conocidos y JWS arroja un error si no encuentra algo del conjunto de archivos de JNLP en caché.

He escrito un servlet que genera manualmente el archivo JNLP. Estoy usando la siguiente configuración de encabezado en mi código de 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"); 

Esto hace que el archivo JNLP siempre obsoleta que debe desencadenar? Servicios del archivo cada vez que el cliente se inicia a través JWS. Incluso puedo ver a esta fecha en el visor de caché en XP:

He encontrado un problema nunca resolver sobre esto en el sitio informe de error de Oracle: Bug ID: 6189106 acabo de probar lo mismo con Java7 en Windows XP, pero este problema todavía existe. Pero solo en XP debido a los caracteres de espacio en blanco en la ruta de la memoria caché de implementación ("Documentos y configuraciones"). Alguien dice que si cambio la ruta de la memoria caché de implementación a algo que no tenga caracteres de espacio, se solucionará el problema. Bueno, no es una solución real porque los usuarios casi nunca pueden escribir en ubicaciones que no sean su perfil.

Debido a que existe este error durante tanto tiempo, creo que debería haber algún tipo de solución. No me gusta decirle al cliente cada vez que borre la memoria caché de Java y vuelva a instalar la aplicación desde la web. Nos gusta pasar a un ciclo de lanzamiento más rápido en el futuro que hará que esto sea aún peor. Espero que alguien tenga una buena idea para esto. : |

Answer 1

El problema está en el camino al cachedir del webstart java. Si contiene espacios (que es exactamente el caso en XP), entonces la ruta se pasa en un formato incorrecto a los javaws y esto bloqueará la verificación de actualización del archivo jnlp.

cambiar esta ruta en deployment.properties archivo de la siguiente manera:

deployment.user.cachedir = C \: \ su \ ruta - este camino no debe contener espacios.

P.S. limpiar el caché de java antes de eso.

Agregado: El problema parece estar aparecido después de la actualización 21.

Answer 2

he llegado a una solución hacky del tipo:

1. poner un número de versión en el archivo JNLP, pasándole como argumento para su método principal (por ejemplo, <argument>1.0</argument>). Alternativamente, podría pasar una marca de tiempo explícita.

2. Comprobar a) la propiedad o java.versionjavawebstart.version sistema para ver si su aplicación se está ejecutando en cualquier cosa entre 1.6.0_22 y 1.7.0_2 (inclusive); yb) verifique la propiedad del sistema deployment.user.cachedir para ver si tiene espacios. Si a) yb) no son verdaderas, probablemente no tenga sentido continuar con los pasos a continuación, ya que Java Web Start debería haber revisado el archivo JNLP para ver las actualizaciones.

3. Al iniciar, antes de mostrar cualquier formulario, descargue su archivo JNLP en la memoria (por ejemplo, usando new URL(jnlpUrlString).openStream() etc.). Paso la URL del archivo JNLP a mi aplicación como un argumento del archivo JNLP, como para el número de versión.

4. Compruebe el archivo JNLP para ver si contiene el número de versión que se pasó a su método principal (por ejemplo, una búsqueda de cadena simple para "<argument>" + versionNumberPassedIntoMainMethod + "</argument>"). Si lo hace, está bien, ya que está ejecutando la última versión. De lo contrario, continúe:

5. Guarde el archivo JNLP en el directorio temporal (por ejemplo, usando File.createTempFile(...)).

6. Obtenga el sistema para abrir el archivo JNLP desde el directorio temporal, p. con java.awt.Desktop.getDesktop().open(jnlpFile) si tiene como objetivo Java 1.6+.

7. System.exit(0) para cerrar la versión desactualizada de la aplicación y dejar que la actualizada se haga cargo.

También almaceno y verifique la fecha de última descarga en el registro (usando java.util.prefs.Preferences) para evitar descargas múltiples o re-abre en sucesión corta. La idea es reducir las posibilidades de que un error en mi código cause algo demasiado desagradable como un ciclo infinito de open-check-reopen-check-reopen-check, etc. Y descargo el archivo JNLP con un tiempo de espera, por lo que una conexión lenta puede ' t evita que la aplicación se abra demasiado tiempo. Pero esos son solo extras opcionales.

Como mi aplicación se ejecuta con <security><all-permissions/><security/>, no tiene problemas para descargar el archivo JNLP, guardarlo en la computadora y abrirlo con el programa predeterminado. Podría ser posible encontrar soluciones para cada uno de esos pasos utilizando la biblioteca javax.jnlp para que no necesitara todos los permisos, pero no estoy muy seguro de eso.

En general, este enfoque parece estar funcionando muy bien. Pero todavía espero un día en que los errores de Java Web Start como este sean cosa del pasado, ya que este tipo de tonterías hacky realmente no deberían ser necesarias.