Замена java web start

Как мы мигрировали с Oracle JDK и Java Web Start на AdoptOpenJDK и OpenWebStart 11.02.2020 11:03

Меня зовут Ильдар и работаю я в одной немецкой компании, которая как и многие немецкие компании использует старый стек технологий и пытается мигрировать на стек поновее.

Проблема

Начну с описания проблемы. В нашей компании есть важнейшая часть системы, которая представляет из себя legacy-приложение, написанное на java 6 и частично на java 8. Запускалось оно на java 8. Чтобы использовать это приложение на production пользователи скачивают с сайта jnlp-файл и запускают его у себя на компьютерах.

Так компания долго и счастливо существовала, пока Oracle не объявила о прекращении поддержки 8й версии java, не пометила технологию Java Web Start как deprecated и вовсе решила выпилить ее начиная с java 11. Это значило, что JWS-приложения, коих все еще немало, больше не будут получать в том числе обновлений безопасности. С этим, конечно же, мало кто может смириться. Так же подумали энтузиасты из компании Karakun решили написать свою замену для JWS.

В нашей же компании некоторое время назад начали переписывать приложение, используя Spring boot для бекэнда и React для фронтэнда, но процесс не быстрый, а обновлений нет уже сейчас.

Поиск решения

Итак перед командой разработки встал вопрос о поиске альтернативных решений. Вообще стоит признать, что решение проблемы есть и не одно. Изначально архитекторы отобрали два решения GetDown и тот самый OpenWebStart. На момент принятия первоначального решения выбор пал на первый вариант, так как OpenWebStart еще даже не был зарелизен под первой версией (были только какие-то наработки и планы).

У каждого из решений были свои плюсы и минусы, но компания решила не ждать релиза OpenWebStart и начать реализовывать proof of concept на базе GetDown.

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

Тем временем прилетели другие срочные задачи и команда разработки отвлеклась от перехода со стадии PoC к полноценной реализации замены Java Web Start.

Сроки поджали

Все жили счастливо, пока менеджмент не осознал, что пришло время уже заканчивать и с заменой Java Web Start. До этого момента я не занимался этим проектом, но тут меня тоже подключили.
Сначала я решил поискать информацию о вариантах решения нашей проблемы еще раз. Так скажем вникнуть в решение с нуля. Таким образом я для себя открыл существование OpenWebStart. Протестировал у себя локально, столкнулся с некоторыми проблемами (потом мы столкнулись еще и с другими) и решил их. В итоге решение понравилось всем. Нужно ли говорить о том, что особенно оно понравилось менеджменту тем, что не нужно будет тратить времени на разработку как в случае с GetDown. Но в итоге время мы потратили на то, чтобы заставить работать нашу систему с OpenWebStart.

Краткая информация об OpenWebStart

OpenWebStart основан на другой реализации Java Web Start — IcedTea-Web и JNLP-спецификации JSR-56. На момент написания статьи проект существует в версии 1.1.4 и планирует реализовать в себе основные фичи Java Web Start (за прогрессом можно наблюдать тут).
Перечислять все возможные настройки не вижу смысла, это может занять очень долго.

Вот лишь некоторые из них:

• управление кэшем (размерами, местоположением…),
• настройки безопасности (разрешение пользователям запускать не подписанное сертификатами приложение, показывать или нет предупреждающие попапы…),
• добавлять адреса серверов в белый список,
• настройки удаленного дебага,
• управление сертификатами безопасности,
• управление версиями JRE/JDK,
• и другие

Особенности использования OpenWebStart и проблемы, с которыми мы столкнулись

Установка OpenWebStart

Установить OpenWebStart довольно просто. Достаточно на сайте скачать установочный файл для вашей платформы и следовать инструкциям установщика.

Но вот незадача. В нашем случае пользователями являются около 10000 клиентов, на каждый из которых служба поддержки нашей компании должна установить этот инструмент. Решение нашлось довольно быстро: доступна так называемая фоновая установка.

Нужно закинуть установочный файл на каждый из компьютеров и запустить специальную команду (а для этого у компании уже есть инструмент):

OpenWebStart_windows_Setup.exe -q -varfile response.varfile 

, где response.varfile — файл с некоторыми настройками, которые заранее можно задать установщику. Например, папка, в которую установить OpenWebStart, и некоторые другие.

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

Мы же в настройках обнаружили, что можно указать URL, с которого OpenWebStart будет брать файл настроек, в котором можно указать URL на нужную нам JRE. А сам URL с файлом настроек можно указать в упомянутом выше response.varfile (вот так все сложно).

Сам JSON-файл настроек с разными версиями JRE выглядит следующим образом.

В настройках так же можно задать версию и вендора JRE, на случай если в JSON файле указано несколько JRE. Мы же указали только один и залили JSON файл и архив с нужным нам JRE на Amazon S3 bucket.

Протестировав мы обнаружили, что с версией JRE, загруженной нами, приложение не стартует… Оказалось, что у нашей джавы немного другая структура в архиве. Мы на скорую руку написали batch-скрипт, который перестраивал структуру JRE архива.

«Ну вот теперь все прекрасно заработает», — подумали мы.

При первом запуске приложения автоматически загружается JRE, который и используется в дальнейшем. Но, нас ждал следующий сюрприз.

Беда не приходит одна

Но как это обычно бывает одной проблемой мы не ограничились.

У нашего приложения есть, скажем так, одна особенность. На самом деле их два. Одно приложение (один jnlp файл) запускает из себя второе приложение (второй jnlp). И вот в этом случае второе приложение не стартовало. В логах можно было увидеть, что приложения застревают в дедлоке. Из стектрейса стало понятно, что причиной служит внутренний механизм логгирования OpenWebStart.

Проблема решилась отключением внутреннего логгирования OpenWebStart. Логи наших приложений разумеется остались включенными.

Эти настройки так же получилось отключить в response.varfile файле, который используется при фоновой установке.

И вот после преодоления этих и немного других препятствий (всех уже и не упомнить), нам удалось запустить наше приложение, которое сейчас проходит тестирование перед релизом в прод. По мере нашего тестирования версия OpenWebStart обновилась с 1.1.1 до 1.1.4. Из заметных изменений была добавлена возможность дебажить удаленно.

Возможно, моя статья будет кому-то полезна в таком нелегком труде как поддержка legacy-приложений. Если будут вопросы — спрашивайте, постараюсь ответить.

P.S. все изображения взяты с официального сайта OpenWebStart.

Источник

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Replacement for Java Web Start

License

alex73/MiniWebStart

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Sign In Required

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

This is replacement for Java Web Start since Oracle deprecated it.

MiniWebStart doesn’t work as part of browser, but was created for simplify software installation and updates on the end-user desktops.

This application also improves some things that was not so good in the Java Web Start:

• It works not only with Java applications, but can handle any applications, even non-application files.
• It doesn’t require to use only installed java on the client computer, but can be used for distribute java as part of your application. That means, you don’t need to update java manually on the all client computers.
• It doesn’t require jars signing — it’s just an optional thing. Probably, certificate of your https server will be enough for validate application on the user side.

The main work principles are almost the same as in Java Web Start:

1. You need to compile your application for each client platform
2. Need to create some deployment description(like jnlp file)
3. Send MiniWebStart to the clients
4. Client will just run MiniWebStart, then MiniWebStart will download/update/start files as described in deployment descriptor

MiniWebStart is just a one executable file and don’t need any installation. Client should just run it with some parameters, like deployment description URL. Developer can build own version of MiniWebStart with custom built-in parameters for send to user. In this case, user will need just to click on the MiniWebStart file for start your application, and will not need to add any parameters.

MiniWebStart is fully working, but I’m planning to make some improvements:

Deployment description looks like jnlp file:

Optional attributes and tags are in square brackets. Minimum memory size is exclusive, maximum memory size — inclusive. M is Mebibytes, i.e. 1024*1024 bytes, G is gibibytes, i.e. 1024*1024*1024 bytes.

Keep in mind that you need to use current directory prefix for execute downloaded files, like «.\start.cmd» or «./start.sh».

You can set command line parameter like «—remote=https://yousite/desc.xml», or define constant in the predefined.go for declare deployment description location. Other command line parameters will be sent to startup application.

You can build application by «DOCKER_BUILDKIT=1 docker build —output=out .» command.

Источник

Альтернативы Java Web Start?

Я чувствую вашу боль, самой большой проблемой, с которой я столкнулся с JWS, является видимость, то есть, что она делает и почему она это делает. Большинство наших проблем были связаны с внутренними прокси-серверами (Java, похоже, действительно не любит аутентификацию доверенных лиц), и на данный момент морщины кажутся сглаженными. Тем не менее, я действительно рассматривал просто запись замены. Это не так сумасшествие, как кажется, JWS делает очень много вещей, на которых меня не волнует, а именно, интеграции с веб-браузером и проверки версий JVM. Рассмотрим следующий сценарий:

• Вы запускаете приложение Java (приложение для запуска). Это приложение принимает один параметр, который является URL-адресом файла JNLP.
• Приложение запускает хэширование URL-адреса и использует его в качестве основы для локальной папки (хранилища), в которой хранятся любые загруженные банки для приложения. Если репозиторий не существует, он создаст его.
• Приложение запуска пытается загрузить JNLP, на который указывает URL. Если он не может загрузить его, он просто запустит все, что находится в репозитории (может быть, предупредить пользователя).
• Если он может загрузить JNLP, проанализируйте его и перечислите все банки, требующие загрузки. Если у вас уже есть банки, используйте что-то вроде Apache HttpClient, чтобы определить, имеет ли сервер более новую версию и, при необходимости, загружается. Важно то, что любые загрузки должны храниться во временной папке. Как только ВСЕ из загрузок преуспели, вы можете применить их к локальному репозиторию. В идеале вы создадите резервную копию того, что уже существует, чтобы разрешить какую-то процедуру отката.

Это должно обеспечить некоторые очень существенные преимущества перед обычным JNLP:

• Видимость, вы можете записывать точно, что происходит.
• Гораздо лучшие режимы отказа: если загрузка прерывается, просто запустите версию, которая уже существует (очевидно, это не сработает, если вмешательство происходит при первой загрузке), если вам хочется сообщить об этом пользователю, сделайте это.
• Запустив локальное приложение, вы должны избегать проблем с подписанием баннеров, я честно не понимаю модель безопасности Java Web Start в отношении подписанных банок, но кажется, что если задействуются разные загрузчики классов, JWS будет жаловаться об этом (я думаю)

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

Источник