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

List:       xmlbeans-dev
Subject:    [jira] Commented: (XMLBEANS-226) Exception "Unexpected end of file
From:       "Richard Garris (JIRA)" <xmlbeans-dev () xml ! apache ! org>
Date:       2008-04-04 19:03:28
Message-ID: 993116663.1207335808661.JavaMail.jira () brutus
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/XMLBEANS-226?page=com.atlassian.jira.plugi \
n.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585704#action_12585704 ] 

Richard Garris commented on XMLBEANS-226:
-----------------------------------------

Hi everyone ---

I found an elegant solution to this issue of InputStream cleanup. Apache Commons IO \
released v1.4 which includes an AutoCloseInputStream wrapper which cleans up \
InputStreams once they have been read.

http://commons.apache.org/io/api-release/org/apache/commons/io/input/AutoCloseInputStream.html


We are using this IBM WAS 6.1 and this appears to resolve this bug. 

Does anyone see any issue with using this fix?

Thanks.

Rich

> Exception "Unexpected end of file after null"
> ---------------------------------------------
> 
> Key: XMLBEANS-226
> URL: https://issues.apache.org/jira/browse/XMLBEANS-226
> Project: XMLBeans
> Issue Type: Bug
> Components: DOM
> Affects Versions: Version 2, Version 2.1
> 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.
-
You can reply to this email to add a comment to the issue online.


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