[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    [jira] Created: (XMLBEANS-226) Exception "Unexpected end of file after null"
From:       "Peter lynch (JIRA)" <xmlbeans-dev () xml ! apache ! org>
Date:       2005-11-17 20:26:43
Message-ID: 1038666148.1132259203493.JavaMail.jira () ajax ! apache ! org
[Download RAW message or body]

Exception "Unexpected end of file after null"
---------------------------------------------

         Key: XMLBEANS-226
         URL: http://issues.apache.org/jira/browse/XMLBEANS-226
     Project: XMLBeans
        Type: Bug
  Components: DOM  
    Versions: Version 2.1, Version 2    
    Reporter: Peter lynch


The problem is best described here:
http://www.mail-archive.com/user%40xmlbeans.apache.org/msg00850.html

Additionally I will note that the identical problem happens with Tomcat 5.5.12 ( \
instead of Jetty). It is always reproducible. Using an InputStream or a \
BufferedReader.

I'd prefer to use Piccolo since it is faster but it seems the safeset thing to do is \
use another parser entirely until the problem is fixed.

So that searches in Jira are easier, I will paste the first part of the thread here \
as well:


------------ START http://www.mail-archive.com/user%40xmlbeans.apache.org/msg00850.html \
-------- Hi,

I am trying to upgrade my project which uses XMLBeans v1 to XMLBeans v2.

I have the following situation: a client (using commons-httpclient)
posts XML to a webserver (jetty), where the posted XML is parsed using
something like:

SomeXmlBeansGeneratedClass.Factory.parse(request.getInputStream());

After upgrading to XMLBeans v2, this gives the following exception on
every other request:

org.xml.sax.SAXParseException: Unexpected end of file after null
org.apache.xmlbeans.impl.piccolo.xml.Piccolo.reportFatalError(Piccolo.java:1038)
org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.java:723)
org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.java:3354)
org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1267)
org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1254)
org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345)
 org.outerx.daisy.x10Publisher.PublisherRequestDocument$Factory.parse(Unknown 
Source)
org.outerj.daisy.publisher.serverimpl.PublisherHttpConnector$PublisherHttpHandler.handle(PublisherHttpConnector.java:115)
 org.mortbay.http.HttpContext.handle(HttpContext.java:1565)
org.mortbay.http.HttpContext.handle(HttpContext.java:1517)
org.mortbay.http.HttpServer.service(HttpServer.java:954)
org.mortbay.http.HttpConnection.service(HttpConnection.java:814)
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981)
org.mortbay.http.HttpConnection.handle(HttpConnection.java:831)
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)

Thus the first request is OK, the second one gives this exception, the
third one is OK again, the fourth one again gives this exception etc.

After some investigation, I have tracked down the problem to Piccolo
which only closes the InputStream of the previous parse when doing a new
parse, i.e. the following in the class Piccolo:

public void parse(InputSource source) throws IOException, SAXException {
    try {
        reset();
        validateParseState();
        try {
            docEntity.reset(source);
            lexer.reset(docEntity);

whereby the docEntity.reset method does the close.

I tried to fix this by doing a docEntity.close() in the finally.
However, this then causes an NPE in PiccoloSaxLoader.postLoad where it
tries to get the encoding and version from the piccolo parser after the
parse finished. After temporarily disabling these lines, I found that
everything worked OK and I did not have the above exception anymore.

The reason I get this problem is probably specific to the Jetty
situation, as Jetty seems to reuse the same InputStream object between
different requests, and I could work around it by wrapping Jetty's input
stream in a custom input stream which ignores additional close calls,
but it would be nice if this was fixed in XMLBeans. I assume a user can
expect that XMLBeans does not keep references to the inputstream after
the parse finished.

Thanks in advance,

Bruno.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]                          [EMAIL PROTECTED]


------------ END http://www.mail-archive.com/user%40xmlbeans.apache.org/msg00850.html \
--------

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]