Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Problem with multi-format messages and JAX-WS handlers
Date: Tue, 19 Sep 2006 22:08:35 +0100
Message-ID: 
 <FA1787F64A095C4090E76EBAF8B183E00300F7@emea-ems1.dublin.emea.iona.com>
Thread-Topic: Problem with multi-format messages and JAX-WS handlers
Thread-Index: AcbcCuC1NiNhTmnxQAGppZnKIgGZ/AAIk/rQ
From: "Glynn, Eoghan" <eoghan.glynn@iona.com>
To: <cxf-dev@incubator.apache.org>


> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]=20
> Sent: 19 September 2006 17:44
> To: cxf-dev@incubator.apache.org
> Subject: Re: Problem with multi-format messages and JAX-WS handlers
>=20
> I disagree that its flawed. It will not work well for every=20
> particular case and there are definite limitations, but for=20
> the following cases it still works:
>=20
> 1. Parsing to DOM, and then using a stream reader on top of stax
> (WS-Security)
> 2. Writing to stax, flushing, writing to an outputstream, and=20
> then writing to stax (JAXB) 3. Reading to byte buffer, stax=20
> on top of byte buffer to route the message, and then writing=20
> the byte buffer

Sure it works in many cases, I'm not disputing that. However there's an
important current use-case in which it definitely doesn't work. So at
the very least its fragile and requires care around the order in which
the various formats are retrieved, and knowledge about how layered
formats are implemented in terms of eager read-ahead.
=20
> Also, I'm not sure I understand your problem with 1) reading=20
> via the inputstream (requires placing the saaj interceptor before the
> staxininterceptor) and 2) putting an xmlstreamreader on top=20
> of the SAAJ impl. SAAJ implements the w3c dom interfaces so=20
> we should be able to use the W3CDOMStreamReader.

I don't have a problem with it, I just thought we'd need to pull in
something like the Xfire DOMStreamReader util class to adapt between the
DOMSource and XMLStreamReader APIs. However, DanK points out that the
XMLInputFactory can handle this already.

/Eoghan
=20
> - Dan
>=20
> Glynn, Eoghan wrote:
>=20
> >Yep, if such a thing were available it would get us over the=20
> hump (note=20
> >as I pointed out in my response to DanK, we currently just=20
> use the RI=20
> >SAAJ model, which consumes the underlying input stream as=20
> opposed to a=20
> >parsed source).
> >
> >However, I'd repeat my feeling that the multi-format message idea is=20
> >flawed, unless we're careful to always replace an old=20
> content type with=20
> >a new one if the latter may render the former unusable. And=20
> often-times=20
> >this isn't obvious ... e.g. it's a quality of a particular=20
> >XMLStreamReader implementation whether it eagerly consumes the=20
> >underlying input stream.
> >
> >/Eoghan
> >
> > =20
> >
> >>-----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=20
> SAAJ tree from=20
> >>the StAX stream reader. Is there a stax->saaj builder around=20
> >>somewhere?
> >>We could certainly write one pretty easily I think. Or=20
> should we just=20
> >>use stax->sax->saaj for now?
> >>- Dan
> >>
> >>Daniel Kulp wrote:
> >>
> >>   =20
> >>
> >>>Eoghan,
> >>>
> >>>I THINK the best "short term" solution for this problem
> >>>     =20
> >>>
> >>would be to put the
> >>   =20
> >>
> >>>SAAJ handlers BEFORE the StAX interceptor.   The SAAJ=20
> >>>     =20
> >>>
> >>handler would use the
> >>   =20
> >>
> >>>input stream to parse to SAAJ.    It would then create the=20
> >>>     =20
> >>>
> >>XMLStreamReader
> >>   =20
> >>
> >>>based on the DOM model and set that into the message.  (The=20
> >>>XMLStreamReader would just iterate over the DOM)  Thus, the StAX=20
> >>>interceptor wouldn't have anything to do anything as the=20
> >>>XMLStreamReader would already be present in the Message.
> >>>
> >>>
> >>>Dan
> >>>
> >>>
> >>>
> >>>
> >>>On Tuesday September 19 2006 6:34 am, Glynn, Eoghan wrote:
> >>>=20
> >>>
> >>>     =20
> >>>
> >>>>Folks,
> >>>>
> >>>>I've come across an issue when trying to use JAX-WS=20
> Handlers in the=20
> >>>>WS-Addressing system test (used to assert that the message
> >>>>       =20
> >>>>
> >>addressing
> >>   =20
> >>
> >>>>properties are made available to handlers as expected).
> >>>>
> >>>>A while back I pointed out what I thought was a flaw in the=20
> >>>>multi-format Message idea, and I think my current problem=20
> may be a=20
> >>>>manifestation of this.
> >>>>
> >>>>Basically we allow say an incoming message to have an underlying=20
> >>>>format (e.g. java.io.InputStream) provided by the transport, and=20
> >>>>various layered formats (e.g. a javax.xml.stream.XMLStreamReader=20
> >>>>under-pinned by the InputStream) added by interceptors in
> >>>>       =20
> >>>>
> >>the dispatch chain.
> >>   =20
> >>
> >>>>The idea being to allow interceptors to switch back and
> >>>>       =20
> >>>>
> >>forth between
> >>   =20
> >>
> >>>>various representations, so as to use the most=20
> >>>>convenient/performant/natural one for the current context. So for=20
> >>>>instance one interceptor consumes elements via StAX,
> >>>>       =20
> >>>>
> >>whereas the next
> >>   =20
> >>
> >>>>reverts to the InputStream to get low-level access to the
> >>>>       =20
> >>>>
> >>underlying
> >>   =20
> >>
> >>>>bytes.
> >>>>
> >>>>However, there's a wrinkle. The layered format could be
> >>>>       =20
> >>>>
> >>implemented to
> >>   =20
> >>
> >>>>read-ahead, e.g. a reader eagerly consuming from the
> >>>>       =20
> >>>>
> >>underlying input
> >>   =20
> >>
> >>>>stream to fulfill the next() call. So if you switch back to the=20
> >>>>underlying format, you'll miss out on elements cached in=20
> the reader.
> >>>>
> >>>>Now that's what appears to be happening, i.e. the XMLStreamReader=20
> >>>>added by the StaxInInterpceptor consumes the stream.=20
> Later when the=20
> >>>>SOAPMessageContext is created by the SOAPHandlerInterceptor, it=20
> >>>>attempts to revert back to the InputStream representation
> >>>>       =20
> >>>>
> >>in order to
> >>   =20
> >>
> >>>>create the SAAJ message - however the stream content has
> >>>>       =20
> >>>>
> >>already been
> >>   =20
> >>
> >>>>consumed by the XMLStreamReader, so the call to
> >>>>javax.xml.soap.MessageFactory.createMessage() fails with an
> >>>>       =20
> >>>>
> >>unexpected
> >>   =20
> >>
> >>>>EOF.
> >>>>
> >>>>It seems to me that this model of switching between=20
> representations=20
> >>>>would only be viable if we could guarantee that the layered
> >>>>       =20
> >>>>
> >>formats do
> >>   =20
> >>
> >>>>not read-ahead eagerly. Anyone know if its possible to set
> >>>>       =20
> >>>>
> >>this sort
> >>   =20
> >>
> >>>>of behavior for the StAX reader? If not, I guess we'd need
> >>>>       =20
> >>>>
> >>to replace
> >>   =20
> >>
> >>>>our use of MessageFactory.createMessage() with our own SAAJ model=20
> >>>>layered over the XMLStreamReader.
> >>>>
> >>>>Thoughts?
> >>>>
> >>>>/Eoghan
> >>>>  =20
> >>>>
> >>>>       =20
> >>>>
> >>>=20
> >>>
> >>>     =20
> >>>
> >>--
> >>Dan Diephouse
> >>(616) 971-2053
> >>Envoi Solutions LLC
> >>http://netzooid.com
> >>
> >>
> >>
> >>   =20
> >>
>=20
>=20
> --
> Dan Diephouse
> (616) 971-2053
> Envoi Solutions LLC
> http://netzooid.com
>=20
>=20
>=20