cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
Subject Re: Problem with multi-format messages and JAX-WS handlers
Date Tue, 19 Sep 2006 15:16:49 GMT


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

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194   F:781-902-8001
daniel.kulp@iona.com

Mime
View raw message