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:[EMAIL PROTECTED] > Sent: 19 September 2006 17:22 > To: [email protected] > 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 > > >
