cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <>
Subject Re: Problem with multi-format messages and JAX-WS handlers
Date Tue, 19 Sep 2006 16:22:19 GMT
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:

>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.
>On Tuesday September 19 2006 6:34 am, Glynn, Eoghan wrote:
>>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.

Dan Diephouse
(616) 971-2053
Envoi Solutions LLC

View raw message