Прерывистый JAR-файл Java Webstart не обновляется

Мы используем java Webstart для развертывания Java-приложения в нашей интрасети. Приложение получает частые обновления. Время от времени пользователь будет запускать приложение со своего значка на рабочем столе после того, как мы обновим JAR / WAR на веб-сервере (временная метка изменена), и Java Webstart запустит старую версию вместо загрузки новой.

Вот вставка нашего JNLP, как вы можете видеть, офлайн-режим включен, но всегда проверять обновления и всегда проверять политику. Кроме того, желает загрузить флаг. Насколько я понимаю, эти параметры всегда должны приводить к проверке кеша по отметке времени на сервере и загрузке файла JAR.

Я начинаю разочаровываться в Webstart! Кто-нибудь видел похожие проблемы? Какие-нибудь решения? Мне надоело проводить людей через очистку кеша веб-запуска вручную при каждом третьем или пятом обновлении.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE jnlp PUBLIC "-//Sun Microsystems, Inc//DTD JNLP Descriptor 6.0//EN" "http://java.sun.com/dtd/JNLP-6.0.dtd">
<jnlp spec="1.0+" codebase="$$codebase" href="$$name">
  <information>
    <title>TITLE</title>

    <vendor>VENDOR</vendor>

    <description>Our Utility Application</description>

    <description kind="short">Our Utility Application PRD</description>
    <icon href="images/util_icon.png" height="64" width="64"/>
    <offline-allowed/>
    <shortcut online="true">
      <desktop />
      <menu submenu="Utility Apps"/>
    </shortcut>
  </information>

  <security>
     <all-permissions />
  </security>

  <update check="always" policy="always" />

  <resources>
    <!-- requires 1.6+ -->
    <j2se version="1.6+" href="http://java.sun.com/products/autodl/j2se" java-vm-args="-ea" initial-heap-size="128m" max-heap-size="512m" />

    <!-- application code, download jar before we start. -->
    <jar href="OurUpdatedJarName.jar" main="true" download="eager" />

    <property name="configfile" value="updatedJarName.config" />
  </resources>

  <application-desc main-class="main.Client">
    <argument>-D</argument> 
  </application-desc>
</jnlp>

person Chris Kannon    schedule 27.01.2010    source источник


Ответы (8)


Возможно, вы решили проблему - но jnlp spec = "1.0+" - элемент поддерживается только после jnlp spec 6.0+. Вероятно, это одна из причин сбоя ваших обновлений.

person luckylak    schedule 14.01.2011

Предполагая, что клиентские JRE обновлены, вы можете попробовать <update check="timeout" policy="always"/>, как предлагается в этом потоке и описано в синтаксисе JNLP документация.

person trashgod    schedule 27.01.2010
comment
@trashgod, вы заметите, что у меня уже есть ‹check update = always policy = always /› в коде. - person Chris Kannon; 27.01.2010
comment
Да, но прерывистый характер проблемы не исключает гипотезу Telcontar. Я не могу не задаться вопросом, может ли тайм-аут или даже фон привести к успешному обновлению. Я также помню, что при переходе на новый сертификат приходилось касаться самого файла .jnlp. - person trashgod; 28.01.2010

У меня были те же проблемы, что и у вас, и я решил их, выполнив следующие действия:

  1. Изменять

    <jar href="OurUpdatedJarName.jar" ...

    to

    <jar href="OurUpdatedJarName-$VERSION.jar" ...

  2. Поместите $ VERSION в <a href="foo-$VERSION.jnlp">Run</a>

Мы автоматически обновляем $ VERSION для каждого развертывания.

Я знаю, что это уродливое решение, но оно работает для нас каждый раз.

person holygeek    schedule 29.11.2010
comment
Похоже, вы не используете более стандартный (согласно спецификации) ... __V {version} .jar и используете флаг JWS versionEnabled? - person Joel; 26.07.2016

Может быть связано с этим сообщением, http://www.coderanch.com/t/528570/JNLP-Web-Start/java/Do-jnlp-file-updates-itself

person thirdy    schedule 14.07.2011

эта проблема вызвана тегом offline-allowed.

Согласно спецификации JNLP

Если указано «разрешено офлайн», Java Web Start также проверяет, доступно ли обновление. Однако, если приложение уже загружено, проверка завершится по таймауту через несколько секунд, и в этом случае вместо этого будет запущено кешированное приложение. При достаточно быстром соединении с сервером обычно запускается последняя версия приложения, но это не гарантируется. Однако приложение можно запустить в автономном режиме.

person Anthony Ho    schedule 22.02.2013

мы распространили java-приложения для запуска веб-приложений в десятке стран, и когда мы обнаружили, что приложение не обновлялось правильно, это было связано с неправильной конфигурацией сети округа или в сетевых настройках пользовательского компьютера, в основном прокси. В наших центральных офисах в испании веб-сайт java всегда работает нормально.

person Telcontar    schedule 27.01.2010
comment
Привет, Telcontar, да, однако без изменений конфигурации это работает с перерывами .. так что это маловероятно, если проблема не связана с прокси-кешем, но тогда при удалении кеша веб-запуска это не решит проблему. - person Chris Kannon; 27.01.2010

Я использовал клон java webstart nextx.jar. Я отследил проблему отсутствия обновления JAR до использования метода URLConnection.getLastUpdated (). Поскольку он использует метод HEAD для получения последнего обновления имени файла, это причина, по которой иногда он не загружается из-за кеширования getLastUpdated (). Мы решили использовать наш собственный метод обновления нашего приложения, поскольку веб-запуск ошибочен.

person Mark Amabile    schedule 01.09.2014

У меня возникла эта проблема только потому, что я не позволил приложению открыться достаточно времени для завершения обновления.

Если у вас есть эта опция: update check = "background" в вашем JNLP, подождите некоторое время, прежде чем закрыть приложение, чтобы позволить завершению обновления (которое выполняется в фоновом режиме).

person martins.tuga    schedule 05.02.2015