[ http://issues.apache.org/jira/browse/XMLBEANS-226?page=comments#action_12357933 ]
Peter lynch commented on XMLBEANS-226: -------------------------------------- One workaround as stated in the original post is to wrap the BufferedReader in the request with a "NonClosingBufferedReader". Override the close() method to do a noop and in the servlet finally block call a 'forceClose()' to clean things up in the servlet ( which calls the real BufferedReader.close() method ). > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
