Org.xml.sax.SAXParseException: преждевременный конец файла для * VALID * XML

Мне становится очень странно "Преждевременный конец файла". исключение за последние несколько дней на одном из наших серверов. Такая же конфигурация XML отлично работает на другом сервере. Мы используем Tomcat 5.0.28 на обоих этих серверах. Этот код работает целую вечность (7+ лет), только после недавнего сбоя сервера мы столкнулись с этой проблемой на одном из серверов. Никаких изменений в XML, а также в Java-синтаксическом коде нет.: (

Единственное отличие, которое я вижу в версиях Java -

Сервер проблем java-версия "1.6.0_16" Java (TM) SE Runtime Environment (сборка 1.6.0_16-b01) Java HotSpot (TM) 64-разрядная серверная VM (сборка 14.2-b01, смешанный режим)

Рабочий сервер java-версия "1.6.0_07" Java (TM) SE Runtime Environment (сборка 1.6.0_07-b06) Java HotSpot (TM) 64-разрядная серверная VM (сборка 10.0-b23, смешанный режим)

Вот код Java, который работал несколько лет -

private void readSource(final InputSource in ) {
    try {
        DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
        DocumentBuilder db = dbf.newDocumentBuilder();
        Document doc = db.parse(in);
        Element elt = doc.getDocumentElement();

        this.readElement( elt );
    } catch ( Exception ex ) {
        ex.printStackTrace();
        throw new ConfigurationException( "Unable to parse configuration information", ex );
    }
}

И вот исключение.

[Fatal Error] :-1:-1: Premature end of file.
org.xml.sax.SAXParseException: Premature end of file.
        at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
        at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
        at com.circus.core.Configuration.readSource(Configuration.java:706)

Я уже пробовал проверять XML и не обнаружил там ошибок. Любая идея, где еще я могу найти возможную проблему?

Любые указатели будут высоко оценены!

ТИА, - Маниш

Ответ 1

Это разрешено. Проблема была в другом месте. Другим кодом в задании cron было усечение XML файла длиной до 0. Я позаботился об этом.

Ответ 2

Это проблема с Java InputStream. Когда поток считывается после того, как счетчик позиции смещения файла перемещается в конец файла. При последующем чтении с использованием того же потока вы получите эту ошибку. Поэтому вам нужно снова закрыть и снова открыть поток или вызвать inputStream.reset() в reset счетчик смещения в исходное положение.

Ответ 3

Это исключение происходит только в том случае, если вы разбираете пустой массив строк/пустых байтов.

ниже - фрагмент о том, как его воспроизвести:

String xml = ""; // <-- deliberately an empty string.
ByteArrayInputStream xmlStream = new java.io.ByteArrayInputStream(xml.getBytes());
Unmarshaller u = JAXBContext.newInstance(...)
u.setSchema(...);
u.unmarshal( xmlStream ); // <-- here it will fail

Ответ 4

Вы уверены, что XML файл находится в правильной кодировке символов? FileReader всегда использует кодировку по умолчанию для платформы, поэтому, если "рабочий" сервер имел кодировку по умолчанию (скажем) ISO-8859-1, а "проблемный" сервер использует UTF-8, вы увидите эту ошибку, если XML содержит какие-либо не-ASCII-символы.

Работает ли он, если вы создаете InputSource из FileInputStream вместо FileReader?

Ответ 5

Пожалуйста, убедитесь, что вы не потребляете ваш inputstream где-либо перед синтаксическим разбором. Пример кода следующий: нижеуказанная реакция httpresponse (т.е. ответ), а основное содержимое содержит внутри StringEntity (i.e. getEntity())in form of inputStream(i.e. getContent()).

InputStream rescontent = response.getEntity().getContent();
tsResponse=(TsResponse) transformer.convertFromXMLToObject(rescontent );

Ответ 6

Если входной поток не закрыт должным образом, это исключение может произойти. убедиться: Если используемый входной поток не используется "До" каким-то образом, то где вы собираетесь читать. т.е. если читать 2-й раз из того же входного потока в одной операции, то второй вызов получит это исключение. Также убедитесь, что закрыл входной поток в блоке finally или что-то в этом роде.

Ответ 7

В нашем случае это был пустой AndroidManifest.xml.

Во время обновления Eclispe мы столкнулись с обычной проблемой, и AndroidManifest.xml, должно быть, был проверен в SVN с помощью сборки script после того, как был сбит.

Найден его путем компиляции из Eclipse, а не из командной строки.