Java Web Start всегда кэширует файл JNLP в Windows XP

Question

В моей компании мы используем Java Web Start для распространения клиентского программного обеспечения.Они используют разные версии Windows: XP, Vista и 7.

Мы развернули версию через JWS с минимальными проблемами в прошлом.Наш последний выпуск включает в себя несколько изменений файлов, некоторые файлы jar пропали, другие появились и т. Д.

Мы обнаружили, что обновление на компьютерах под управлением Windows XP не выполняется, поскольку JWS все еще пытается найти файлы jar, которые больше не доступны навеб-сервер.Я проверил журнал моего HTTP-сервера, и JNLP-файл никогда не будет доступен с компьютеров XP при запуске приложения.Если я пытаюсь сделать то же самое в Vista или Windows 7, все работает нормально, JWS выбирает дескриптор JNLP и загружает различия, когда доступно обновление.Таким образом, на машинах XP обновляются только известные jar-файлы, и JWS выдает ошибку, если не находит что-либо из набора файлов кэшированного JNLP.

Я написал сервлет, который вручную генерирует файл JNLP.Я использую следующую конфигурацию заголовка в своем коде сервлета:

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");

Это делает файл JNLP всегда устаревшим, что должно вызывать перепроверку файла каждый раз, когда клиент запускается через JWS.Я даже вижу эту дату в средстве просмотра кэша в XP:

На сайте отчетов об ошибках Oracle я никогда не решал эту проблему: Идентификатор ошибки: 6189106 Только что протестировал то же самое с Java7 на Windows XP, но эта проблема все еще существует.Но только в XP из-за пробелов в пути кеша развертывания («Документы и настройки», вы знаете).Там кто-то говорит, что если я изменю путь кеша развертывания на что-то без пробелов, это решит проблему.Ну, это нереальное решение, потому что пользователи вряд ли когда-либо смогут писать в места, отличные от их профиля.

Поскольку эта ошибка существует в течение столь длительного времени, я думаю, что должен быть какой-то обходной путь.Я не люблю каждый раз рассказывать клиенту, чтобы он очищал кеш Java и переустанавливал приложение из Интернета.Мы хотели бы перейти к более быстрому циклу выпуска в будущем, который сделает это еще хуже.Я надеюсь, у кого-то есть хорошая идея для этого.: |

Answer 1

Я придумал какое-то хакерское решение:

1. Поместите номер версии в свой файл JNLP, передав его в качестве аргумента вашему основному методу (например, <argument>1.0</argument>). В качестве альтернативы вы можете передать явную метку времени.

2. Проверьте a) системное свойство java.version или javawebstart.version, чтобы увидеть, работает ли ваше приложение в диапазоне от 1.6.0_22 до 1.7.0_2 (включительно); и b) проверьте системное свойство deployment.user.cachedir, чтобы увидеть, есть ли в нем пробелы. Если a) и b) оба не верны, вероятно, нет смысла продолжать выполнение описанных ниже шагов, поскольку Java Web Start должен был проверить сам файл JNLP на наличие обновлений.

3. При запуске, прежде чем показывать какие-либо формы, загрузите файл JNLP в память (например, используя new URL(jnlpUrlString).openStream() и т. Д.). Я передаю URL-адрес файла JNLP в свое приложение в качестве аргумента самого файла JNLP, например, для номера версии.

4. Проверьте файл JNLP, чтобы увидеть, содержит ли он номер версии, который был передан в ваш основной метод (например, простой поиск строки для "<argument>" + versionNumberPassedIntoMainMethod + "</argument>"). Если это произойдет, вы хорошо, так как вы используете последнюю версию. Если нет, продолжайте:

5. Сохраните файл JNLP во временном каталоге (например, используя File.createTempFile(...)).

6. Получите, чтобы система открыла файл JNLP из временного каталога, например, с java.awt.Desktop.getDesktop().open(jnlpFile), если вы нацелены на Java 1.6 +.

7. System.exit(0), чтобы закрыть устаревшую версию приложения и позволить обновленной версии вступить во владение.

Я также храню и проверяю дату последней загрузки в реестре (используя java.util.prefs.Preferences), чтобы предотвратить многократные загрузки или повторное открытие в короткие сроки. Идея состоит в том, чтобы уменьшить вероятность ошибки в моем коде, вызывающей нечто слишком неприятное, например бесконечный цикл open-check-reopen-check-reopen-check и т. Д. И я загружаю файл JNLP с тайм-аутом, чтобы медленное соединение могло ' не позволяет приложению открываться слишком долго. Но это просто дополнительные функции.

Поскольку мое приложение работает с <security><all-permissions/><security/>, у него нет проблем с загрузкой файла JNLP, сохранением его на компьютер и открытием с помощью программы по умолчанию. Возможно, можно найти обходные пути для каждого из этих шагов, используя библиотеку javax.jnlp, поэтому вам не нужны все разрешения, но я не слишком уверен в этом.

В целом мне кажется, что этот подход работает очень хорошо. Но я все еще надеюсь на день, когда такие ошибки Java Web Start уйдут в прошлое, так как подобная хакерская ерунда действительно не обязательна.

Answer 2

Проблема заключается в пути к кеширу веб-старта Java. Если он содержит пробелы (что в точности относится к XP), то путь передается в неверный формат javaws, и это блокирует проверку обновления файла jnlp.

Измените этот путь в файле deploy.properties следующим образом:

deploy.user.cachedir = C \: \ your \ path - этот путь не должен содержать пробелов.

P.S. очистите кеш Java до этого.

Добавлено: Кажется, проблема появилась после обновления 21.