спецификации, руководства, описания, API

Руководство JnlpDownloadServlet

Введение

JnlpDownloadServlet сервлет, который упрощает процесс развертывающегося Java веб-приложения Запуска на веб-сервере так же как обеспечении улучшенной функциональности. JnlpDownloadServlet доступно в sample/jnlp/servlet каталог JDK, и как скомпилированные файлы JAR и как исходный код.

В самом простом случае развертывания JNLP Вы помещаете свои файлы приложения и файл JNLP на веб-сервере. После того, как Вы конфигурируете веб-сервер для типа MIME JNLP, у Вас есть основная функциональность JNLP — пользователь щелкает по ссылке файла JNLP в браузере, и Ваше приложение загружается и выполняется.

Однако, у этого подхода есть некоторые недостатки. Во-первых, явный URL кодовой базы приложения должен появиться в файле JNLP. Это означает, что должно быть изменено, если Вы решаете разместить свое приложение в другом месте, или если Вы перемещаетесь от локального тестового сервера до более общедоступного производственного сервера. Кроме того, метка времени файловой системы на Ваших файлах приложения будет использоваться, чтобы сообщить о метке времени Вашего приложения, которое не могло бы быть тем, что Вы хотите. Наконец, только самые основные части протокола JNLP реализуются через HTTP. Управление версиями и другие функции не поддерживаются.

Функции

JnlpDownloadServlet действия как связь между Вашими файлами приложения и клиентом. Это обеспечивает следующие функции:

У Вас нет к hardcode кодовой базе URL в файле JNLP. Это упрощает перемещение от одного сервера до другого.
Можно определить явную метку времени для своих файлов приложения, вместо того, чтобы положиться на метки времени файловой системы.
Сервлет поддерживает полный комплект протоколов загрузки, определенных спецификацией JNLP.
Информация о версии может быть определена на файл или на каталог.
Сервлет генерирует файлы JARDiff.
Сервлет поддерживает сжатие Pack200 для файлов приложения.

Базовый Пример

Понять полезные функции это JnlpDownloadServlet приносит к развертыванию приложения, следует сначала понять самый простой способ, которым приложение может быть распределено, используя JNLP и Java веб-Запуск.

app1 пример (в sample/jnlp/servlet каталог JDK), содержит простое приложение и, возможно более ценный, сценарий сборки Муравья, который создает приложение и связывает его в ВОЕННОМ файле для распределения на веб-сервере.

Само приложение состоит из единого класса, Pie, и файл образа, key-lime.jpg, которые упаковываются в pie.jar файл JAR.

Архив pie.jar упаковывается в файл веб-приложения, app1.war, у которого есть это содержание:

WEB-INF/web.xml
index.html
pie.jnlp
pie.jar

Файл JNLP описывает приложение, предполагая, что это развертывается на сервере в http://localhost:8080/, который работает на локально установленный сервер Tomcat.

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://localhost:8080/app1">
    <information>
        <title>Pie</title>
        <vendor>Example Vendor</vendor>
    </information>
    <resources>
        <j2se version="1.2+"/>
        <jar href="pie.jar" main="true" />
    </resources>
    <application-desc/>
</jnlp>

Рассмотрите взаимодействие между клиентом и сервером как диалоговое окно:

[Пользователь щелкает по ссылке в браузере.]

Клиентский браузер: у меня может, пожалуйста, быть pie.jnlp?

Сервер: Да, здесь Вы идете.

Клиентский браузер: Я замечаю, что тип MIME application/x-java-jnlp-file. Java веб-Запуск, пожалуйста обработайте pie.jnlp для меня?

Клиентский Java веб-Запуск: Позвольте мне видеть, какие ресурсы требуются для этого приложения. Эй Сервер, у меня может, пожалуйста, быть pie.jar?

Сервер: Здесь Вы идете.

Клиентский Java веб-Запуск: Теперь я запущу файл JAR, используя Main-class явный атрибут.

[Приложение появляется на экране пользователя.]

Другие Примеры

app2 пример показывает, как связаться JnlpDownloadServlet с приложением и как использовать это, чтобы выполнить простые замены в файле JNLP.

app3 пример показывает, как имеющий версию запрос ресурса обрабатывается JnlpDownloadServlet.

Оба app2 и app3 будет ссылаться от следующих разделов.

Используя `JnlpDownloadServlet`

Использовать в своих интересах JnlpDownloadServlet, выполните эти шаги.

Пакет JnlpDownloadServlet в Вашем веб-приложении ВОЕННЫЙ файл. Следует использовать два файла JAR, чтобы иметь полную функциональность, jnlp-servlet.jar и jardiff.jar. Эти два файла JAR вставляются WEB-INF/lib каталог Вашего ВОЕННОГО файла.

Карта запрашивает на *.jnlp и *.jar к JnlpDownloadServlet использование Вашего веб-приложения web.xml файл. Это должно содержать строки, которые идентифицируют JnlpDownloadServlet и делает это обработчиком для файлов JAR и JNLP. Вот полный пример:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

  <servlet>
    <servlet-name>JnlpDownloadServlet</servlet-name>
    <servlet-class>jnlp.sample.servlet.JnlpDownloadServlet</servlet-class>
  </servlet>
  
  <servlet-mapping>
    <servlet-name>JnlpDownloadServlet</servlet-name>
    <url-pattern>*.jnlp</url-pattern>
  </servlet-mapping>

  <servlet-mapping>
    <servlet-name>JnlpDownloadServlet</servlet-name>
    <url-pattern>*.jar</url-pattern>
  </servlet-mapping>

</web-app>

app2 и app3 примеры показывают, как упаковать JnlpDownloadServlet в веб-приложении. Рассмотрите сценарий сборки Муравья app2/build.xml или app3/build.xml для получения дополнительной информации.

Замены

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

Метка времени

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

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

Чтобы использовать явную метку времени, добавьте строку к вершине Вашего файла JNLP. Начните строку с TS:. Остальная часть строки должна содержать метку времени в формате ISO 8601, у которого есть этот основной формат:

YYYY-MM-DD hh:mm:ss

Вот один пример:

TS: 2010-08-07 21:19:05

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

Кодовая база и Другие Значения

JnlpDownloadServlet делает замены на строки, которые начинаются с двух знаков доллара. Например, рассмотрите эту строку в файле JNLP:

<jnlp spec="1.0+" codebase="$$codebase">

Когда клиент запрашивает файл JNLP, JnlpDownloadServlet заменяет корректным значением $$codebase, везде, где это развертывается. Это удобно, потому что у Вас нет к hardcode этого значения в файле JNLP, облегчая перемещаться от сервера до сервера.

Полный список замен показывают в следующей таблице:

Имя	Значение, которым заменяют,
`$$codebase`	URL запроса за исключением имени файла JNLP
`$$name`	Имя файла JNLP
`$$context`	Базовый URL веб-приложения
`$$site`	Адрес веб-сервера
`$$hostname`	Имя сервера

Например, предположите app2 пример развертывается в example.com. Значения каждой замены были бы следующие:

Имя	Значение, которым заменяют,
`$$codebase`	`http://example.com/app2/`
`$$name`	`pie.jnlp`
`$$context`	`http://example.com/app2`
`$$site`	`http://example.com`
`$$hostname`	`example.com`

app2/pie.jnlp и app3/pie.jnlp примеры используют только $$codebase.

Версия, Расширение, и Запросы Платформы

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

JnlpDownloadServlet оказывает поддержку для специальных запросов с двумя различными механизмами. Первой является схема именования файлов ресурсов, где локали, операционные системы, и другие параметры встраиваются в имя файла. Второй механизм включает XML-файл, который описывает параметры файлов ресурсов в том же самом каталоге.

Соглашение о присвоении имен файла

JnlpDownloadServlet включения Вы, чтобы определить информацию о файлах, встраивая это в имя файла. Если имя файла содержит два подчеркивания подряд, имя файла обрабатывается как содержащий атрибуты. Буква префикса определяет информацию атрибута, как показано здесь:

Префикс	Значение
`V`	Номер версии
`O`	Операционная система
`A`	Архитектура
`L`	Локаль

Только одна версия позволяется на файл, но файл может быть связан с многократной операционной системой, архитектурой, или атрибутами локали. Например, приложение __ V1.2 __ Len_US __ Len.jar означает что ресурс application.jar имеет версию 1.2, и связанные локали en_US и en.

Например, рассмотрите файл JNLP, который содержит эту строку ресурса:

<jar href="app-lib.jar" version="2.0" />

Когда Java, веб-Запуск встречается с этой строкой в файле JNLP, это отправляет запрос серверу для версии 2.0 app-lib.jar. Если Вы поместили файл app-lib__V2.0.jar в Вашем веб-приложении, JnlpDownloadServlet возвраты это клиенту как версия 2.0 app-lib.jar. Отметьте, как фактическое имя файла в Вашем веб-приложении повторно отображается, чтобы быть видимым клиенту как app-lib.jar.

Файл Версии XML

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

JnlpDownloadServlet поддерживает альтернативный механизм, где все атрибуты описываются в отдельном XML-файле. Сервлет ищет a version.xml файл в том же самом каталоге как ресурс. version.xml файл содержит информацию о других файлах в том же самом каталоге.

Например, следующий version.xml файл описывает ресурс, который доступен клиенту как application.jar. Фактический файл хранится в том же самом каталоге как application-1_2-us.jar.

<jnlp-versions>
  <resource>
    <pattern>
      <name>application.jar</name>
      <version-id>1.2</version-id>
      <locale>en_US</locale>
      <locale>en</locale>
    </pattern>
    <file>application-1_2-us.jar</file>
  </resource>
</jnlp-versions>

app3 пример показывает, как ответить на имеющий версию запрос на ресурс, используя файл версии XML. В частности файл JNLP содержит эту строку ресурса:

<jar href="app-lib.jar" version="2.0" />

ВОЕННЫЙ файл содержит библиотеку, app-lib.jar, и этот файл версии XML version.xml это описывает библиотеку:

<jnlp-versions>
  <resource>
    <pattern>
      <name>app-lib.jar</name>
      <version-id>2.0</version-id>
    </pattern>
    <file>app-lib-2.0.jar</file>
  </resource>
</jnlp-versions>

Отметьте как подлинное имя файла, app-lib-2.0.jar, повторно отображается так, чтобы имя файла, видимое от клиента, было app-lib.jar.

Инкрементные обновления с JARDiff

JnlpDownloadServlet генерирует и возвращает инкрементные обновления до файлов JAR, если возможный. Если current-version-id параметр включается в запрос, и сервлет может найти обоих соответствием на current-version-id и требуемая версия, и запрос для файла JAR, затем файл JARDiff сгенерирован сервлетом. Файл JARDiff возвращается, если его размер является меньше чем та из требуемой версии.

Файл JARDiff сгенерирован и хранится во временном каталоге, который является определенным для веб-контейнера. Сервлет находит временный рабочий каталог, используя javax.servlet.context.tempdir атрибут контекста.

Более быстрые Загрузки с Pack200

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

JnlpDownloadServlet может предоставить ресурсы для клиентов, таких как Java веб-Запуск, та поддержка загрузки Pack200 и GZIP. Место *.jar.pack.gz или *.jar.gz файлы вместе с Вашим оригиналом *.jar файлы на сервере. Например, JnlpDownloadServlet выбирает лучший из следующих файлов, основанных на том, что поддерживает клиент:

pie.jar
pie.jar.gz
pie.jar.pack.gz

Можно создать файлы Pack200, используя pack200 инструмент, который включается с Комплектом разработчика для Java. app3 пример создает версию Pack200 pie.jar файл. Смотрите на build.xml видеть, как файл Pack200 создается. Поскольку pie.jar просто, файл Pack200 незначительно меньше; однако, для большего файла JAR, сжатие намного больше.

Другие Функции

Замены JNLP, поддержка Pack200, и поддержка атрибута файла являются самыми полезными функциями JnlpDownloadServlet. Сервлет также поддерживает систему журналирования и отображение типа MIME.

Журналирование

У сервлета есть возможности журналирования, которые позволяют Вам контролировать его поведение. Регистрирующие сообщения сгенерированы в различных категориях:

FATAL означает неправильное функционирование, или внутренняя ошибка произошла в сервлете.
WARNING указывает на ошибку, обрабатывая часть информации в ВОЕННОМ файле или анализируя version.xml файл.
INFORMATIONAL журналы все запросы, ответы, сканирование каталога, и так далее.
DEBUG детализированная внутренняя информация дисплеев о том, как обрабатывается запрос.

Журналированием вывода управляют два параметра инициализации сервлета, logLevel и logPath. Уровень журнала может быть установлен в также NONE, FATAL, WARNING, INFORMATIONAL, или DEBUG. Путь журнала определяет файл, где вывод пишется. Если никакой путь не определяется, журналирование делается к стандартному журналу для сервлетов (использование ServletContext.log()). Вот пример:

