Изменение стандартной реализации org.w3c.dom.Document - PullRequest
Новая
       14

Изменение стандартной реализации org.w3c.dom.Document

2 голосов
/ 10 ноября 2010

Мне нужно изменить реализацию по умолчанию в моем проекте на org.w3c.dom.Document.

Я перешел по этой ссылке изменить реализацию по умолчанию для: 

javax.xml.parsers.DocumentBuilderFactory
javax.xml.parsers.SAXParserFactory
javax.xml.transform.TransformerFactory

Я создал 3 файла с вышеуказанными именами в META-INF/services и вставил в каждую следующие строки:

В файле: javax.xml.parsers.DocumentBuilderFactory Я положил: com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl

В файле: javax.xml.parsers.SAXParserFactory Я положил: com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl

В файле: javax.xml.transform.TransformerFactory Я положил: org.apache.xalan.processor.TransformerFactoryImpl

Но когда я развернул сервер Oracle Application Server, я понял, что класс реализации org.w3c.dom.Document равен: oracle.xml.parser.v2.XMLDocument вместо com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl, который печатается при разработке на Jetty.

Я занимаюсь разработкой на Jetty и внедряю на сервере приложений Oracle.

Ответы [ 3 ]

1 голос
/ 10 ноября 2010

Возможно, реализация oracle.xml.parser.v2.XMLDocument для org.w3c.dom.Document найдена до com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl загрузчиком классов. Проверьте, возможно ли исключить реализацию Oracle, найдите файл, который содержит класс. Это может быть расположено в папке «на уровне контейнера», а ваша реализация в папке «на уровне приложения».

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

1 голос
/ 10 ноября 2010

Звучит так, будто ты поступаешь правильно. Но может быть проще использовать метод системных свойств ... по крайней мере, пока вы не сможете выяснить, что не так с методом "services".

0 голосов
/ 12 февраля 2015

Обратите внимание на две вещи:
1.com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl имеет подсказку для вас: это внутренняя реализация (в отличие от публичного API).Он подвержен изменениям и не должен быть главным выбором для развития производства.
2.Я обнаружил, что com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl - лучшая реализация, которая отвечает всем моим потребностям, и, насколько я могу судить, она соответствует спецификации.

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

Вот мой опыт:

игра с META-INF /Службы и порядок JAR в classpath казались хаком, работали еще хуже и, в конце концов, я отошел от этого подхода.Вот почему у меня это не сработало: на пути к классам было более 2-х сторонних реализаций, поэтому не было надежды получить .xerces.internal. по умолчанию.Однако, указав его так, как System Property, переопределит его для всего, что не сработало для сторонних продуктов.

• • • В итоге я создал свойство и загрузил точную фабрику, которую явно хотел, без , опираясь на механизм поиска через META-INF / services и системные свойства.

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

...