Сбой запуска Java WebStart, когда JNLP исправлен на JRE 1.6 и установлена ​​JRE 1.7

В моей компании мы загружаем и запускаем приложение JNLP, привязанное к JRE 1.6.0_20. Мы используем функцию системного кеша для загрузки JAR-файлов.

Когда мы устанавливаем JRE 1.7 на ПК, WebStart не запускается. Когда мы включаем журналы, мы видим следующее исключение:

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

Есть ли известный обходной путь?


java jnlp java-7 java-web-start
person Raghavendra    schedule 06.06.2012    source источник
comment
Вы когда-нибудь находили больше об этом? Кажется, это известная ошибка, и единственным обходным решением, которое я нашел, было удаление Java 7 JRE (хотя я мог бы сохранить JDK для разработки).   -  person haylem    schedule 31.10.2012

Ответы (3)


arrow_upward
1
arrow_downward

Это проблема установки, проблема запуска плагина для нескольких JRE. Переустановите все плагины с обновленной JRE. См. базу данных ошибок

person Mossaddeque Mahmood    schedule 16.12.2012

arrow_upward
1
arrow_downward

Это может не очень хорошо относиться к вашей ситуации, но я нашел решение для нашей проблемы. Я изменил файл JNLP, чтобы указать, какую JRE использовать. В нашем случае файл JNLP имел следующее:

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

И судя по всему, "1.6+" допускает исполнение под 1.7. Поэтому я удалил «+», вот так:

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

И теперь приложение работает нормально. Если вы можете изменить файл JNLP, который обслуживается через URL-адрес вашего приложения, это будет лучше всего. В нашем случае это было невозможно (JNLP поставляется из стороннего программного пакета), поэтому я скачал JNLP, отредактировал его, и теперь мы запускаем приложение, дважды щелкнув измененный файл .jnlp (или запустив 1.6 javaws.exe на нем).

Вот некоторая документация по формату файлов JNLP если вам нужна дополнительная информация.

person S'pht'Kr    schedule 22.04.2013

arrow_upward
0
arrow_downward

В моем случае для решения этой проблемы помогло следующее:

Мне нужно было добавить '*', что означает, что будет выбрана последняя версия 1.6 JRE, найденная на машине. Почему-то просто использовать '1.6' у меня не получилось, а 1.7 продолжала блокировать запуск.

person r.blooberi    schedule 20.01.2014