> 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
Problem is that we don't currently actually parse out the DOM in the SOAPHandlerInterceptor ... instead we rely on SAAJ reference implementation MessageFactory.createMessage() to parse out the SOAP message parts. So wouldn't we need to implement our own SAAJ model based on a DOM? Also, I think we'd need a specialized XMLStreamReader implementation capable of consuming a DOM. I don't think the standard StAX XMLInputFactory provides such a thing, but I guess we could lift the DOMStreamReader implementation from Xfire. In general though, would you agree that this issue sortta invalidates the multi-format Message model? It seems to me that instead of calling Message.setContent(XMLStreamReader.class, ...) to provide an *additional* content format, it should instead *replace* the InputStream content completely. IMO this sould apply at least anywhere the new content renders the original content unusable (e.g. by consuming as in this example). Relying on ordering effects is too fragile. /Eoghan > 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 > [EMAIL PROTECTED] > >
