Uploaded image for project: 'XMLBeans'
  1. XMLBeans
  2. XMLBEANS-226

Exception "Unexpected end of file after null"

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: Version 2, Version 2.1
    • Fix Version/s: None
    • Component/s: DOM
    • Labels:
      None

      Description

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

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                peterlynch Peter lynch
              • Votes:
                8 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated: