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

Кэширование апплета

Этот раздел затрагивает следующие темы:

Кэширование Опции
Безопасность
Известные Проблемы

Кэширование Опции

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

Альтернативная форма кэширования апплета обеспечивается, который позволяет апплету deployer решать, должен ли апплет быть липким, липкий апплет помещается в дисковый кэш, которым, создаваемый и управляет Плагин Java, который не может перезаписать браузер. Единственное время липкий апплет загружается после кэширования, - то, когда это обновляется на сервере. Иначе апплет всегда доступен для быстрой загрузки. Апплеты, обеспечивающие приложения основного бизнеса, должны быть сделаны липкими, чтобы улучшить производительность запуска.

Эта опция активируется включением cache_archive, cache_version , и cache_archive_ex значения в OBJECT/EMBED тегируйте как описано ниже.

Отметить

.jar файлы, определенные с archive атрибут также кэшируется в этом липком кэше.

cache_archive

Атрибут cache_archive содержит список файлов, которые будут кэшироваться:

<PARAM NAME="cache_archive" VALUE="a.jar,b.jar,c.jar">

Как archive приписывают в теге APPLET, списке .jar файлы в атрибуте cache_archive не содержат полный URL, но всегда загружаются с codebase.

cache_version

cache_version является дополнительным атрибутом. Если использующийся, это содержит список версий файла, которые будут кэшироваться:

<PARAM NAME="cache_version" VALUE="1.2.0.1, 2.1.1.2, 1.1.2.7">

Каждый номер версии находится в форме xxxx.xxxx.xxxx.xxxx, где x шестнадцатеричное число. Каждый номер версии соответствует соответствующему .jar файл в cache_archive.

cache_archive_ex

Чтобы позволить предварительно загружать .jar файлы, параметр HTML cache_archive_ex может использоваться. Этот параметр позволяет Вам определять ли .jar файл должен быть предварительно загружен; дополнительно версия .jar файл может также быть определен. VALUE для cache_archive_ex имеет следующий формат:

VALUE="<jar_file_name>;<preload(optional)>;<jar_file_version(optional)>,<jar_file_name>;
       <preload(optional)>;<jar_file_version(optional)>,..."

Дополнительные теги preload и jar_file_version может появиться после jar_file_name в любом порядке, разделенном разделителем";".","разделяет многократные записи.

Следующие шоу, как эти теги могли бы использоваться в странице HTML:

 <OBJECT .... <PARAM NAME="archive" VALUE="a.jar">
 <PARAM NAME="cache_archive" VALUE="b.jar, c.jar, d.jar">
 <PARAM NAME="cache_version" VALUE="0.0.0.1, 0.0.2A.1, 0.3D.22.FFFE">
 <PARAM NAME="cache_archive_ex" VALUE="applet.jar;preload, util.jar;preload;0.9.0.AC1, tools.jar;0.9.8.7F">
 </OBJECT>

In the above example, a.jar is specified in archive, whereas b.jar, c.jar and d.jar are specified in cache_archive. The versions are also specified for b.jar, c.jar, and d.jar as 0.0.0.1, 0.0.2A.1, and 0.3D.22.FFFE, respectively. In cache_archive_ex, applet.jar is specified to be pre-loaded. util.jar is also specified to be pre-loaded but along with the version. For tools.jar, only version is specified.

Java Plug-In doesn't compare the versions if they are not specified for all the .jar files specified in HTML parameter cache_archive. If cache_archive is used without cache_version, the .jar files specified in cache_archive are treated no differently than the .jar files specified in HTML parameter archive. Similar treatment is given to .jar files specified in cache_archive_ex when preload and version options are not provided.

Class files and resources will be searched in the following order from the .jar files specified by the HTML parameters

cache_archive_ex
cache_archive
archive

Applet Caching Update Algorithm

By default, without the cache_version attribute, applet caching will be updated if:

The cache_archive has not been cached before, or
The "Last-Modified" value of the cache_archive on the web server is newer than the one stored locally in the applet cache, or
The "Content-Length" of the cache_archive on the web server is different from the one stored locally in the applet cache.

However, in some situations, the "Last-Modified" value returned from the web server through HTTP/HTTPS may not reflect the actual version of the applets. For example, if the web server crashes and all the files are restored, the cache_archive may have a different modification date on the server. Even if the cache_archive has not been updated, it will still force all the Java Plug-in clients to download the cache_archive again.

To strongly enforce the version update, it is recommended that the applet deployer use the cache_version attribute.

If cache_version is used, applet caching will be updated if the cache_version for the cache_archive is larger than the one stored locally in the applet cache. Note that the version number is used for triggering an update; there is no actual version number attached to the .jar file on the web server. In fact, unless version is used to trigger an update, it is possible the applet on the web server could be updated without the applet in cache_archive.

Using cache_version eliminates the need to connect to the web server to obtain "Modification-Date" and "Content-Length" of the cache_archive. In most cases this will speed up performance.

Security

Although sticky applets are cached locally, they will still conform to the security policy defined by their original codebase and signer.

Versioning Support

Java Plug-in 6 applets can use the JNLP Version Download protocol for launching JAR resources listed in the HTML file. Versioning also supports JarDiff. To use versioning support use the archive_x tag where x specifies a number. The following is the syntax of the archive_x tag.

First value must be the jar filename
Each value must be separated by comma
Use preload to indicate preloading of the jar file
version= is used to specify the version string for the jar file request

The following are the various ways in which the archive_x tag can be used.

<PARAM NAME="archive_1" VALUE="a.jar, preload, version=2.0+">

The + sign after the version indicates the Java Plug-in to request for a jar file whose version is equal to or higher than the specified version

<PARAM NAME="archive_1" VALUE="a.jar, preload, version=2.0*">

The * sign after the version indicates the Java Plug-in to request for a jar file whose version begins with 2.0, e.g 2.0.1 or 2.0.2

<PARAM NAME="archive_2" VALUE="b.jar, version=0.0.0.3">

This allows Java Plug-in to request for a jar file whose version is exactly 0.0.0.3

Note

The archive_x tag is ignored if it found within the cache_archive, cache_version and cache_archive_ex tag.

Applets using JNLP style version support should use the JNLPDownloadServlet to host the applet resources. More information about JNLP Version Download protocol and JNLPDownloadServlet is available in the JNLP Guide.

Known Issues

Caching of the .jar files specified in the manifest's Class-Path variable using Java Plug-in's cache is currently not supported.
The path specified in the cache_archive must be a relative URL to the applet's codebase. Full URLs are not supported in cache_archive.
The "java.io.IOException: Caching not supported for ..." is thrown because Java Plug-in could not get the expiration and last-modification dates for a given JAR file from the web server. If the Java Plug-in cannot get the date information, the JAR file is downloaded every time it is used.

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