Spec-Zone .ru
спецификации, руководства, описания, API
Содержание документации

Руководство по Совместимости JAXP
для J2SE 6 Платформ

Содержание

Введение

Java 2 Платформы, Выпуск (J2SE) 1.4 Standared, включенный Темно-красная ссылочная реализация для JAXP 1.1. Платформа Java, Standard Edition (Java платформа SE) 6 включает ссылочную реализацию для JAXP 1.4 основанный на Apache библиотека Xerces.

Поскольку эти реализации, прибывшие от полностью различных кодовых баз, и потому что стандарт JAXP развился от 1.1 до 1.4, есть некоторые тонкие различия между реализациями, даже они оба соответствуют стандарту JAXP. Эти два фактора объединяются, чтобы создать проблемы совместимости, описанные в этом руководстве.

Новые функции и возможности

См. Информацию о версии.

ДОМ Левель 3

В то время как ссылочная реализация в J2SE 1.4 поддерживала ДОМА Левеля 2 API, реализация в J2SE 6 поддерживает ДОМА Левеля 3 семейства API. Этот раздел покрывает воздействие тех изменений на программах, которые использовали JAXP 1.1 ссылочных реализации:

Для получения дополнительной информации см. полный список изменений в ДОМЕ Левеле 3 приложения Изменений.

Методы, добавленные к интерфейсам ДОМА

В уровне 3 ДОМА дополнительные методы были определены в следующих интерфейсах:

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

Сохранение формата XML

Эти изменения влияют на приложение, которое читает в данных XML в ДОМА, делает модификации, и затем выписывает это в пути, который сохраняет исходное форматирование.

В JAXP 1.1, посторонний пробел был автоматически удален на вводе, и единственном свойстве (ignoringLexicalInfo) был установлен в false сохранить узлы объекта и узлы CDATA, например. Включая дополнительные узлы, сделанные ДОМОМ, несколько более сложным, чтобы обработать, но потому что они были там, добавляя пробельный вывод (добавление отступа и новые строки), произвел очень читаемую, отформатированную версию данных XML, которые близко приблизили ввод.

В JAXP 1.4, есть четыре API, что использование приложения, чтобы определить, насколько лексический (форматирование) информация доступна процессу, используя следующий DocumentBuilderFactory методы:

Значения по умолчанию для всех этих свойств false, который сохраняет всю лексическую информацию, необходимую, чтобы восстановить входящий документ в его исходной форме. Установка их всех к true позволяет Вам создавать самого простого ДОМА, таким образом, приложение может сосредоточиться на семантическом контенте данных, не имея необходимость волноваться о лексических деталях синтаксиса.

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

SAX 2.0.2

Следующее является изменениями, произведенными между SAX 2.0.0 и SAX 2.0.2, который мог бы влиять на совместимость.

Отметьте:
Одна точка совместимости также стоит упоминать. Распознавание пространства имен было выключено по умолчанию в J2SE 1.4 (JAXP 1.1). Для обратной совместимости та политика продолжается в J2SE 6 (JAXP 1.4). Однако, распознавание пространства имен включается по умолчанию в официальной реализации SAX в www.saxproject.org. В то время как не строго проблема совместимости с точки зрения JAXP, это - проблема, которая иногда становится неожиданностью.

Используя XSLT

Код, который использует стандартные API JAXP, чтобы создать и получить доступ к преобразователю XSL, не должен быть изменен. Вывод будет тем же самым, но будет вообще произведен намного быстрее, начиная с XSLTC компиляция преобразователя будет использоваться по умолчанию вместо интерпретации преобразователь Xalan.

Отметьте:
Не может быть никакой значительной разницы между производительностью Xalan и XSLTC для единственного выполнения на небольшом наборе данных, как тогда, когда Вы разрабатываете и тестируете таблицу стилей XSL. Но есть главный выигрыш в производительности при использовании XSLTC на чем-либо большем.

Программируемый Доступ к XPath Xalan

JAXP 1.4 обеспечивает стандартный API XPath для того, чтобы он оценил выражения XPath. Мы поощряем пользователей использовать этот API. Xalan-интерпретирующий не включается в ссылочную реализацию. Если приложение явно будет использовать API XPath Xalan, чтобы оценить автономное выражение XPath (тот, который не является частью таблицы стилей XSLT), то Вы должны будете загрузить и установить библиотеки Apache для Xalan.

Смены имени пакета

Это изменение не влияет на приложения, которые ограничиваются использованием стандартных API JAXP. Но приложения, которые получают доступ к специфичным для реализации функциям процессоров XML, определенных в версиях JAXP до 1.3, должны будут быть изменены.

Изменение имеет несколько эффектов на предыдущие приложения:

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

  2. Приложения, которые использовали внутренние API, которые от классов реализации Xalan должны изменить операторы импорта, которые предоставляли им доступ к тем API.

  3. Приложения, которые использовали внутренние API от Темно-красной реализации, должны быть повторно кодированы - идеально, при использовании более новых API JAXP или, в случае необходимости, при использовании API Xerces.

Что Измененный, и Почему

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

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

Решение начиная с JAXP 1.3 состоит в том, чтобы изменить названия пакета библиотек Apache, пользовавшихся в реализации. То изменение позволяет справочнику пользователя более новые библиотеки Apache в пути к классу, таким образом, разработчики приложений могут использовать их таким же образом, которые использовали бы любые другие дополнения к платформе Java.

Новые имена, данные пакетам Apache в JAXP 1.3 ссылочных реализации, показывают ниже:

Изменения на имена пакета JAXP

JAXP 1.1

Начиная с JAXP 1.3

org.apache.crimson

-/-
com.sun.org.apache.xerces.internal

org.apache.xml

com.sun.org.apache.xml.internal

Изменения на имена пакета XSLT

JAXP 1.1

Начиная с JAXP 1.3

org.apache.xalan
org.apache.xpath
org.apache.xalan.xsltc

com.sun.org.apache.xalan.internal
com.sun.org.apache.xpath.internal
com.sun.org.apache.xalan.internal.xsltc

Вопрос безопасности, Изложенный по Вложенным Определениям Объекта

В то время как XML не позволяет рекурсивные определения объекта, он действительно разрешает вложенные определения объекта, который производит потенциал для Атак "отказ в обслуживании" сервера, который принимает данные XML из внешних источников. Например, документ SOAP как следующий, который очень глубоко вложил определения объекта, может использовать 100 % процессорного времени и больших объемов памяти в расширениях объекта:

<?xml version="1.0" encoding ="UTF-8"?>
 <!DOCTYPE foobar[
 <!ENTITY x100 "foobar">
 <!ENTITY  x99 "&x100;&x100;">
 <!ENTITY  x98 "&x99;&x99;">
 ...
 <!ENTITY   x2 "&x3;&x3;">
 <!ENTITY   x1 "&x2;&x2;">
 ]>
<SOAP-ENV:Envelope xmlns:SOAP-ENV=...>
<SOAP-ENV:Body>
<ns1:aaa xmlns:ns1="urn:aaa" SOAP-ENV:encodingStyle="...">
<foobar xsi:type="xsd:string">&x1;</foobar>
</ns1:aaa>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope> 

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

Новое системное свойство, чтобы ограничить расширение объекта
Системное свойство entityExpansionLimit позволяет существующим приложениям ограничивать общее количество расширений объекта, не перекомпилировав код. Синтаксический анализатор бросает фатальную ошибку, как только он достиг предела расширения объекта. (По умолчанию предел устанавливается к 64000.)

Чтобы установить предел расширения объекта, используя системное свойство, используйте опцию как следование командной строки java: -DentityExpansionLimit=100000

Новое свойство синтаксического анализатора, чтобы отвергнуть DTD
Приложение может также установить свойство синтаксического анализатора http://apache.org/xml/features/disallow-doctype-decl в истину. Фатальная ошибка тогда бросается, если входящий XML-документ содержит объявление DOCTYPE. (Значение по умолчанию для этого свойства является ложью.) Это свойство обычно полезно для SOAP базируемые приложения, где сообщение SOAP не должно содержать Объявление Типа документа.
Новая функция Безопасной Обработки
JAXP 1.3 включает новую безопасную функцию обработки, в которой приложение может сконфигурировать SAXParserFactory или DocumentBuilderFactory, чтобы получить процессор XML, который ведет себя защищенным способом. Установка этой функции к истине устанавливает предел расширения объекта к 64000. Отметьте, что предел значения по умолчанию может быть увеличен, используя entityExpansionLimit системное свойство.



Oracle и/или его филиалы Авторское право © 1993, 2012, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами