Stax exception for (extremely) large content in tag

[Peter Liljenberg <pl...@gmail.com>]

Hi,

We're integrating with an external provider that is sending their full
stacktrace back to us in their SoapFault (yes, I'm not kidding).
This causes the StaxInInterceptor to fail, or rather the XML parsing part,
since the reader used by Stax only gets 4000 bytes of data before trying to
validate the XML and since the tag is larger than that is fails with the
exception below.
We've found a workaround by inserting a CorrectingStaxInInterceptor that
creates a different XMLInputFactory and sets the
"com.ctc.wstx.inputBufferLength" property to a larger value and that seems
to work.
Is there a way to set this property in any other way? Browsing the CXF and
STAX code there is no obvious way. 

Stacktrace:

Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected end of input block
in start tag
 at [row,col {unknown-source}]: [1,4000]
        at
com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOB(StreamScanner.java:700)
        at
com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.java:1054)
        at
com.ctc.wstx.sr.StreamScanner.getNextCharFromCurrent(StreamScanner.java:811)
        at
com.ctc.wstx.sr.BasicStreamReader.handleNsAttrs(BasicStreamReader.java:3003)
        at
com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2936)
        at
com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2848)
        at
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1019)
        at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:849)
        at
org.apache.cxf.staxutils.StaxUtils.startElement(StaxUtils.java:771)
        at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:808)
        at
org.apache.cxf.staxutils.StaxUtils.startElement(StaxUtils.java:771)
        at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:808)
        at
org.apache.cxf.staxutils.StaxUtils.startElement(StaxUtils.java:771)
        at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:808)
        at org.apache.cxf.staxutils.StaxUtils.read(StaxUtils.java:708)
        at
org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:66)

-- 
View this message in context: http://cxf.547215.n5.nabble.com/Stax-exception-for-extremely-large-content-in-tag-tp2805384p2805384.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: Stax exception for (extremely) large content in tag

[Daniel Kulp <dk...@apache.org>]

On Monday 06 September 2010 4:37:43 pm Peter Liljenberg wrote:
> Hi,
> 
> We're integrating with an external provider that is sending their full
> stacktrace back to us in their SoapFault (yes, I'm not kidding).

That's usually not an issue if it's the text of an element.   The parser will 
likely break it up into separate Text events.     We actually have some flags 
that will tell CXF to do that as well for our faults.


> This causes the StaxInInterceptor to fail, or rather the XML parsing part,
> since the reader used by Stax only gets 4000 bytes of data before trying to
> validate the XML and since the tag is larger than that is fails with the
> exception below.

Are they sticking the stack trace into an Attribute or something?   It looks 
like it from the stack trace.  THAT would be completely bizarre. 


> We've found a workaround by inserting a CorrectingStaxInInterceptor that
> creates a different XMLInputFactory and sets the
> "com.ctc.wstx.inputBufferLength" property to a larger value and that seems
> to work.
> Is there a way to set this property in any other way? Browsing the CXF and
> STAX code there is no obvious way.

Not that I can think of.  You could try using Woodstox 4 and seeing if that 
"just works" as maybe they changed some of the parsing logic.   In general, if 
the "default" parser isn't working, something similar to what you did is 
probably required.   There are ways you can configure in the  XMLInputFactory 
from Spring that can avoid the CorrectingStaxInInterceptor, but that can also 
be a bit complex.


-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog