[ 
https://issues.apache.org/jira/browse/OLINGO-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13834859#comment-13834859
 ] 

Aki Yoshida commented on OLINGO-73:
-----------------------------------

Hi Christian,
here is the official reference of JDK.

http://docs.oracle.com/javaee/5/api/javax/xml/stream/XMLStreamReader.html#next()
Get next parsing event - a processor may return all contiguous character data 
in a single chunk, or it may split it into several chunks. If the property 
javax.xml.stream.isCoalescing is set to true element content must be coalesced 
and only one CHARACTERS event must be returned for contiguous element content 
or CDATA Sections. By default entity references must be expanded and reported 
transparently to the application.

you could force the parser to return a single chunk but you will have to be 
aware of security risk of blowing up in memory.
typically, a parser implementation uses its default buffer size to return a 
chunk.
regards, aki



> Woodstox parser fails for big files sometimes
> ---------------------------------------------
>
>                 Key: OLINGO-73
>                 URL: https://issues.apache.org/jira/browse/OLINGO-73
>             Project: Olingo
>          Issue Type: Bug
>          Components: odata2-core
>    Affects Versions: V2 1.0.0
>            Reporter: Christian Amend
>            Assignee: Christian Amend
>             Fix For: V2 1.1.0
>
>
> For some big xml files the woodstox parser which is a transitive dependency 
> of cxf fails with the exception: "Found characters or cdata event when not 
> expected"
> This happens because a previous call of getText() doesn´t deliver the whole 
> text but only a fraction. So when we call nextTag() the parser throws the 
> exception because there is still character data on the buffer. This issue 
> does only appear with big xml files and happens randomly within the document 
> altough always at the same element.
> So maybe this is a woodstox bug. We can implement a workaround by calling 
> getText() as long as there is still character data left. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to