Как запустить jar файл на сервере

Обновлено: 08.07.2024

Java - это кроссплатформенный язык программирования, благодаря которому программы, написанные один раз, можно запускать в большинстве операционных систем: в Windows, Linux и даже MacOS. И всё это без каких-либо изменений.

Но программы, написанные на Java, распространяются в собственном формате .jar, и для их запуска необходимо специальное ПО - Java-машина. В этой небольшой статье мы рассмотрим, как запустить jar-файл в Linux.

Как запустить jar Linux

Как я уже сказал, для запуска jar-файлов нам необходимо, чтобы на компьютере была установлена Java-машина. Если вы не собираетесь ничего разрабатывать, вам будет достаточно Java Runtime Environment или JRE. Что касается версии, то, обычно, большинство программ работают с 7 или 8 версией. Если нужна только восьмая, то разработчики прямо об этом сообщают. Посмотреть версию Java и заодно убедиться, что она установлена в вашей системе, можно с помощью команды:

У меня установлена восьмая версия, с пакетом обновлений 171. Если вы получаете ошибку, что команда не найдена, то это значит, что вам нужно установить java. В Ubuntu OpenJDK JRE можно установить командой:

Если вы хотите скомпилировать пример из этой статьи, то вам понадобиться не JRE, а JDK, её можно установить командой:

Чтобы узнать, как установить Java в других дистрибутивах, смотрите статью по ссылке выше. Когда Java будет установлена, вы можете очень просто запустить любой jar-файл в Linux, передав путь к нему в качестве параметра Java-машине. Давайте для примера создадим небольшое приложение:

public class Main public static void main(String[] args) System.out.println(" Losst test app! ");
>
>

Затем скомпилируем наше приложение в jar-файл:

javac -d . Main.java
jar cvmf MANIFEST.MF main.jar Main.class

Теперь можно запустить наш jar-файл командой java с параметром -jar:

java -jar main.jar

Таким образом вы можете запустить любой jar-файл, который собран для вашей версии Java. Но не очень удобно каждый раз открывать терминал и прописывать какую-либо команду. Хотелось бы запускать программу по щелчку мышки или как любую другую Linux-программу - по имени файла.

Если мы дадим программе право на выполнение:

chmod u+x ./main.jar

И попытаемся её запустить, то получим ошибку:

sudo apt install jarwrapper

Теперь можно запускать java в Linux по щелчку мыши или просто командой.

Выводы

В этой небольшой статье мы рассмотрели, как запустить jar Linux с помощью java-машины, а также как упростить команду запуска. Если у вас остались вопросы, спрашивайте в комментариях!

Нет похожих записей

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.

Всем привет. Продолжаем цикл статей по написанию своего проекта.

Сортируем ветки

JRTB-0
JRTB-2
JRTB-3

STEP_1_JRTB-0 — первый шаг
STEP_2_JRTB-2 — второй шаг
STEP_3_JRTB-3 — третий шаг

Немного о докере

Что такое Docker? Вкратце — это инструмент, с помощью которого можно быстро и безопасно развертывать (деплоить) приложения, создавая для них закрытую инфраструктуру, необходимую только для них. Пока что сложно, я понимаю. В общем и целом докер можно понимать как платформу для разработки, где можно быстро и эффективно работать. Докер можно понимать как программу, которая работает на сервере. Эта программа имеет возможность хранить контейнеры с приложениями. Что такое контейнер? Это отдельная инфраструктура, в которую можно добавить все, что нужно. Например для Java-приложения нам нужна JRE, чтобы запустить приложение, вот контейнер будет иметь это, нужно будет еще какое-то программное обеспечение — можно добавить это. А может быть, нам нужен Линукс и Tomcat сервлет контейнер. Такое тоже можно будет сделать. Контейнеры создаются на основе image (образа): то есть, это определенный шаблон в котором написано все необходимое для создания докер контейнера. Как создать этот образ? В нашем случае нам нужно будет создать файл Dockerfile в корне проекта с описанием того, что должно быть в контейнере. Так как мы не хотим где-то показывать токен бота, придется извернуться и передавать его каждый раз, когда мы захотим развертывать приложение. Более детально об этой теме почитать можно здесь и здесь.

Пишем JRTB-13

Нужно настроить быстрый и легкий процесс развертывания (деплоя) нашего приложения на сервер. То есть на машину, которая работает 24/7. За основу возьмем докер. Но задачи в нашем списке, которая бы отвечала за добавление этой функциональности, нет. Как-то я его пропустил при создании. Ничего страшного, сейчас создадим. Заходим на вкладку создания issue на гитхаб и выбираем Feature Request:Добавляем описание задачи, критерии его приемки, устанавливаем, к какому проекту этот issue относится и можно создавать новое issue:Теперь чтобы показать, что задача взята в работу, сменим статус задачи с To do на In Progress:Это будет сложная статья. Если будут проблемы — пишите в комментариях: я буду следить и отвечать на них в меру сил. Такой будет небольшой Customer Support :D

Создаем Dockerfile

Создаем docker-compose.yml

Хорошо бы вам про YAML формат почитать отдельно, а то статья и так уже растет, как на дрожжах. Для нас это просто еще одно описание переменных по типу .properties. Только в пропертях записывается через точку, а в YAML это делается немного красивее. Например, так. Две переменные в .properties: javarush.telegram.bot.name=ivan javarush.telegram.bot.token=pupkin А вот в .yaml (тоже самое что и .yml) будет это так: Второй вариант более красивый и понятный. Пробелы должны быть именно такие, как указаны выше. Как-нибудь переведем наши application.properties и application.yml. Для начала нужно его создать. В корне проекта создаем файл docker-compose.yml и записываем туда следующее: Первая строка — это версия docker-compose. services: говорит о том, что все следующие строки после этого (будут сдвинуты) — относятся к сервисам, которые мы настраиваем. У нас такой пока только один — java-приложение под названием jrtb . И уже под ним будут все его настройки. Например, build: context: . говорит о том, что мы будем искать Dockerfile в той же директории, что и docker-compose.yml. А вот секция environment: будет отвечать за то, чтобы мы передали в Dockerfile необходимые переменные среды (environment variables). Как раз то, что нам и нужно. Поэтому ниже мы переменные и передаем. Их docker-compose будет искать в переменных операционной среды сервера. Добавим их в баш скрипте.

Создаем баш скрипты

Dockerfile — файл для создания образа нашего приложения;
docker-compose.yml — файл с настройкой того, как мы будем запускать наши контейнеры;
start.sh — баш скрипт для развертывания нашего приложения;
stop.sh — баш скрипт для остановки нашего приложения.

И в README добавим новый параграф с описанием того, как деплоить наше приложение:

Разумеется, все пишет на английском. Уже как обычно, в нашей новосозданной ветке STEP_4_JRTB-13 создаем новый коммит с именем: JRTB-13: implement deployment process via docker и делаем пуш. Я перестаю подробно останавливаться на вещах, которые я уже описывал в прошлых статьях. Не вижу смысла повторять одно и тоже. К тому же, кто разобрался и сделал у себя, у того вопросов не возникнет. Это я о том, как создать новую ветку, как создать коммит, как запушить коммит в репозиторий.

За сегодня я показал тьму новой информации, которую нужно хорошо обдумать и расширить дополнительным чтением. Самое главное: при помощи ОДНОЙ(. ) команды все необходимое для развертывания нашего приложения будет сделано. Это настолько классно, что я даже передать не могу вам. Да, пришлось потратить приличное количество времени в документации докера, чтобы понять, как правильно пробрасывать переменные. С этого момента телеграм-бот всегда будет работать на последней версии main ветки. Ссылка на телеграм-бота. Сегодня не будут ссылок на материалы, которые хорошо бы прочесть: ответственность лежит на вас. Нужно учиться искать информацию. Все, кто подписан на мой телеграм-канал, узнали о деплое бота почти сразу же. Друзья, нравится проект? Ставьте ему звезду! Так он станет более популярным и больше людей смогут узнать о нем и поучиться. Традиционно предлагаю зарегистрироваться на GitHub и подписаться на мой аккаунт, чтобы следить за этой серией и другими моими проектами, которые я веду там. Теперь мы готовы подключать базу данных. Следующая статья будет бооольшая и в ней мы сделаем все необходимое для работы с БД. Все описание — в JRTB-1.

В этой статье объясняется, что такое Java Web Start (JWS), как настроить его на стороне сервера и как создать простое приложение.

1. Обзор

