The workaround is in
Package: com.hp.hpl.jena.sparql.engine.http
HttpQuery.execCommon()
Look for "WORKAROUND"
It does:
byte[] bytes = IO.readWholeFile(in) ;
in = new ByteArrayInputStream(bytes) ;
remove that.
The report code is in:
<src-dev>/reports.ReportDBPedia2
XMLInputStAX is the StAX based parser.
There is a separate SAX-based parser (non-streaming, but the workaround
is to stop streaming...) enabled by:
ARQ.getContext().setTrue(ARQ.useSAX) ;
Andy
On 08/02/11 22:11, Benson Margulies wrote:
What would I back out from trunk to get the failure so that I could
see if I could make any sense of it, possibly with help from Tatu?
On Tue, Feb 8, 2011 at 1:30 PM, Benson Margulies<[email protected]> wrote:
On Tue, Feb 8, 2011 at 11:34 AM, Andy Seaborne
<[email protected]> wrote:
On 08/02/11 15:23, Benson Margulies wrote:
Hmm. This works fine in CXF. Do you all care enough to put more effort
into avoiding the extra buffer?
Is the STaX parser is CXF using?
I tried upgrading to woodstox 4.1.1 and (stil using the STaX API) get the
same problem.
recoding (only in XMLInputStAX?) to use STaX2 might be an option.
I don't think that's relevant. The main CXF data path does just what's
giving you trouble, using the plain STaX API.
Andy
