El inicio de Java WebStart falla cuando se arregla un JNLP en JRE 1.6 y se instala JRE 1.7

Question

En mi empresa, descargo y lanzo una aplicación JNLP que está vinculada a un JRE 1.6.0_20. Usamos la función de caché del sistema para descargar los JAR.

Cuando instalamos un JRE 1.7 en la PC, WebStart no se inicia. Cuando habilitamos los registros, vemos la siguiente excepción:

java.lang.ExceptionInInitializerError 
    at com.sun.deploy.net.protocol.https.Handler.openConnection(Unknown Source) 
    at java.net.URL.openConnection(Unknown Source) 
    at com.sun.deploy.net.BasicHttpRequest.createUrlConnection(Unknown Source) 
    at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source) 
    at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source) 
    at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source) 
    at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source) 
    at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source) 
    at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source) 
    at com.sun.deploy.net.DownloadEngine.getCachedFile(Unknown Source) 
    at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source) 
    at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source) 
    at com.sun.javaws.Main.launchApp(Unknown Source) 
    at com.sun.javaws.Main.continueInSecureThread(Unknown Source) 
    at com.sun.javaws.Main$1.run(Unknown Source) 
    at java.lang.Thread.run(Unknown Source) 
Caused by: java.lang.ClassCastException: sun.security.ssl.X509TrustManagerImpl cannot be ast to com.sun.net.ssl.internal.ssl.X509ExtendedTrustManager 
    at com.sun.deploy.security.X509ExtendedDeployTrustManager.<init>(Unknown Source) 
    at com.sun.deploy.net.protocol.https.Handler$Initializer$1.run(Unknown Source) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at com.sun.deploy.net.protocol.https.Handler$Initializer.<clinit>(Unknown Source) 
... 16 more 

¿Existe una solución conocida?

Answer 1

Este es un problema de instalación, problema de inicio del complemento para JRE múltiple. Reinstale todo el complemento con JRE actualizado. See bug database

Answer 2

Esto puede no aplicarse bien a su situación, pero encontré una solución para esto para nuestro problema. Modifiqué el archivo JNLP para especificar qué JRE usar. En nuestro caso, el archivo JNLP tenía el siguiente:

<j2se java-vm-args="-Xmx512m -Dsun.java2d.noddraw=true" version="1.6+"/> 

Y al parecer, el "1.6+" permite la ejecución bajo 1.7. Así que me quité el "+", así:

<j2se java-vm-args="-Xmx512m -Dsun.java2d.noddraw=true" version="1.6"/> 

Y ahora la aplicación funciona bien. Si puede cambiar el archivo JNLP que se sirve a través de la URL de su aplicación, sería lo mejor. En nuestro caso, esa no era una opción (el JNLP proviene de un paquete de software de un tercero), así que descargué el JNLP, lo edité y ahora lanzamos la aplicación haciendo doble clic en el archivo .jnlp modificado (o ejecutando el 1.6 javaws.exe en él).

Aquí está some documentation on the JNLP file format si necesita más información.

Answer 3

En mi caso, la siguiente trabajaron para resolver este problema -

que necesitaba para añadir el '*', lo que implica que el último JRE 1.6 encontrado en la máquina va a ser recogido. Por alguna razón, simplemente usar '1.6' no funcionó para mí, y 1.7 continuó bloqueando el lanzamiento.