Примечание: JWS был удален из Oracle JDK, начиная с Java 11. В качестве альтернативы рассмотрите возможность использования Open Web Start .

2. Введение

JWS-это среда выполнения, которая поставляется вместе с Java SE для веб-браузера клиента и существует с версии Java 5.

При загрузке файлов JNLP (также известных как протокол запуска сети Java) с веб-сервера эта среда позволяет нам удаленно запускать пакеты 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:

Давайте назовем его hello.jndi и поместим в любую веб-папку нашей ВОЙНЫ. И JAR, и WAR загружаются, поэтому нам не нужно беспокоиться о том, чтобы поместить JAR в папку lib .

URL-адрес нашей последней банки жестко закодирован в файле JNLP, что может вызвать некоторые проблемы с распространением. Если мы изменим серверы развертывания, приложение больше не будет работать.

Давайте исправим это с помощью правильного сервлета позже в этой статье. А пока давайте просто поместим файл JAR для загрузки в корневую папку в качестве index.html , и связать его с элементом привязки:

Давайте также установим основной класс в нашем JAR-манифесте . Это может быть достигнуто путем настройки плагина JAR в pom.xml файл. Аналогично, мы перемещаем файл JAR за пределы WEB-INF/lib , поскольку он предназначен только для загрузки, т. е. не для загрузчика классов:

4. Специальные конфигурации

4.1. Вопросы безопасности

Чтобы запустить приложение, нам нужно подписать банку . Создание действительного сертификата и использование плагина JAR Sign Maven выходит за рамки этой статьи, но мы можем обойти эту политику безопасности в целях разработки или если у нас есть административный доступ к компьютеру нашего пользователя.

5. JnlpDownloadServlet

5.1. Алгоритмы сжатия

Есть специальный сервлет, который можно включить в нашу ВОЙНУ. Он оптимизирует загрузку, ища наиболее сжатую скомпилированную версию нашего файла JAR, если она доступна, а также исправляет жестко закодированное значение codebase в файле JLNP.

Поскольку наша БАНКА будет доступна для загрузки, рекомендуется упаковать ее с помощью алгоритма сжатия, такого как Pack200, и доставить обычную банку и любой пакет JAR.PACK.GZ или JAR.GZ сжатая версия в той же папке, чтобы этот сервлет мог выбрать лучший вариант для каждого случая.

К сожалению, пока нет стабильной версии плагина Maven для этого алгоритма сжатия, но мы можем работать с исполняемым файлом Pack200, который поставляется с JRE (обычно устанавливается по пути /jre/bin/ ).

Без изменения JNLP и путем размещения jar.gz и jar.pack.gz версии JAR в той же папке, сервлет выбирает лучшую, как только он получает вызов от удаленного JNLP. Это улучшает пользовательский интерфейс и оптимизирует сетевой трафик.

5.2. Динамическая подстановка Кодовой Базы

Сервлет также может выполнять динамические замены жестко закодированных URL-адресов в теге . Изменив JNLP на подстановочный знак , он доставит тот же окончательный тег визуализации.

5.3. Добавление сервлета в путь к классу

Чтобы добавить сервлет, давайте настроим обычное сопоставление сервлетов для шаблонов JAR и JNLP для вашего web.xml :

Сам сервлет поставляется в виде набора банок ( jardiff.jar и jnlp-servlet.jar ), которые в настоящее время находятся в разделе демонстраций и образцов на странице загрузки Java SDK.

В примере GitHub эти файлы включены в папку java-core-samples-lib и включены в качестве веб-ресурсов плагином Maven WAR:

6. Заключительные мысли

Java Web Start-это инструмент, который может использоваться в средах (интрасети), где нет сервера приложений. Кроме того, для приложений, которым необходимо манипулировать локальными файлами пользователей.

Я сделал приложение java, которое хранит данные из a .csv-файл в базу данных MySql. Теперь мой клиент хочет загрузить это приложение в свое веб-пространство (веб-пространство, которое он взял для своего веб-сайта), чтобы он мог запустить эту программу на этом сервере.

я использовал FileZilla программа для загрузки программа для его веб-хостинг, но теперь я не знаю как запустить эту программу на своем сервере.

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

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

