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

    [ http://issues.apache.org/jira/bro
wse/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: htt
p://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.getInputStr
eam());
> 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.reportFatalErro
r(Piccolo.java:1038)
>
org.apache.xmlbeans.impl.piccolo.xml.Piccolo.parse(Piccolo.j
ava:723)
>
org.apache.xmlbeans.impl.store.Locale$SaxLoader.load(Locale.
java:3354)
>
org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Local
e.java:1267)
>
org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Local
e.java:1254)
>
org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(S
chemaTypeLoaderBase.java:345)
>
org.outerx.daisy.x10Publisher.PublisherRequestDocument$Facto
ry.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.ja
va:981)
>
org.mortbay.http.HttpConnection.handle(HttpConnection.java:8
31)
>
org.mortbay.http.SocketListener.handleConnection(SocketListe
ner.java:244)
>
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:3
57)
>
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:5
34)
> 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.atl
assian.com/software/jira


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribexmlbeans.apache.org
For additional commands, e-mail: dev-helpxmlbeans.apache.org