[jira] Commented: (XMLBEANS-226) Exception "Unexpected end of file after null"

["Andy DePue (JIRA)" <xm...@xml.apache.org>]

    [ http://issues.apache.org/jira/browse/XMLBEANS-226?page=comments#action_12366234 ] 

Andy DePue commented on XMLBEANS-226:
-------------------------------------

I'm running into this same issue.  I have code that assumes the InputStream is not retained and ensures it is closed once parsing has finished, ultimately leading to an exception the next time something is parsed.

> 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