поскольку он хранит данные из файла (.csv-файл) в базу данных MySql, тогда было бы лучше развернуть эту программу на сервере, на котором размещается база данных, а не на сервере, на котором размещается веб-сайт?

действительно, говоря "веб-приложение", мы обычно имеем в виду специальное приложение, запрограммированное для работы на веб-сервере все время, просто ожидая запросов от пользователя для обработки.

в вашем случае, у вас есть консольное приложение.

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

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

в случае внутреннего сервера компании вам нужно попросить своего клиента и его ИТ-материал настроить это.

наконец, вам нужно спросить: 1. Поддерживает ли сервер SSH? - это просто пульт дистанционного управления. Обычно он работает на порту 22, и вы многие проверяете его с помощью команды " telnet yourserver 22" (windows и linux) - если он не отклоняет ваше соединение - настроены означает, что SSH-это. 2. Установлен ли на вашем сервере java и доступен ли он для вашей учетной записи через SSH-соединение?

только если ваш клиент действительно означает веб-приложение вместо консольного приложения, вам нужно спросить, есть ли у сервера сервер веб-приложений для Java - обычно это что-то вроде Apache Tomcat, Jetty, JBoss, Weblogic и т. д. Но этот способ потребует модификации приложения, чтобы запустить его на веб-сервере.

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

наличие "веб-пространства" не обязательно означает, что он имеет достаточный доступ к серверу для запуска произвольных программ (или базы данных MySql).

вы может потенциально перепишите приложение как веб-приложение, но это может быть не очень хорошо подходит.

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

ваше приложение, скорее всего, консольное, а не веб-приложение.

вашему клиенту нужно будет SSH на сервер и сделать что-то вроде:

Если у вашего веб-хоста есть java, вы можете попробовать выполнить его из php cronjob без необходимости ssh:

1. Введение.

Что такое Java Web Start? Это небольшая, бесплатно распространяемая программа на клиентском ПК ассоциированная с веб-броузером. Когда пользователь щелкает в броузере на HTML странице ссылку, указывающую на специальный JNLP (Java Network Launching Protocol) файл запуска Java-приложения, это приводит к запуску Java Web Start, который в свою очередь автоматически скачивает файлы приложения с Web-сервера, кэширует их и запускает описанное Java-приложение. Java Web Start идет в стандартной инсталляции как JRE 1.4.х так и и JDK 1.4.x. Стоит сказать, что Java Web Start - это кроме того и набор технологий + API, который позволяет очень легко решить вопрос установки Java-приложений (также и Applet-ов) и их последующего "автоматического" обновления на любом ПК в корпоративной (и не только корпоративной) среде. После "единичной" настройки самого Java Web Start на клиентском ПК и установки вашего Java-приложения, все необходимые для работы JAR библиотеки кэшируются на клиентском ПК. Последующие обновления приложения (при обновлении функциональности приложения, при устранении в коде ошибок) на клиентском ПК выполняются при запуске приложения АВТОМАТИЧЕСКИ. Т.е. Java Web Start позволит вам не заботиться об обновлении Java-приложения на локальных ПК, и выполнит это "самостоятельно и автоматически", проверяя и скачивая новые версии НЕ ТОЛЬКО написанных ВАМИ модулей, но также и обновленные версии используемых клиентским приложением сторонних библиотек. При этом на клиенте происходит обновление только тех файлов библиотек, которые изменились на сервере. Когда код вашего клиентского приложения обновился и вам требуется обновить его на локальных ПК, вам потребуется ВСЕГО ЛИШЬ положить новые версии JAR-библиотек приложения на сервер приложений (в WAR-приложение). При запуске установленного и кэшированного на клиенте приложения, Java Web Start выполняет сравнение локальных версий файлов и файлов на сервере. При изменении файлов на сервере, выполняется выборочное скачивание ТОЛЬКО изменившихся JAR файлов.

2. Требования к Java-приложениям и настройки на клиентском ПК.

Так как работа Java Web Start основана на использовании JNLP-протокола, то выполнить настройки необходимо как на стороне СЕРВЕРА, так и на стороне КЛИЕНТА.

Для установки Java-приложений на локальном ПК нам понадобиться установленный Java Web Start (Application Manager) и веб-броузер. Броузер требуется только для первоначального запуска Java-приложения и после запуска может быть закрыт, в то время как приложение будет продолжать работать. В качестве броузера лучше сначала использовать IE, т.к. он работает корректно сразу. Также можно воспользоваться и другими броузерами (Mozilla, Opera 7.x), но для этого необходимо выполнить в них небольшие настройки. Как настроить Opera 7.x для правильной работы с JNLP файлами, я написал в самом конце этой статьи, аналогичным образом должны настраиваться и другие броузеры.

Если Java-приложение запускается часто, то в среде Windows можно с помощью Java Web Start, создать стандартный "ярлык приложения" на рабочем столе и запускать Java-приложение НЕ ИСПОЛЬЗУЯ броузер, а пользуясь только ярлыком. Также можно запускать Java-приложение из командной строки.

Как уже было сказано, Java Web Start, всегда доступен как при установке JRE 1.4.x, так и при установке JDK 1.4.x, поэтому нам ничего не остается сделать как воспользоваться его возможностями. К сожалению для версии JDK/JRE 1.3 его нужно устанавливать отдельно. Но я бы НЕ советовал этого делать, т.к. на мой взгляд он сыроват и лучше всего перевести код вашего приложения на версию JDK 1.4, тем более что GUI клиент прекрасно взаимодействует с сервером под JDK 1.3. Проблем с передачей сериализированных объектов между версиями JDK 1.3 <-> 1.4 замечено не было.

Если вы никогда не запускали и не видели на "рабочем столе" ярлыка Java Web Start, который изображается обычно такой иконкой,

тогда вам необходимо найти данное приложение в каталоге, где установлен JDK (или JRE). Для установленной JDK 1.4 это будет например файл: . \j2sdk1.4.2\jre\javaws\javaws.exe , который находиться в каталоге Java Web Start (..\javaws). В этом же каталоге находяться и другие DLL файлы, необходимые для его корректной работы. В случае установки ТОЛЬКО JRE данный запускаемый файл можно найти в каталоге - . \Program Files\Java\j2re1.4.xx\javaws\javaws.exe

Если вы не видите этого ярлыка, то необходимо найти указанный исполняемый файл и запустить его. После запуска вы должны увидеть окно Java Web Start Application Manager:

Если вы запустили на локальном ПК клиента Java Web Start, то можно считать, что этого достаточно для того, чтобы устанавливать клиентские Java-приложения. Но я все-таки хочу обратить ваше внимание на дополнительные параметры настройки JWS. Откройте в приложении JWS Application Manager:
File -> Preferences, закладка General.

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

Подробности можно найти также в PDF спецификации -
JAVA™ NETWORK LAUNCHING PROTOCOL & API SPECIFICATION (JSR-56) VERSION 1.0.1
более новая версия протокола уже 1.2

Кроме этого, вам понадобиться взять на сайте Sun небольшой архив, предназначенный для разработчика. В моем случае это был файл размером около 160 Кб - javaws-1_2-dev.zip. Он содержит необходимую информацию о настройке JNLP, А ТАКЖЕ JAR архивы классов сервлетов (jardiff.jar, jnlp-servlet.jar, jnlp.jar), которые будут необходимы на сервере.

3. Создание JNLP файла, описывающего ваше клиентское приложение, его библиотеки и другие параметры.

Для того, чтобы Java Web Start мог знать какие именно файлы необходимы для запуска и работы вашего клиентского приложенния, необходимо создать специальный JNLP файл, имеющий XML формат. Данный файл будет помещен на сервере JBoss в Web-приложение, предназначенное для выполнения деплоймента GUI.

Я приведу здесь краткий и простейший пример JNLP файла, использованного для деплоймента, и дам небольшие пояснения о тегах файла и их значениях. Для более детального описания всех параметров и всех возможностей данной технологии, я очень рекомендую вам обратиться к документации разработчика на сайте Sun Microsystems.

href="application.jnlp" - название JNLP файла-дескриптора, который описывает наше приложение. Данный параметр также можно заменить "специальной переменой", фактическое значение которой jnlp-сервлет поставит при обработке запроса. href="$$name"

В разделе ресурсов, есть указание использования JRE версии 1.3 и более новых - <j2se version="1.3+"/>. А вообще, элемент <resources> может содержать 6 различных подэлементов, таких как: jar, nativelib, j2se, property, package и extension. Подробности и правила можно найти в документации.

<jar href="main_gui.jar" main="true"/> - Указание библиотеки, в которой находятся классы нашего приложения, при этом параметр main="true", указывает что данный JAR архив содержит запускаемый класс GUI приложения.

<jar href="jboss-client.jar"/> - далее перечислены все наобходимые библиотеки, которые будут получены с сервера и кэшированы на клиенте

<property name="java.naming.provider.url" value="localhost:1099"/> - так мы можем перечислить все, передаваемые в качестве параметров запуска приложению свойства, которые получаются вызовом System.getProperty(. )

<application-desc main-class="com.my_company_name.client.Application" /> - указание полного запускаемого класса. JWS также поддерживает запуск Applet-ов. В этом случае вместо тэга <application-desc> используется тэг <applet-desc>. Принцип написания и параметры - смотрите в документации.

Что касается элемента <information> JNLP файла. В данном тэге значения подэлементов <title> и другие, наверное, пока что лучше указывать на английском языке. В последней версии Java Web Start (1.2) из версии JDK 1.4.2_04-b05 название на русском языке в JNLP файле, вызвали ошибку при конвертировании русских букв. Ошибка наблюдалась в логе JBoss (server.log):

JNLP файл имеет также дополнительные параметры и позволяет указывать разные ресурсы приложения в зависимости от: версии самого приложения, версии операционной системы, платформы, "локали" - т.е. поддерживает "версионность" приложений по разным критериям. В качестве ресурсов можно также указывать "native" библиотеки (например DLL, SO), используемые вашим приложением. Если вашему приложению требуется доступ к локальным файлам или другие права на локальном ПК, то для этого существует раздел <security>, который необходимо также описать. При необходимости доступа к локальным ресурсам на ПК, например файлов, все библиотеки вашего приложения должны быть подписаны сертификатом, который можно сгенерировать самостоятельно. Все подробности и правила описания можно найти в документации.

Для создания JNLP деплоймент файлов можно использовать свободно распространяемый "DeployDirector" от Sitraka Software, подробности читайте на сайте производителя.

4. Настройка поддержки JNLP (Java Network Launching Protocol) на сервере JBoss 3.x.x с установленным Web-контейнером Apache TomCat.

К сожалению, мне пока не приходилось настраивать JNLP на сервере JBoss, который использует в качестве Web-контейнера Mortbay Jetty, а только Apache TomCat. Но посмотрев внутренности Jetty, могу сказать, что это тоже вполне возможно сделать аналогичным способом. Нужно только внимательно посмотреть и найти файлы настроек в JAR архивах данного Web-контейнера, в которые понадобиться внести аналогичные добавления.

Итак, какие изменения вносят на сервере.

4.1 Добавление поддержки новых MIME типов в Apache TomCat.

Мы выполним данную настройку "глобально" для всего TomCat, чтобы этот MIME тип был описан для всех Web-приложений контейнера, но такого же эффекта можно добиться, если добавить дополнительные MIME типы ТОЛЬКО в web.xml отдельного web-приложения, которое будет вами сделано на сервере для деплоймента клиенского ПО. Для добавления новых MIME типов, мы находим в каталоге JBoss, подкаталог в котором установлен TomCat. В случае JBoss 3.x - это скорее всего каталог: . \jboss\catalina\

Находим конфигурационный файл - . \jboss\catalina\conf\web.xml.

В последних версиях JBoss 3.2.x данный файл необходимо искать в каталоге:
. \jboss-3.2.3\server\default\deploy\jbossweb-tomcat41.sar\web.xml

В данном файле находим раздел, где описаны MIME типы, проверяем есть ли они уже в списке описанных. jnlp, jar - обычно уже есть, а вот jardiff - скорее всего необходимо добавить. При их полном отсутствии добавляем, например в начало списка, еще три дополнительных типа:

Замечание: Будьте внимательны с тем, что можно легко перепутать расширение файлов *.jnlp, ошибочно назвав *.jnpl, как в настройках Web-контейнера, так и в названиях файлов.

4.2 Создание архива Web-приложения (WAR), предназначенного для деплоймента Java-приложения на локальные ПК.

В каталоге JBoss, предназначенного для деплоймента J2EE приложений, создадим новое Web-приложение. Его можно создать любым удобным способом, я предлагаю сделать так: пусть это будет "default" конфигурация. Внутри деплоймент каталога, создаем каталог web-приложения с названием, указанным в JNLP файле, это будет - ..\application.war

В моем случае содержимое WAR приложения выглядит так:

4.3 Добавление необходимых параметров в web.xml файл WAR-приложения.

Кроме этого необходимо, описать необходимые настроечные параметры у нашего Web-приложения в файле . \jboss-3.2.1\server\default\deploy\application.war\WEB-INF\web.xml. Согласно документации в него нужно дописать следующие настройки, которые выделены красным цветом:

Еще одно из требований для корректной работы JNLP сервлета, описанного в примере настройки - это наличие XML парсера. Для этого необходимо, что либо сам Web-контейнер был запущен с помощью JRE 1.4 , в которой парсер интегрирован, или чтобы парсер был доступен серверу как библиотека. В нашем случае, т.к. JBoss имеет в поставке XML парсер (Xerces), никаких дополнительных действий делать НЕ НАДО. В случае если ваша ситуация отличается, то добавьте парсер в Web-приложение - каталог где хранятся библиотеки приложения . \application.war\WEB-INF\lib\

Теперь опишем КАК выглядит индексная страница, с которой осуществляется установка и запуск наших клиентских приложений на локальных ПК пользователей. Простейший вид страницы index.html :

5. Пробуем запустить.

Все готово к первому запуску Java-приложения. Запускаем JBoss, сначала WAR-приложение должно успешно задеплоиться. В логах вы должны увидеть приблизительно следующее:

Если этого не произошло - проверяйте все настройки и параметры Web-приложения.

Щелкнув на ней мы должны увидеть Splash-скрин запуска Java Web Start. Для версии JDK 1.4.2 он выглядить примерно так:

После этого на сервере в логе должны появиться записи об обращении к JNLP-сервлету примерно такого вида:

Теперь мы можем посмотреть на причину данной ошибки, нажав кнопку - Details. В моем случае оно выглядело так:

Другие закладки дают дополнительную информацию о причине и характере ошибки:

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

Исправив ошибку в application.jnlp, который находиться на сервере, мы сразу выполняем повторный запуск Java-приложения. Если все получилось, что вы увидите окно показывающее загрузку библиотек:

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

Если вы ответите на вопрос положительно на рабочем столе появиться ярлык для запуска клиентского Java-приложения, которым можно пользоваться "напрямую", НЕ запуская броузер.

Также после успешной установки Java-приложения на клиентский ПК в JWS Application Manager появиться ссылка на ваше приложение, с указанием источника. Там же с помощью иконок в правом нижнем углу JWS сообщает об доступности новых версий библиотек данного приложения.

Что еще можно увидеть в настройках JWS. Например кэш, в котором храняться Java-приложения, установленные с помощью JWS расположен в каталоге настроек пользователя:

На закладке "Advanced" можно увидеть каталог кэшированного приложения, в моем случае это был D:\Documents and Settings\Blandger\Application Data\Java\. При этом также указывается текущий размер занимаемый приложением - 3110 Кб, в любое время вы можете легко очистить кэш, используя кнопку - "Clear Folder".

Теперь, если вы дочитали до этого места и все-таки не совсем поняли что происходит. Как вы думаете, что теперь необходимо сделать для обновления Java-приложения на локальных ПК пользователей после того, как мы собрали новую версию GUI приложения, или например решили использовать более свежую версию какой-то сторонней библиотеки ?

Мы должны всего лишь скопировать новые версии библиотек в каталог сервера . \jboss-3.2.1\server\default\deploy\application.war\ , у меня это файлы: main_gui.jar, main_gui_lib.jar (или например библиотеки - xercesImpl.jar, xmlParserAPIs.jar). При последующем запуске GUI приложения на клиентском ПК с помощью Java Web Start данные JAR файлы будут скачены на ПК, после чего приложение будет запущено с новыми версиями библиотек. Вот и все действия для обновления !

Приложение: Как настроить броузер Opera 7.x для корректной работы с JNLP файлами.

Можно открыть файл, нажав кнопку "Open". А можно нажать кнопку "Change. " и установить обработку данного MIME-типа и расширения файлов "по умолчанию".

Отметьте пунк "Open with default application" и Opera будет всегда открывать JNLP файлы с помощью Java Web Start.

Читайте также: