Можно ли настроить Java Web Start для обновления текущей версии сервера вместо последней?

1

Подводя итог моим исследованиям, кажется, что Java Web Start будет использовать временную метку, предоставленную через веб-сервер, чтобы определить, была ли обновлена определенная банка или нет. На поведение обновления может влиять элемент "обновление" jnlp, в котором элементы "проверяют" и "политику", которые позволяют определить, как часто выполняется проверка обновлений и запрашивается ли пользователю подтверждение обновления или нет.

Однако я не нашел возможности определить другой механизм, кроме сопоставления временной метки, чтобы определить, обновлено ли приложение или нет. На самом деле, сейчас у нас есть дискуссия, если это имеет смысл (для нас), если не самый новый, но текущая версия сервера должна быть загружена клиенту. Это также может быть, например, более старая версия сервера, которая была восстановлена на сервере, потому что ранее активная версия нового сервера была откатна. В случае отката серверного приложения каждый пользователь должен вручную очистить свой Java-кеш в данный момент, что, конечно, возможно, но не очень удобно.

Может ли Java Web Start быть настроен/принудительно всегда загружать версию приложения с сервера, если это "отличается" от локально кэшированной версии?

Теги:
java-web-start

1 ответ

0

Я не согласен, если он точно соответствует вашим потребностям, но взгляните на веб- версию Version Download Protocol.

Подводя итог: с версией загрузки вы можете указать каждую jar-версию, которая будет использоваться в jnlp файле следующим образом:

    <jar href="jackson-core.jar" version="2.0.2" />

и разверните свой jar файл на сервере с именем файла jackson-core__V2.0.2.jar.

С помощью этого протокола webstart будет использовать только jar файлы, версия которых точно соответствует данной версии из jnlp файла. Другим преимуществом является то, что, когда указанная версия уже присутствует в локальном кеше, webstart не будет пытаться загрузить версию снова - независимо от временных меток и т.д.

Преимущества:

  • Полный контроль над версиями, используемыми через jnlp файл.
  • Меньше запросов загрузки для баков, присутствующих в кеше

Недостатки:

  • Новые версии требуют изменения в файле jnlp
  • Не подходит для SNAPSHOT-сборок, поскольку временная метка файла полностью игнорируется, а номера версий не изменяются для SNAPSHOT-сборок.
Поделиться
  • 0
    Большое спасибо за ваш подробный ответ! Я вижу, что в целом это способ принудительной загрузки определенной версии jar, но в нашем случае у нас много клиентов, которые используют «настроенную» версию jnlp. Поэтому мы стараемся максимально сократить количество обязательных изменений в нашем файле jnlp «по умолчанию», чтобы избежать «ручных слияний». Таким образом, в этом случае удаление кэша (или настройка метки времени на сервере) является для нас меньшей проблемой.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню