org.xml.sax.SAXParseException: fin de archivo prematuro para * VÁLIDO * XML

Me estoy poniendo muy extraño "Fin de archivo prematuro". excepción para los últimos días en uno de nuestros servidores. El mismo XML de configuración funciona bien en otro servidor. Estamos utilizando Tomcat 5.0.28 en ambos servidores. Este código ha estado funcionando para las edades (más de 7 años), solo después de una caída reciente del servidor, enfrentamos este problema en uno de los servidores. No hay cambios en XML así como en el código de análisis de Java. :(org.xml.sax.SAXParseException: fin de archivo prematuro para * VÁLIDO * XML

La única diferencia es que puedo ver en las versiones de Java -

Problema del servidor versión java "1.6.0_16" Java (TM) SE Runtime Environment (build 1.6.0_16-b01) Java HotSpot (TM) de 64 bits del servidor VM (build 14.2-b01, modo mixto)

servidor de trabajo java version "1.6.0_07" Java (TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot (TM) 64- Bit servidor VM (build 10.0-b23, modo mixto)

Aquí está el código Java que ha estado trabajando durante varios años -

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); 
    } 
}

Y aquí es la excepción.

[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)

ya he intentado validar XML y no encontró errores allí. ¿Alguna idea de dónde más puedo buscar un posible problema?

¡Cualquier apuntador sería muy apreciado!

TIA, - Manish

Fuente

2012-06-20 Manish

1. ¿Cómo es el 'InputSource' construyeron? 2. ¿Qué tan grande es el 'XML'? 3. ¿El 'XML' proviene de un archivo local, de una URL, una base de datos, alguna otra fuente de transmisión? ¿Tal vez el socket se desconecta o el' InputStream' se cierra en el medio del análisis? – npe

¿Estás seguro de que cuando el servidor se bloqueó no agregó algunos caracteres especiales? Podría intentar incluir el XML de uno de sus servidores en funcionamiento y ver si funciona. – npinti

@npe - (1) El 'InputSource' se construye con' FileReader' - 'this.readSource (nueva InputSource (fr));' (2) XML es 108,1 KB de tamaño. Ha sido así desde hace mucho tiempo. (3) XML proviene del sistema de archivos local. También estoy sospechando si 'InputStream' se está cerrando en el medio. ¿Cómo puedo detectar eso? Y de nuevo, preguntándome por qué funcionó antes y ahora no :( @npinti - He utilizado XML fresco de SVN y también he probado la misma versión en el validador XML. * Es * XML válido. – Manish

Esto se resuelve. El problema estaba en otra parte. Otro código en el trabajo cron estaba truncando XML a 0 archivo de longitud. Me he encargado de eso.

Fuente

2013-02-11 10:17:31 Manish

¿Estás seguro de que el archivo XML está en la correcta codificación de caracteres? FileReader siempre usa la codificación predeterminada de la plataforma, por lo que si el servidor "en funcionamiento" tenía una codificación predeterminada de (digamos) ISO-8859-1 y el servidor "problemático" usa UTF-8 vería este error si el XML contiene Caracteres ASCII

¿Funciona si crea el InputSource desde un FileInputStream en lugar de un FileReader?

Fuente

2012-11-20 20:54:43

Es un problema con Java InputStream. Cuando se lee la secuencia una vez que el contador de posición de desplazamiento de archivo se mueve al final del archivo. En la lectura posterior utilizando la misma secuencia, obtendrá este error. Por lo tanto, debe cerrar y volver a abrir la transmisión de nuevo o llamar al inputStream.reset() para restablecer el contador de compensación a su posición inicial.

Fuente

2012-12-06 21:29:18 dadob051

lo intentó y no funcionó. – moldovean

En nuestro caso, era AndroidManifest.xml vacío.

Al actualizar Eclispe nos topamos con el usual trouble, y AndroidManifest.xml debe haber sido registrado en SVN por el script de construcción después de ser criticado.

Lo encontró compilando desde dentro de Eclipse, en lugar de hacerlo desde la línea de comandos.

Fuente

2014-10-26 12:51:32

Si el flujo de entrada no se cierra correctamente, esta excepción puede ocurrir. asegúrate de: Si inputstream utilizado no se utiliza "Antes" de alguna manera que el que está destinado a leer. es decir, si se lee por segunda vez desde el mismo flujo de entrada en una sola operación, la segunda llamada recibirá esta excepción. También asegúrese de cerrar el flujo de entrada en el bloque final o algo así.

Fuente

2015-08-11 22:30:13 supernova

Asegúrese de que no está consumiendo su inputstream en cualquier lugar antes de analizar. El código de muestra es el siguiente: la propuesta a continuación es httpresponse (es decir, la respuesta) y el contenido principal contiene StringEntity (i.e. getEntity())in form of inputStream(i.e. getContent()).

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

Fuente

2016-06-11 10:49:55

Esta excepción sólo ocurre si se está analizando una matriz de bytes cadena vacía/vacío.

a continuación es un fragmento sobre cómo reproducirlo:

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

Fuente

2016-10-14 09:35:49 Zo72

org.xml.sax.SAXParseException: fin de archivo prematuro para * VÁLIDO * XML

Respuesta

Cuestiones relacionadas