cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Problem with multi-format messages and JAX-WS handlers
Date Tue, 19 Sep 2006 16:36:21 GMT

Yep, if such a thing were available it would get us over the hump (note
as I pointed out in my response to DanK, we currently just use the RI
SAAJ model, which consumes the underlying input stream as opposed to a
parsed source).

However, I'd repeat my feeling that the multi-format message idea is
flawed, unless we're careful to always replace an old content type with
a new one if the latter may render the former unusable. And often-times
this isn't obvious ... e.g. it's a quality of a particular
XMLStreamReader implementation whether it eagerly consumes the
underlying input stream.

/Eoghan

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 19 September 2006 17:22
> To: cxf-dev@incubator.apache.org
> Cc: Glynn, Eoghan
> Subject: Re: Problem with multi-format messages and JAX-WS handlers
> 
> 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
> 
> 
> 

Mime
View raw message