Well, my thought that we should be able to build up the SAAJ tree from
the StAX stream reader. Is there a stax->saaj builder around somewhere?
We could certainly write one pretty easily I think. Or should we just
use stax->sax->saaj for now?
- Dan
Daniel Kulp wrote:
Eoghan,
I THINK the best "short term" solution for this problem would be to put the
SAAJ handlers BEFORE the StAX interceptor. The SAAJ handler would use the
input stream to parse to SAAJ. It would then create the XMLStreamReader
based on the DOM model and set that into the message. (The XMLStreamReader
would just iterate over the DOM) Thus, the StAX interceptor wouldn't have
anything to do anything as the XMLStreamReader would already be present in
the Message.
Dan
On Tuesday September 19 2006 6:34 am, Glynn, Eoghan wrote:
Folks,
I've come across an issue when trying to use JAX-WS Handlers in the
WS-Addressing system test (used to assert that the message addressing
properties are made available to handlers as expected).
A while back I pointed out what I thought was a flaw in the multi-format
Message idea, and I think my current problem may be a manifestation of
this.
Basically we allow say an incoming message to have an underlying format
(e.g. java.io.InputStream) provided by the transport, and various
layered formats (e.g. a javax.xml.stream.XMLStreamReader under-pinned by
the InputStream) added by interceptors in the dispatch chain.
The idea being to allow interceptors to switch back and forth between
various representations, so as to use the most
convenient/performant/natural one for the current context. So for
instance one interceptor consumes elements via StAX, whereas the next
reverts to the InputStream to get low-level access to the underlying
bytes.
However, there's a wrinkle. The layered format could be implemented to
read-ahead, e.g. a reader eagerly consuming from the underlying input
stream to fulfill the next() call. So if you switch back to the
underlying format, you'll miss out on elements cached in the reader.
Now that's what appears to be happening, i.e. the XMLStreamReader added
by the StaxInInterpceptor consumes the stream. Later when the
SOAPMessageContext is created by the SOAPHandlerInterceptor, it attempts
to revert back to the InputStream representation in order to create the
SAAJ message - however the stream content has already been consumed by
the XMLStreamReader, so the call to
javax.xml.soap.MessageFactory.createMessage() fails with an unexpected
EOF.
It seems to me that this model of switching between representations
would only be viable if we could guarantee that the layered formats do
not read-ahead eagerly. Anyone know if its possible to set this sort of
behavior for the StAX reader? If not, I guess we'd need to replace our
use of MessageFactory.createMessage() with our own SAAJ model layered
over the XMLStreamReader.
Thoughts?
/Eoghan
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
