Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
J2SE 1.4 платформы, включенные "Темно-красная" ссылочная реализация для JAXP 1.1. J2SE 5 платформ включает ссылочную реализацию для JAXP 1.3 основанный на Apache библиотека "Xerces".
Поскольку эти реализации, прибывшие от полностью различных кодовых баз, и потому что стандарт JAXP развился от 1.1 до 1.3, есть некоторые тонкие различия между impementations, даже они оба соответствуют стандарту JAXP. Эти два фактора объединяются, чтобы создать проблемы совместимости, описанные в этом руководстве.
Однако, в то время как приложения XML, записанные для 1.4, действительно переносят некоторые несовместимости, JAXP 1.3 в
J2SE 5 платформ обеспечивает некоторые неотразимые преимущества:
Это - хорошие новости. Дурные вести - то, что некоторые проблемы совместимости пережили все попытки уничтожения. Остаток от этого документа обсуждает те проблемы.
В то время как ссылочная реализация в J2SE 1.4 поддерживала ДОМА Левеля 2 API, реализация в J2SE 5 поддерживает ДОМА Левеля 3 семейства API. Этот раздел покрывает воздействие тех изменений на программах, которые использовали JAXP 1.1 ссылочных реализации:
Для получения дополнительной информации см. полный список изменений в ДОМЕ Левеле 3 приложения .
В уровне 3 ДОМА дополнительные методы были определены в следующих интерфейсах:
Добавленные методы только влияют на приложения, которые реализуют интерфейсы непосредственно, и только тогда, когда приложение перекомпилировано. У приложений, которые используют методы фабрики, чтобы получить классы реализации для этих интерфейсов, не будет никаких проблем.
Эти изменения влияют на приложение, которое читает в данных XML в ДОМА, делает модификации, и затем выписывает это в пути, который сохраняет исходное форматирование.
В JAXP 1.1, посторонний пробел был автоматически удален на вводе, и единственное свойство (ignoringLexicalInfo) было установлено в ложь сохранить узлы объекта и узлы CDATA, например. Включая дополнительные узлы, сделанные ДОМОМ, несколько более сложным, чтобы обработать, но потому что они были там, добавляя пробельный вывод (добавление отступа и новые строки), произвел очень читаемую, отформатированную версию данных XML, которые близко приблизили ввод.
В JAXP 1.3, есть четыре API, что использование приложения, чтобы определить, насколько лексический (форматирование) информация доступна процессу, используя следующие методы DocumentBuilderFactory:
Значения по умолчанию для всех этих свойств являются ложью, которая сохраняет всю лексическую информацию, необходимую, чтобы восстановить входящий документ в его исходной форме. Установка их всех к истине позволяет Вам создавать самого простого ДОМА, таким образом, приложение может сосредоточиться на семантическом контенте данных, не имея необходимость волноваться о лексических деталях синтаксиса.
Отметьте:
Добавляя новые узлы, приложение должно добавить любое добавление отступа и новую строку, форматирующую, который необходим для удобочитаемости, так как это не обеспечивается автоматически.
Следующее является изменениями, произведенными между SAX 2.0.0 и SAX 2.0.2, который мог бы влиять на совместимость.
DeclHandler.externalEntityDecl теперь требует, чтобы синтаксический анализатор возвратил абсолютный системный идентификатор для непротиворечивости с DTDHandler.unparsedEntityDecl. Это может вызвать некоторые несовместимости.В SAX 2.0.1, приложение может установить ErrorHandler, EntityResolver, ContentHandler, или DTDHandler к нулю. Это - расслабление предыдущего ограничения в SAX 2.0, который генерировал 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);
Огромное большинство приложений незатронуто этим изменением, потому что класс реализации DefaultHandler был изменен, чтобы объявить дополнительное исключение, и очень немного приложений используют DefaultHandler таким способом, которым они столкнутся с проблемой.
Единственным путем на приложение можно влиять, то, если оно переопределяет resolveEntity () метод и также вызывает super.resolveEntity (). В этом случае приложение не будет компилировать в J2SE 5, пока метод не будет изменен, чтобы обработать IOExceptions, который мог бросить super.resolveEntity ().
и следующее новое свойство:
Для полного списка функций Xerces и свойств, см. и .
Отметьте:
Одна точка совместимости также стоит упоминать. Распознавание пространства имен было выключено по умолчанию в J2SE 1.4 (JAXP 1.1). Для обратной совместимости та политика продолжается в J2SE 5 (JAXP 1.3). Однако, распознавание пространства имен включается по умолчанию в официальной реализации SAX в . В то время как не строго проблема совместимости с точки зрения JAXP, это - проблема, которая иногда становится неожиданностью.
Код, который использует стандартные API JAXP, чтобы создать и получить доступ к преобразователю XSL, не должен быть изменен. Вывод будет тем же самым, но будет вообще произведен намного быстрее, начиная с XSLTC компиляция преобразователя будет использоваться по умолчанию вместо интерпретации преобразователь Xalan.
Отметьте:
Нет никакой значительной разницы между производительностью Xalan и XSLTC для единственного выполнения на небольшом наборе данных, как тогда, когда Вы разрабатываете и тестируете таблицу стилей XSL. Но есть главный выигрыш в производительности при использовании XSLTC на чем-либо большем.
JAXP 1.3 обеспечивает стандартный API XPath для того, чтобы он оценил выражения XPath. Мы поощряем пользователей использовать этот API. Xalan-интерпретирующий не включается в ссылочную реализацию. Если приложение явно будет использовать API XPath Xalan, чтобы оценить автономное выражение XPath (тот, который не является частью таблицы стилей XSLT), то Вы должны будете загрузить и установить библиотеки Apache для Xalan, поместить их в путь к классу.
Это изменение не влияет на приложения, которые ограничиваются использованием стандартных API JAXP. Но приложения, которые получают доступ к специфичным для реализации функциям процессоров XML, определенных в предыдущих версиях JAXP, должны будут быть изменены, чтобы принять во внимание имена пакета, которые изменились в JAXP 1.3.
Изменение имеет несколько эффектов на предыдущие приложения:
В J2SE 1.4, фактом, что JAXP был встроен в платформу Java, было нечто, вызывающее смешанные чувства. С одной стороны приложение могло положиться на тот факт, что это было там. На другом, большинство приложений необходимые функции и исправления ошибок, которые были доступны в более поздних версиях.
Но добавляя новый libarires, имеемый никакой эффект, потому что внутренние классы всегда имеют приоритет по пути к классу. Решение для той проблемы в 1.4 состояло в том, чтобы использовать подтвержденный механизм стандартов. Однако, это было новым механизмом, и тем, которое часто помещало дополнительное бремя в конечного пользователя, так же как разработчика приложений.
Решение в JAXP 1.3 ссылочных имени состоит в том, чтобы изменить названия пакета библиотек Apache, пользовавшихся в реализации. То изменение позволяет Вам ссылочные более новые библиотеки Apache в пути к классу, таким образом, разработчики приложений могут использовать их таким же образом, которые использовали бы любые другие дополнения к платформе Java.
Новые имена, данные пакетам Apache в JAXP 1.3 ссылочных реализации, показывают ниже:
| JAXP 1.1 |
JAXP 1.3 |
|
| JAXP | org.apache.crimson |
-/- com.sun.org.apache.xerces.internal |
| org.apache.xml | com.sun.org.apache.xml.internal | |
| XSLT | 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 |
Приложения, которые определение системных свойств на командной строке с-D, в lib/jaxp.properties файле JRE, или твердым кодированием их в приложение, обычно делает так, чтобы получить доступ к функциональности, которая не присутствует в стандартных API.
JAXP 1.3 содержит много новых дополнений. Обновляя такие приложения, желательно искать стандартные API в javax.xml.* пакетах, которые сделают то же самое задание, потому что это - лучший способ удержаться от необходимости изменить приложение в будущем. Если это совершенно необходимо (или из-за ограничений функциональности или из-за нехватки времени, чтобы исследовать новые API), значения свойств могут быть изменены, преобразовывая имена пакета старого формата в формат:
org.apache.somePackage-> com.sun.org.apache. SomePackage.internal
Точно так же внутренние классы реализации все использование новые имена пакета. Если Ваше приложение использует implementaton классы (оно не было должно!) те имена пакета должны будут измениться, также.
В то время как 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 системное свойство.
