cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject Problem with multi-format messages and JAX-WS handlers
Date Tue, 19 Sep 2006 10:34:12 GMT


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

Basically we allow say an incoming message to have an underlying format
(e.g. provided by the transport, and various
layered formats (e.g. a 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

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

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.



View raw message