cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Stax exception for (extremely) large content in tag
Date Tue, 07 Sep 2010 16:42:32 GMT
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

Mime
View raw message