|
I saw a similar post regarding the server side, but in
looking at all the documentation and samples, I cannot figure out how to write
a client that doesn’t build the whole OM object tree for the payload.
If I set caching to false: public OMElement getPayload(InputStream is) throws
XMLStreamException { XMLInputFactory xif =
XMLInputFactory.newInstance(); XMLStreamReader reader =
xif.createXMLStreamReader(is); StAXOMBuilder builder = new
StAXOMBuilder(reader); builder.setCache(false); OMElement oe =
builder.getDocumentElement(); return oe; } then the client side code goes into an infinite loop trying
to get the document element. This is caused by the following sequence of
calls in Axiom, wherein the document element is never set to a non-null value
because caching is on. OMDocumentImpl: public OMElement getOMDocumentElement() { while (documentElement == null) { parserWrapper.next(); } return documentElement; } StAXOMBuilder: public int next() throws OMException { try { if (done) { throw new OMException(); } int token = parser.next(); if (!cache) { return token; } ..etc. Now if I comment out the call to turn off caching, Axiom
merrily goes along and builds the entire OMElement result = sender.sendReceive(payload); eventually calls: ServiceClient.fillSOAPEnvelope() which eventually leads to: OMElementImpl.detach(); Which causes the whole tree to be rendered as OMObjects.
For the previous server-side question the Axis person suggested looking at the
OMDatasource test code, but looking at this seemed to yield nothing relevant
unless I’m missing something. Any suggestions on how to efficiently handle a large
client-side payload using Axiom? Is this a bug that should be submitted? Gary Gordon |