<servlet>
  <servlet-name>
    JnlpDownloadServlet
  </servlet-name>
  <servlet-class>
    jnlp.sample.servlet.JnlpDownloadServlet
  </servlet-class>

  <init-param>
    <param-name>
      logLevel
    </param-name>

    <param-value>
      DEBUG
    </param-value>
  </init-param>

  <init-param>
    <param-name>
      logPath
    </param-name>

    <param-value>
      /logs/jnlpdownloadservlet.log
    </param-value>
  </init-param>

</servlet>

Типы MIME

Сервлет обрабатывает JNLP и файлы JAR особенно. Замены делаются в файлах JNLP как desribed в Заменах. Основанный на версии запрос на файл JAR может привести к генерации инкрементного обновления. Сервлет использует расширения, чтобы определить, является ли файл файлом JAR или JNLP. Расширение по умолчанию файлов JNLP .jnlp и поскольку файлы JAR .jar. Эти расширения по умолчанию могут быть перезаписаны параметрами инициализации: jnlp-extension и jar-extension. Вот пример:

<init-param>
  <param-name>
    jnlp-extension
  </param-name>

  <param-value>
    .xjnlp
  </param-value>
</init-param>

Тип MIME, который возвращается для файла, также основан на его расширении. Тип MIME ищется в конфигурационных файлах для веб-контейнера и ВОЕННОГО файла. Если никакое отображение не определяется, типы MIME по умолчанию присваиваются:

Расширение	Тип MIME по умолчанию
`.jnlp`	`application/x-java-jnlp-file`
`.jar`	`application/x-java-archive`
`.jardiff`	`application/x-java-archive-diff`

Изменить тип MIME JnlpDownloadServlet возвраты, используйте <mime-type> элемент в web.xml файл. Вот пример:

<web-app>
   ...
   <mime-mapping>
      <extension>jnlp</extension>
      <mime-type>text/ascii</mime-type>
   </mime-mapping>
   ...
</web-app>

Создание `JnlpDownloadServlet`

Большую часть времени Вы будете использовать JnlpDownloadServlet непосредственно. В редких случаях Вы могли бы хотеть добавить функциональность к JnlpDownloadServlet. Полный исходный код доступен, и сборка является относительно прямой.

У Вас должен быть GNU make, Комплект разработчика для Java (JDK), и следует определить переменные окружения. Вот один пример на системе Linux.

$ export CLASS_PATH=/home/edmond/Applications/apache-tomcat-7.0.2/lib/servlet-api.jar
$ export FILE_SEPARATOR=:
$ export TMPDIR=/tmp
$ export SDK_HOME=/home/edmond/jdk1.7.0
$ make
.
.
.

Вывод сборки lib/jnlp-servlet.jar и lib/jardiff.jar.

Ссылка

Больше информации О Метках времени ISO 8601

Общий формат метки времени:

   YYYY-MM-DD hh:mm:ss

Тире, двоеточия, и секунды являются дополнительными:

   YYYYMMDDhhmm

Гд находится в 24-часовой нотации. По умолчанию зона местного времени используется. Всемирное время (UTC), также известный как время GMT, может быть определено, добавляя прописную букву Z ко времени:

     23:59:59Z or 235959Z

Строки +hh:mm, +hhmm, или +hh может быть добавлен ко времени, чтобы указать, что зона местного времени hh часы и mm минуты перед UTC. Для часовых поясов к западу от нулевого меридиана, которые находятся позади UTC, нотации -hh:mm, -hhmm, или -hh используется вместо этого. Например, Центрально-европейское время (CET) +0100, и американское/Канадское Восточное Стандартное Время (ОЦЕНКА)-0500. Следующие строки все указывают на тот же самый момент времени:

     12:00Z = 13:00+01:00 = 0700-0500

Спецификация Файла Версии XML

Полное определение типа документа (DTD) для version.xml файл показывают здесь:

<!ELEMENT jnlp-versions <resource*, platform*)>
<!ELEMENT resource (pattern, file)>
<!ELEMENT platform (pattern, file, product-version-id)>
<!ELEMENT pattern (name, version-id, os*, arch*, locale*)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT version-id (#PCDATA)>
<!ELEMENT os (#PCDATA)>
<!ELEMENT arch (#PCDATA)>
<!ELEMENT locale (#PCDATA)>
<!ELEMENT file (#PCDATA)>
<!ELEMENT product-version-id (#PCDATA)>

Свяжитесь с Нами