open web start что это
What is OpenWebStart?
OpenWebStart is an open source reimplementation of the Java Web Start technology. It provides the most commonly used features of Java Web Start and the JNLP standard, so that your customers can continue using applications based on Java Web Start and JNLP without any change. OpenWebStart is based on Iced-Tea-Web and the JNLP-specification defined in JSR-56. OpenWebStart is released under the GPL with Classpath Exception. For more information, read the full license here.
The main focus of OpenWebStart is the execution of JNLP-based applications. Additionally, the tool contains four modules that simplify your Web Start workflows and let you configure OpenWebStart to suit your needs:
App Manager
JVM Manager
Control Panel
Updater
Which JNLP features will be supported?
How do I install and manage OpenWebStart?
OpenWebStart comes in two different versions:
If you or your customers are companies with IT departments of their own, we recommend an unattended installation to roll out OpenWebStart on multiple client machines. In this scenario, the auto-update functionality is inactive; your IT department is free to plan and handle rollouts of new versions based on your internal workflows.
Roadmap
OpenWebStart follows a half-yearly release cycle. The releases are targeted around May and November each year. These regular releases usually contain bugfixes as reported by sponsors and the community as well as recurring maintenance issues to guarantee stability and topicality.
Hot-fix releases may be published at any time (independent of the regular release cycle). The same applies for customer-specific releases. For customer-specific releases, a support contract with Karakun is needed.
New features are currently only developed when a sponsor can be found. Contact us for an individual offer.
OpenWebStart installation and administration guide
Latest news
2021-06-20 : Release OpenWebStart V1.4.0
Table of contents
Overview
For the start of the Aftersales applications OpenWebStart is required since February 2020. OpenWebStart is an open source software package that must be installed locally on the workstations of all application users.
Please follow the installation instructions to set up OpenWebStart on your workstation.
The User guide describes the usage of OpenWebStart.
Administrators and IT departments can find information about integrating OpenWebStart with centrally administered workstations or terminal servers in the Administration Guide.
Several applications provided by the Mercedes-Benz AG are «rich client» applications, programmed in the language Java™. The applications are running on the local computer of the user, and they require a so called Java Runtime Environment (JRE) to work. In the past, the runtime environment used to run such applications was provided by the supplier Oracle™.
Rich clients can be launched directly from the web browser. To achieve this, a technology named «Java Web Start» (JWS) is part of the Oracle Java Runtime Environment (JRE). In 2017 Oracle decided to drop the support for Java Web Start. Starting with Java 11, the JWS has been removed from the JRE installation packages. This means, that clients that have the latest version of Oracle 11 JRE installed, can no longer launch applications through JWS.
In parallel, Oracle has ended free support of Java 8 in 2019. Companies no longer get any updates and security fixes for Oracle Java 8.
Therefore the Mercedes-Benz AG decided to replace the usage of Oracle Java with the new product OpenWebStart (OWS), provided by the Swiss company Karakun AG. OpenWebStart will keep on enabling the same reliable, long-term and secure provision of Java Web Start technology, but with an improved costing framework.
What’s the problem?
What needs to be done?
To make sure, that the applications still can be started in future, the following actions need to be taken on user’s side:
| Time schedule | |
|---|---|
| Immediately | Upgrade of 32-bit operating systems to 64-bit operating systems, replacement of hardware if necessary. |
| Until end of 10/2020 | OWS-Installation on user devices (phased in, during this period application launch through Oracle Java 8 is still possible, until OWS has been installed) |
What happens after 31 st of October 2020?
Mercedes-Benz AG ensures, that the Aftersales applications can be started using Oracle 8 Java Runtime until 31 th of October 2020. After that date we will not face you with a «hard cut». But there will be no further engagement, that the applications will be compatible with Oracle JRE 8 after changes.
What about my XENTRY Diagnosis Kit system?
XENTRY Diagnosis Kit systems have no demand for a replacement change, no installation of OpenWebStart is necessary for launching WIS/ASRA on these devices. Don’t try to perform an OWS installation!
Как мы мигрировали с Oracle JDK и Java Web Start на AdoptOpenJDK и OpenWebStart
Доброго времени суток.
В данной статье я расскажу о «модернизации» в компании, в которой я работаю, такого инструмента как Java Web Start, а точнее об его замене альтернативным opensource решением.
О себе
Меня зовут Ильдар и работаю я в одной немецкой компании, которая как и многие немецкие компании использует старый стек технологий и пытается мигрировать на стек поновее.
Проблема
Начну с описания проблемы. В нашей компании есть важнейшая часть системы, которая представляет из себя 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 (за прогрессом можно наблюдать тут).
Перечислять все возможные настройки не вижу смысла, это может занять очень долго.
Вот лишь некоторые из них:
Особенности использования OpenWebStart и проблемы, с которыми мы столкнулись
Установка OpenWebStart
Установить OpenWebStart довольно просто. Достаточно на сайте скачать установочный файл для вашей платформы и следовать инструкциям установщика.
Но вот незадача. В нашем случае пользователями являются около 10000 клиентов, на каждый из которых служба поддержки нашей компании должна установить этот инструмент. Решение нашлось довольно быстро: доступна так называемая фоновая установка.
Нужно закинуть установочный файл на каждый из компьютеров и запустить специальную команду(а для этого у компании уже есть инструмент):
, где 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-приложений. Если будут вопросы — спрашивайте, постараюсь ответить.
Frequently Asked Questions on OpenWebStart
These FAQs refer to the OpenWebStart version 1.6.0-SNAPSHOT and were build at 08.12.2021.
General
What is OpenWebStart?
OpenWebStart is an open source reimplementation of the Java Web Start technology. It provides the most commonly used features of Java Web Start and the JNLP standard, so that your customers can continue using applications based on Java Web Start and JNLP without any change. OpenWebStart is based on Iced-Tea-Web and the JNLP-specification defined in JSR-56.
Under which license does OpenWebStart come?
OpenWebStart is released under the GPL with Classpath Exception.
Installation
Do I have to install a Java on my system to run OWS?
OpenWebStart comes with a JVM Manager and a bundled Java runtime. There is no need to have any JVM installed on your system.
The bundled JVM is used solely to run OWS. The JVMs manged by the JVM Manager are used to run the JNLP applications.
Which Java versions can be used to run my JNLP applications?
Your JNLP applications can be run with either Java 8 and 11. We have not run any tests with Java 12 or 13 yet but from the experience collected while adding support for Java 11 we do not expect any big obstacles.
OpenWebStart JVM Manager will download and manage JVMs as they are requested by an application. Currently, we provide access to long-term support (LTS) versions of JDKs from various vendors by our default download server. Have a look at the OWS user guide for a list of all JDK vendors that currently are available on this server. Note that this list might be subject of change in the future.
If your preferred JVM is not provided by the default download server, you can either add locally installed JVMs to your JVM manager’s list or setup a custom download server.
Is there an MSI installer for OpenWebStart?
Currently, we do not provide an MSI installer. More details on the reasons can be found at https://github.com/karakun/OpenWebStart/issues/98.
Can I install Oracle Java Web Start and OpenWebStart in parallel?
It is possible to specify separate System Configuration for JWS and OWS. Please see the section OWS specific System Configuration in the OWS Guide.
Debugging and Error Reporting
Does OWS write log files and where do I find them?
The log files of OWS are located in a hidden directory below your user home directory:
where depends on your operating system. By default this should be
Note that logging has to be activated using the OWS Settings application by checking «Activate debug logging» and «Log to file» on the «Logging» tab.
Download
How to set up the resource server to facilitate caching by OWS
To find out whether a resource has been modified since the last download, OWS sends a HTTP HEAD request to the server and expects to receive the last modified timestamp of the resource on the server. In order to facilitate caching of resources by OWS it is necessary that the server from where the resources are downloaded is configured to respond to HTTP HEAD request. In case the server is not configured to respond to HTTP HEAD request, OWS will not be able to determine the last modified timestamp of the resource and will go ahead and download the resource.
Security
What to do when my JNLP application complains about missing certificates in the trust store?
Sometimes OpenWebStart signals that the application’s digital signature cannot be verified when launching an applications with signed jars.
OpenWebStart does not maintain a curated collection of certificates by itself. Rather it relies on the JVM which brings a default set of certificates.
In this context it is helpful to distinguish between the bundled JVM, used to run OpenWebStart itself, and the custom-selected JVM used to launch the JNLP applications. While the bundled JVM cannot customized or replaced by an OpenWebStart user, the JVM used to run the JNLP application is determined by the definition in the JNLP file and by the configuration of the OpenWebStart JVM Manager.
With its half-yearly releases (spring and fall) we update the bundled JVM. This has an impact on the certificates included in the internal JVM.
The certificates available during the execution of the JNLP application are those who come with the custom-selected JVM.
How can I add certifictes to the trust store?
Another possibility is to select the option Always trust content from this publisher
Руководство по веб-запуску Java
В этой статье объясняется, что такое Java Web Start (JWS), как настроить его на стороне сервера и как создать простое приложение.
1. Обзор
В этой статье объясняется, что такое Java Web Start (JWS), как настроить его на стороне сервера и как создать простое приложение.
Примечание: JWS был удален из Oracle JDK, начиная с Java 11. В качестве альтернативы рассмотрите возможность использования Open Web Start .
2. Введение
JWS-это среда выполнения, которая поставляется вместе с Java SE для веб-браузера клиента и существует с версии Java 5.
При загрузке файлов JNLP (также известных как протокол запуска сети Java) с веб-сервера эта среда позволяет нам удаленно запускать пакеты JAR, на которые она ссылается.
Проще говоря, механизм загружает и запускает классы Java на компьютере клиента с обычной установкой JRE. Это также позволяет получить некоторые дополнительные инструкции от Jakarta EE. Однако ограничения безопасности строго применяются JRE клиента, обычно предупреждая пользователя о ненадежных доменах, отсутствии HTTPS и даже неподписанных JAR.
С общего веб-сайта можно загрузить файл JNLP для выполнения приложения JWS. После загрузки его можно запустить непосредственно из ярлыка на рабочем столе или средства просмотра кэша Java. После этого он загружает и выполняет файлы JAR.
Этот механизм может быть очень полезен для предоставления графического интерфейса, который не является веб-интерфейсом (без HTML), такого как приложение для безопасной передачи файлов, научный калькулятор, безопасная клавиатура, локальный браузер изображений и так далее.
3. Простое приложение JNLP
Хороший подход-написать приложение и упаковать его в файл WAR для обычных веб-серверов. Все, что нам нужно, это написать желаемое приложение (обычно с помощью Swing) и упаковать его в файл JAR. Затем этот JAR, в свою очередь, должен быть упакован в файл WAR вместе с JNLP, который будет ссылаться, загружать и выполнять класс Main своего приложения в обычном режиме.
Нет никакой разницы с обычным веб-приложением, упакованным в файл WAR, за исключением того факта, что нам нужен файл JNLP для включения JWS, как будет показано ниже.
3.1. Java-приложение
Давайте начнем с написания простого Java-приложения:
Мы видим, что это довольно простой класс свинга. Действительно, ничего не было добавлено, чтобы сделать его совместимым с JWS.
3.2. Веб-приложение
Все, что нам нужно, это упаковать этот пример класса Swing в файл WAR вместе со следующим файлом JNLP:
URL-адрес нашей последней банки жестко закодирован в файле JNLP, что может вызвать некоторые проблемы с распространением. Если мы изменим серверы развертывания, приложение больше не будет работать.
4. Специальные конфигурации
4.1. Вопросы безопасности
Для этого нам нужно добавить локальный URL-адрес (например: http://localhost:8080 ) в список исключений безопасности установки JRE на компьютере, на котором будет выполняться приложение. Его можно найти, открыв панель управления Java (в Windows мы можем найти его через панель управления) на вкладке Безопасность.
5. JnlpDownloadServlet
5.1. Алгоритмы сжатия
Есть специальный сервлет, который можно включить в нашу ВОЙНУ. Он оптимизирует загрузку, ища наиболее сжатую скомпилированную версию нашего файла JAR, если она доступна, а также исправляет жестко закодированное значение codebase в файле JLNP.
Поскольку наша БАНКА будет доступна для загрузки, рекомендуется упаковать ее с помощью алгоритма сжатия, такого как Pack200, и доставить обычную банку и любой пакет JAR.PACK.GZ или JAR.GZ сжатая версия в той же папке, чтобы этот сервлет мог выбрать лучший вариант для каждого случая.
К сожалению, пока нет стабильной версии плагина Maven для этого алгоритма сжатия, но мы можем работать с исполняемым файлом Pack200, который поставляется с JRE (обычно устанавливается по пути
Без изменения JNLP и путем размещения jar.gz и jar.pack.gz версии JAR в той же папке, сервлет выбирает лучшую, как только он получает вызов от удаленного JNLP. Это улучшает пользовательский интерфейс и оптимизирует сетевой трафик.
5.2. Динамическая подстановка Кодовой Базы
5.3. Добавление сервлета в путь к классу
Чтобы добавить сервлет, давайте настроим обычное сопоставление сервлетов для шаблонов JAR и JNLP для вашего web.xml :
Сам сервлет поставляется в виде набора банок ( jardiff.jar и jnlp-servlet.jar ), которые в настоящее время находятся в разделе демонстраций и образцов на странице загрузки Java SDK.
В примере GitHub эти файлы включены в папку java-core-samples-lib и включены в качестве веб-ресурсов плагином Maven WAR:
6. Заключительные мысли
Java Web Start-это инструмент, который может использоваться в средах (интрасети), где нет сервера приложений. Кроме того, для приложений, которым необходимо манипулировать локальными файлами пользователей.
Приложение отправляется конечному пользователю по простому протоколу загрузки без каких-либо дополнительных зависимостей или конфигурации, за исключением некоторых проблем безопасности (HTTPS, подписанный JAR и т. Д.).
После этого мы сможем запустить Tomcat, как обычно.