SAXParseException, которое происходит только локально. Работает на веб-серверах

Я пишу тест junit, который тестирует и старую часть кода. Этот код работает на наших веб-серверах iplanet и наших локальных серверах Tomcat и работает без проблем. Однако при запуске теста JUNIT я получаю это исключение.

Справочная информация: он извлекает файл XSL из JAR, а затем преобразует его в документ xml, который считывается из файла ресурсов.

Я пытался изменить фабрики трансформаторов, изменить кодировку и проверить все файлы на наличие нулевых символов с помощью шестнадцатеричного редактора. Любые идеи?

[Неустранимая ошибка] :2251:46: Недопустимый символ XML (Unicode: 0x0) был обнаружен в значении атрибута «тест», а элемент — «xsl:when». Идентификатор системы неизвестен; Строка № 2251; Колонка №46; org.xml.sax.SAXParseException; номер строки: 2251; номер столбца: 46; Недопустимый символ XML (Unicode: 0x0) был обнаружен в значении атрибута «тест», а элемент — «xsl:when».

**ОБНОВЛЕНИЕ Я обнаружил, что если я использую папку класса проекта, в которой хранится XSL, и перемещаю ее по зависимости от jar, он работает, но если он использует xsl из jar, он ломается


junit xslt xalan saxparseexception
person user1943539    schedule 02.01.2013    source источник
comment
Убедитесь, что все версии библиотек на тестовом хосте JUnit соответствуют версиям на ваших серверах Tomcat и iPlanet :)   -  person paulsm4    schedule 02.01.2013
comment
Они делают. Это было первое, на что я посмотрел.   -  person user1943539    schedule 02.01.2013

Ответы (3)


arrow_upward
0
arrow_downward

ПРЕДЛОЖЕНИЯ:

1) Убедитесь, что все версии вашей библиотеки совпадают.

2) Я подозреваю, что «Обнаружен недопустимый символ XML (Unicode: 0x0)» может быть вызвано несколькими совершенно разными причинами. Вы должны исследовать каждый из них.

3) Во-первых, самое очевидное - проверьте ввод на наличие нулевого символа :)

4) Во-вторых, проверьте свою кодировку — возможно, ваш отправитель пишет UTF-16, а ваш читатель ожидает UTF-8. Вот хорошая ссылка:

* Ошибка из-за недопустимых символов XML в Java

Это проблема с кодировкой. Либо вы читаете входной поток как UTF8, а это не так, либо наоборот.

Кодировку следует указывать явно при чтении содержимого. Например. с помощью

new InputStreamReader(getInputStream(), "UTF-8")

Другой проблемой может быть кот. Попробуйте добавить URIEncoding="UTF-8" в настройки соединителя вашего tomcat в файле server.xml

5) Основной причиной также может быть сбой чтения или отсутствие какого-либо объекта. Возможно, отсутствует определение.

В: Что такое «SystemId»? Из-за чего он может «пропасть»?

6) Одна из возможностей заключается в том, что "resolveEntity()" не работает:

InputSource resolveEntity(String publicId, String systemId)

Вот пара ссылок по этой проблеме:

7) Обе эти ссылки предполагают, что «resolveEntity() может дать сбой, потому что вы не можете подключиться к указанному хосту. Проверьте имена сетевых хостов, указанные в вашем XML, и убедитесь, что вы можете «пинговать» их.

person paulsm4    schedule 02.01.2013
comment
Я не уверен, что это означает под systemId. Я видел, что перечисленные с этой ошибкой другие места. Я не думаю, что что-то пропало, так как точный код отлично работает на серверах. Я проверю свой код, чтобы убедиться, что нет небольшого фрагмента кода, который запускается перед тестовым кодом, который может вызвать это. - person user1943539; 02.01.2013

arrow_upward
0
arrow_downward

Если он дошел до строки 2251, это убедительно свидетельствует о том, что что-то не так с содержимым файла в этом месте. Если с файлом в этом месте все в порядке, мое следующее предположение будет заключаться в том, что что-то не так с парсером. Я знаю, это звучит безумно, но синтаксический анализатор XML, встроенный в JDK, содержит серьезные ошибки, и я хотел бы проверить, исчезнет ли проблема, если вместо нее установить версию Xerces для Apache. Во многих случаях это просто вопрос размещения соответствующих JAR-файлов в каталоге lib/endorsed установки JDK.

person Michael Kay    schedule 02.01.2013
comment
Спасибо, убрал часть ошибок. Теперь возникает другая проблема: конечный тег для типа элемента xsl:text должен заканчиваться разделителем '›'. Я проверил, и «›» находится в том месте, где он говорит, что это не так. - person user1943539; 03.01.2013
comment
Я взял файл xsl и файл XML, с которым он был преобразован, и использовал онлайн-преобразователь, и он отлично сработал. - person user1943539; 03.01.2013
comment
Очевидно, происходит что-то странное, и мы не сможем определить это без более полной информации. - person Michael Kay; 07.01.2013

arrow_upward
0
arrow_downward

Это было вызвано тем, что файлы XSL, которые я пытался преобразовать, все еще находились в JAR. Сначала мне нужно было, чтобы Maven извлек файлы в целевой каталог.

person user1943539    schedule 26.06.2013