Изменение реализации по умолчанию org.w3c.dom.Document

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

Я последовал this link изменить реализацию по умолчанию:

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.

источник

2010-11-10 Muhammad Hewedy

Похоже, вы поступаете правильно. Но проще всего использовать метод системных свойств ... по крайней мере, пока вы не поймете, что происходит с методом «services».

источник

2010-11-10 09:50:16

Механизм обслуживания - это компоненты, которые предоставляют услугу, объявляющую, что они это делают. Речь идет о предоставлении выбора. Это * не * о том, чтобы указать *, который * выбор сделать, и полагаться на упорядочение пути к нему, чтобы использовать его, чтобы сделать это, похоже на kludge для меня. Метод свойств системы - это способ сделать явный выбор, и поэтому это правильный способ сделать это здесь. –

@Tom Anderson - в защиту ОП мое чтение связанного документа заключается в том, что подход «сервисов» должен работать. И я нашел другие поисковые запросы, которые предполагают, что это верно и для OAS. Тем не менее, я должен признать, что способ формулирования документа оставляет сомнение в некотором роде, и я не мог найти конкретную документацию OAS. –

Да, вы совершенно правы. Сервисный подход действительно должен работать повсюду, поскольку он является частью JRE. Я просто думаю, что лучше быть явным. –

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

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

источник

2010-11-10 10:12:16 Kennet

Ya, я знаю, что это проблема .... упорядочение JARS на пути к классам .. но неважно, я развертываю на prod-сервере, у которого есть другое приложение, которое работает, что означает, что я не могу ничего изменить в «container» -wdie "configs :) –

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

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

Вот мой опыт:

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

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

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

источник

2015-02-12 01:02:57

Изменение реализации по умолчанию org.w3c.dom.Document

ответ

Смежные вопросы