Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
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. Эти два фактора объединяются, чтобы создать проблемы совместимости, описанные в этом руководстве.
См. Информацию о версии.
В то время как ссылочная реализация в J2SE 1.4 поддерживала ДОМА Левеля 2 API, реализация в J2SE 6 поддерживает ДОМА Левеля 3 семейства API. Этот раздел покрывает воздействие тех изменений на программах, которые использовали JAXP 1.1 ссылочных реализации:
Для получения дополнительной информации см. полный список изменений в ДОМЕ Левеле 3 приложения .
В уровне 3 ДОМА дополнительные методы были определены в следующих интерфейсах:
Attr
Документ
DOMImplementation
Элемент
Объект
Узел
Текст
Добавленные методы только влияют на приложения, которые реализуют интерфейсы непосредственно, и только когда приложение перекомпилировано. У приложений, которые используют методы фабрики, чтобы получить классы реализации для этих интерфейсов, не будет никаких проблем.
Эти изменения влияют на приложение, которое читает в данных XML в ДОМА, делает модификации, и затем выписывает это в пути, который сохраняет исходное форматирование.
В JAXP 1.1, посторонний пробел был автоматически удален на вводе, и единственном свойстве (ignoringLexicalInfo) был установлен в false сохранить узлы объекта и узлы CDATA, например. Включая дополнительные узлы, сделанные ДОМОМ, несколько более сложным, чтобы обработать, но потому что они были там, добавляя пробельный вывод (добавление отступа и новые строки), произвел очень читаемую, отформатированную версию данных XML, которые близко приблизили ввод.
В JAXP 1.4, есть четыре API, что использование приложения, чтобы определить, насколько лексический (форматирование) информация доступна процессу, используя следующий DocumentBuilderFactory методы:
setCoalescing()
Преобразовать узлы CDATA в текстовый узел и добавить
к смежному текстовому узлу (если любой).
setExpandEntityReferences()
Развернуть узлы ссылки на сущность.
setIgnoringComments()
Проигнорировать комментарии.
setIgnoringElementContentWhitespace()
Проигнорировать пробел, который не является значительной частью
из контента элемента.
Значения по умолчанию для всех этих свойств false, который сохраняет всю лексическую информацию, необходимую, чтобы восстановить входящий документ в его исходной форме. Установка их всех к true позволяет Вам создавать самого простого ДОМА, таким образом, приложение может сосредоточиться на семантическом контенте данных, не имея необходимость волноваться о лексических деталях синтаксиса.
Отметьте:
Добавляя новые узлы, приложение должно добавить любое добавление отступа и новую строку, форматирующую, который необходим для удобочитаемости, так как это не обеспечивается автоматически.
Следующее является изменениями, произведенными между SAX 2.0.0 и SAX 2.0.2, который мог бы влиять на совместимость.
DeclHandler.externalEntityDecl теперь требует, чтобы синтаксический анализатор возвратил абсолютный системный идентификатор для непротиворечивости с DTDHandler.unparsedEntityDecl. Это может вызвать некоторые несовместимости.
В SAX 2.0.1, приложение может установить ErrorHandler, EntityResolver, ContentHandler, или DTDHandler к null. Это - расслабление предыдущего ограничения в SAX 2.0, который генерировал a NullPointerException (NPE) при таких обстоятельствах.
Таким образом, следующий код является законным в JAXP 1.3:
SAXParserFactory spf = SAXParserFactory.newInstance(); SAXParser sp = spf.newSAXParser(); XMLReader reader = sp.getXMLReader(); reader.setErrorHandler(null); reader.setContentHandler(null); reader.setEntityResolver(null); reader.setDTDHandler(null);
resolveEntity() метод в EntityResolver API теперь бросает IOException, так же как SAXException. (Прежде, чем, это только бросило SAXException.)
Огромное большинство приложений незатронуто этим изменением, потому что DefaultHandler класс реализации был изменен, чтобы объявить дополнительное исключение, и очень немного приложений используют DefaultHandler таким способом, которым они столкнутся с проблемой.
Единственным путем на приложение можно влиять, то, если оно переопределяет resolveEntity() метод и также вызывает super.resolveEntity(). В этом случае приложение не будет компилировать в J2SE 5, пока метод не будет изменен, чтобы обработать IOExceptions это super.resolveEntity() мог бросить.
Следующие новые функции распознаются:
http://xml.org/sax/features/external-general-entities
Включать внешние общие объекты.
http://xml.org/sax/features/external-parameter-entitiesВключать внешние объекты параметра и внешнее подмножество DTD.
и следующее новое свойство:
http://xml.org/sax/properties/xml-stringПолучить строку символов, связанных с текущим событием.
Для полного списка функций Xerces и свойств, см. и .
Отметьте:
Одна точка совместимости также стоит упоминать. Распознавание пространства имен было выключено по умолчанию в J2SE 1.4 (JAXP 1.1). Для обратной совместимости та политика продолжается в J2SE 6 (JAXP 1.4). Однако, распознавание пространства имен включается по умолчанию в официальной реализации SAX в . В то время как не строго проблема совместимости с точки зрения JAXP, это - проблема, которая иногда становится неожиданностью.
Код, который использует стандартные API JAXP, чтобы создать и получить доступ к преобразователю XSL, не должен быть изменен. Вывод будет тем же самым, но будет вообще произведен намного быстрее, начиная с XSLTC компиляция преобразователя будет использоваться по умолчанию вместо интерпретации преобразователь Xalan.
Отметьте:
Не может быть никакой значительной разницы между производительностью Xalan и XSLTC для единственного выполнения на небольшом наборе данных, как тогда, когда Вы разрабатываете и тестируете таблицу стилей XSL. Но есть главный выигрыш в производительности при использовании XSLTC на чем-либо большем.
JAXP 1.4 обеспечивает стандартный API XPath для того, чтобы он оценил выражения XPath. Мы поощряем пользователей использовать этот API. Xalan-интерпретирующий не включается в ссылочную реализацию. Если приложение явно будет использовать API XPath Xalan, чтобы оценить автономное выражение XPath (тот, который не является частью таблицы стилей XSLT), то Вы должны будете загрузить и установить библиотеки Apache для Xalan.
Это изменение не влияет на приложения, которые ограничиваются использованием стандартных API JAXP. Но приложения, которые получают доступ к специфичным для реализации функциям процессоров XML, определенных в версиях JAXP до 1.3, должны будут быть изменены.
Изменение имеет несколько эффектов на предыдущие приложения:
Значения свойств, которые использовались, чтобы получить доступ к внутренним реализациям, должны быть изменены.
Приложения, которые использовали внутренние API, которые от классов реализации Xalan должны изменить операторы импорта, которые предоставляли им доступ к тем API.
Приложения, которые использовали внутренние 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 |
|---|---|
|
|
|
|
|
|
Изменения на имена пакета XSLT
|
JAXP 1.1 |
Начиная с JAXP 1.3 |
|---|---|
|
|
|
В то время как 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 системное свойство.