Случайная ошибка с конфигурацией XML-анализатора OpenSAML

1

Я запускаю webapp в Tomcat 8, который использует OpenSAML. Я одобрил Xerces в Tomcat, я проверил, что одобренный путь dir установлен правильно, кажется, что все работает нормально:

[ajp-apr-8009-exec-22] DEBUG org.opensaml.xml.Configuration - VM с использованием парсера JAXP org.apache.xerces.jaxp.DocumentBuilderFactoryImpl

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

OpenSAML требует XML-анализатор, который поддерживает JAXP 1.3 и DOM3. В настоящее время JVM настроен на использование анализатора Sun XML, который, как известно, является ошибкой и не может использоваться с OpenSAML. Пожалуйста, поддержите функциональную библиотеку JAXP (ы), такую как Xerces и Xalan. Инструкции о том, как одобрить новый парсер, см. Http://java.sun.com/j2se/1.5.0/docs/guide/standards/index.html.

    at org.opensaml.xml.Configuration.validateNonSunJAXP(Configuration.java:278)
    at org.opensaml.xml.parse.BasicParserPool.<init>(BasicParserPool.java:126)

Как только я начну получать ошибку, я получаю ошибку каждый раз, но я не смог выделить то, что нужно, чтобы вызвать проблему. (Редактирование: похоже, что это может быть связано каким-то образом с использованием docx4j, ошибки начинаются после запроса, который использует docx4j для генерации файла в виде словарного документа. Поскольку docx4j настолько зависит от XML, это может иметь смысл.)

В принципе, то, что делает validationNonSunJAXP(), довольно просто. Все, что он делает, это проверить имя класса для DocumentBuilderFactory, и если он начинается с "com.sun", он выдает ошибку.

Любые идеи о том, что может произойти, заставят виртуальную машину прекратить использование одобренной библиотеки?

Теги:
tomcat
docx4j
opensaml

1 ответ

1

docx4j манипулирует:

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

Вы можете видеть, что он делает, на странице https://github.com/plutext/docx4j/blob/master/src/main/java/org/docx4j/XmlUtils.java

javax.xml.parsers.SAXParserFactory

Таким образом, вы можете запретить docx4j касаться этого значения с помощью настроек свойств docx4j.

Мы обнаружили, что Crimson не удается проанализировать файлы docx4j XSLT, поэтому docx4j по умолчанию пытается использовать Xerces, где он включен в JDK. (В более поздних JDK может быть лучше)

Если вы не хотите этого, вы можете указать другое поведение через docx4j.properties:

  • docx4j.javax.xml.parsers.SAXParserFactory.donotset = true останавливает docx4j от изменения настройки или
  • javax.xml.parsers.SAXParserFactory позволяет вам указать, что вы хотите

Обратите внимание, что мы не восстанавливаем значение до исходного значения, так как мы хотим избежать использования Crimson для жизни приложения.

javax.xml.parsers.DocumentBuilderFactory

Это работает аналогично SAXParserFactory

Соответствующие свойства docx4j следующие:

  • docx4j.javax.xml.parsers.DocumentBuilderFactory.donotset
  • javax.xml.parsers.DocumentBuilderFactory

Мы не восстанавливаем значение до его первоначальной настройки (хотя, возможно, мы могли бы: нужно было бы проверить, всегда ли docx4j использует XmlUtils.getNewDocumentBuilder())

Поделиться
  • 0
    Поэтому, основываясь на вашем описании validateNonSunJAXP (), настройка одного из двух свойств docx4j DocumentBuilderFactory должна дать вам то, что вам нужно.
  • 0
    Спасибо, это была именно проблема. Включение donotset для DocumentBuilderFactory решает проблему. Похоже, что OpenSAML все еще устарел, если предположить, что поставляемые JDK библиотеки JAXP содержат ошибки, потому что, по крайней мере, в Sun / Oracle JDK они уже давно встраивают Xerces, просто встроенные xerces находятся под "com.sun". .org.apache.xerces ", поэтому он не проходит тест (просто ищет" com.sun "), даже если это xerces, что в теории должно работать.
Показать ещё 2 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню