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 17:22:37 GMT
On Tuesday September 19 2006 12:36 pm, Glynn, Eoghan wrote:
> 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).

That should be fine.   If we put it before the StAX thing, we can parse using 
the stream/MimeHeaders like normal.   I'd probably also remove the 
InputStream from the message if it's totally consumed as well.  

The SAAJ stuff all implements the DOM interfaces.   Thus, you can create a 
DOMSource out of it and pass that to the XMLInputFactory to create an 
XMLStreamReader from it.   That would be set in the message going forward so 
the SOAP/XML bindings can use that.


> 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.

There are definitely places where it won't work, in which case we'll need to 
be careful.   In the above case, if the input stream is completely consumed 
and no longer valid at all, we SHOULD remove it from the message. 

Dan



>
> /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

-- 
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