Spec-Zone .ru
спецификации, руководства, описания, API
След: Механизм Расширения
Урок: Создание и Используя Расширения
Расширения загрузки
Домашняя страница > Механизм Расширения > Создание и Используя Расширения

Расширения загрузки

Расширения загрузки являются наборами классов (и связанные ресурсы) в файлах JAR. Декларация файла JAR может содержать заголовки, которые обращаются к одному или более расширениям загрузки. На расширения можно сослаться одним из двух способов:

Отметьте, что самое большее одному из каждого разрешают в декларации. Расширения загрузки, обозначенные заголовком Class-Path, загружаются только для времени жизни приложения, которое загружает их, такие как веб-браузер. Их преимущество состоит в том, что ничто не устанавливается на клиенте; их недостаток - то, что они загружаются каждый раз, когда они необходимы. Расширения загрузки, которые загружаются заголовком Extension-List, устанавливаются в каталог /lib/ext JRE, который загружает их. Их преимущество состоит в том, что они загружаются в первый раз, когда они необходимы; впоследствии они могут использоваться без загрузки. Но, как показано позже в этом учебном руководстве, они более сложны, чтобы развернуться.

Так как расширения загрузки, которые используют заголовки Class-Path, более просты, давайте рассматривать их сначала. Предположите например, что a.jar и b.jar являются двумя файлами JAR в том же самом каталоге, и что декларация a.jar содержит этот заголовок:

Class-Path: b.jar

Затем классы в b.jar служат классами расширения в целях классов в a.jar. Классы в a.jar могут вызвать классы в b.jar без классов b.jar, имеющих необходимость быть названными на пути class. a.jar может или, возможно, самостоятельно не расширение. Если бы b.jar не был в том же самом каталоге как a.jar, то значение заголовка Class-Path должно быть установлено в относительный путь b.jar.

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

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

Пример

Предположите, что Вы хотите создать апплет, который использует RectangleArea class предыдущего раздела:

public final class RectangleArea {  
    public static int area(java.awt.Rectangle r) {
        return r.width * r.height;
    }
}

В предыдущем разделе Вы сделали RectangleArea class в установленное расширение, помещая файл JAR, содержащий это в каталог lib/ext JRE. Делая это установленное расширение, Вы позволяли любому приложению использовать RectangleArea class, как будто это была часть платформы Java.

Если Вы хотите быть в состоянии использовать RectangleArea class от апплета, ситуация немного отличается. Предположите, например, что у Вас есть апплет, AreaApplet, это использует class RectangleArea:

import java.applet.Applet;
import java.awt.*;

public class AreaApplet extends Applet {
    Rectangle r;

    public void init() {    
        int width = 10;
        int height = 5;

        r = new Rectangle(width, height);
    }

    public void paint(Graphics g) {
        g.drawString("The rectangle's area is " 
                      + RectangleArea.area(r), 10, 10);
    }
}

Этот апплет инстанцирует 10 x 5 прямоугольников и затем выводит на экран область прямоугольника при использовании метода RectangleArea.area.

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

Чтобы видеть, как это делается, давайте предполагать, что Вы связались AreaApplet в файле JAR под названием AreaApplet.jar и что class RectangleArea связывается в RectangleArea.jar. Для RectangleArea.jar, который будет обработан как расширение загрузки, RectangleArea.jar должен быть перечислен в заголовке Class-Path в декларации AreaApplet.jar. декларация AreaApplet.jar могла бы быть похожей на это, например:

Manifest-Version: 1.0
Class-Path: RectangleArea.jar

Значением заголовка Class-Path в этой декларации является RectangleArea.jar без определенного пути, указывая, что RectangleArea.jar располагается в том же самом каталоге как файл JAR апплета.

Больше о Заголовке Пути к классу

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

Class-Path: area.jar servlet.jar images/

В заголовке Class-Path любые URL, перечисленные, который не заканчивается '/', как предполагается, являются файлами JAR. URL, заканчивающиеся в '/', указывают на каталоги. В предыдущем примере images/ мог бы быть каталогом, содержащим ресурсы, необходимые апплету или приложению.

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

Class-Path: area.jar servlet.jar monitor.jar datasource.jar
  provider.jar gui.jar

Будущий выпуск может удалить ограничение наличия только одного экземпляра каждого заголовка, и ограничения строк только к 72 символам.

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

Установка Расширений Загрузки

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

Так как этот механизм расширяет базовый API платформы, его использование должно быть рассудительно применено. Это редко подходяще для интерфейсов, используемых единственным, или маленьким набором приложений. Все видимые символы должны следовать за обратным доменным именем и соглашениями иерархии class.

Основные требования - то, что и апплет и расширения, которые он использует, обеспечивают информацию о версии в их декларациях, и что они быть подписанными. Информация о версии позволяет Плагину Java гарантировать, что коду расширения ожидал версию апплет. Например, AreaApplet мог определить расширение areatest в своей декларации:

Manifest-Version: 1.0
Extension-List: areatest
areatest-Extension-Name: area
areatest-Specification-Version: 1.1
areatest-Implementation-Version: 1.1.2
areatest-Implementation-Vendor-Id: com.example
areatest-Implementation-URL: http://www.example.com/test/area.jar

Декларация в area.jar предоставила бы соответствующую информацию:

Manifest-Version: 1.0
Extension-Name: area
Specification-Vendor: Example Tech, Inc
Specification-Version: 1.1
Implementation-Vendor-Id: com.example
Implementation-Vendor: Example Tech, Inc
Implementation-Version: 1.1.2

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

keytool -genkey -dname "cn=Fred" -alias test  -validity 180

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

jarsigner AreaApplet.jar test
jarsigner area.jar test

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

Вот AreaDemo.html, который загружает апплет и заставляет код расширения быть загруженным и установленным:

<html>
<body>
  <applet code="AreaApplet.class" archive="AreaApplet.jar"/>
</body>
</html>

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

После перезапуска веб-браузера и загрузки та же самая веб-страница, только представляется диалоговое окно о подписывающем лице апплета, потому что area.jar уже устанавливается. Это - также истина, если AreaDemo.html открывается в различном веб-браузере (предполагающий, что оба браузера используют тот же самый JRE).

Для получения дополнительной информации об установке расширений загрузки, см. Развертывающиеся Расширения Java. Более подробный пример в Развертывающейся Платформе Носителей Java как Расширение Java.


Проблемы с примерами? Попытайтесь Компилировать и Выполнить Примеры: FAQ.
Жалобы? Поздравление? Предложения? Дайте нам свою обратную связь.

Предыдущая страница: Установленные Расширения
Следующая страница: Понимание Загрузки Класса Расширения