[ http://issues.apache.org/jira/browse/XMLBEANS-226?page=comments#action_12366382 ]
Radu Preotiuc-Pietro commented on XMLBEANS-226: ----------------------------------------------- I think this one is better left for the Piccolo guys to deal with. I guess though, that I can't see how wrapping it into an "unclosable" stream would lead to more memory leaks than you would have should Piccolo not close the stream. Also, it feels to me that, in some sense, Tomcat could take care that a "close" does the right thing, so that the fact that the streams are in reality shared is transparent to programmers. Would you feel better if XmlBeans had an option to wrap any streams that it uses in "unclosable" streams? > 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]
