I disagree that its flawed. It will not work well for every particular
case and there are definite limitations, but for the following cases it
still works:
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 then
writing to stax (JAXB)
3. Reading to byte buffer, stax on top of byte buffer to route the
message, and then writing the byte buffer
Also, I'm not sure I understand your problem with 1) reading via the
inputstream (requires placing the saaj interceptor before the
staxininterceptor) and 2) putting an xmlstreamreader on top of the SAAJ
impl. SAAJ implements the w3c dom interfaces so we should be able to use
the W3CDOMStreamReader.
- Dan
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).
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
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
