I think I see what you're saying, but let me recap to make sure. I'm
assuming you're looking at implementing the SAAJ support on the outgoing
side? So if we did something like this:
Document doc = DOMUtils.createDocument();
XMLStreamWriter writer = StaxUtils.createXMLStreamWriter(new
DOMResult(doc));
message.setContent(writer);
Our invocation flow would then be:
MessageSender
->StaxOutInterceptor (would get skipped because there is already an
XMLStreamWriter)
-> SoapOutInterceptor
-> Wrapped/Bare interceptors
-> SAAJ interceptor(s) (creates SAAJ message and invoke SAAJ
Handlers)
I'm assuming that the concern is we haven't returned alway the way back
to the SoapOutInterceptor so we wouldn't be finished writing?
However, due to some sneakiness, with a DOM streamwriter we don't
actually need to call writeEndElement(), so we have a complete DOM by
the time we get to the SAAJ portion of the chain.
With that said, I am intrigued by your idea of subchains for the
marhsalling. I think that it could be a good idea to perform the
marshalling in a sub chain and then we can perform processing on what it
is fully written. The question is how to do it cleanly... One option
might be to only allow reentrance up through a particular phase. i.e.
when we hit whatever phase is after marshalling, force everything to
return back to MessageSender and *then* continue to the next phase.
In XFire we got around this by having a MessageSerializer which could be
wrapped, so we could have:
serializer = new WrappedSerializer();
serializer = new SoapSerializer(serializer);
And this allowed databinding to all happen within one single
interceptor. This approach might be worth thinking about too.
Cheers,
- Dan
Liu, Jervis wrote:
Hi,
I've come across an issue when trying to make SOAPHandlerInterceptor able to
read SOAPMessage in the outbound direction. Basically the problem is that our
current outbound interceptor chain is not a flat chain, it looks like below:
WrapperClassOutInterceptor
LogicalHandlerInterceptor
MessageSenderInterceptor
StaxOutInterceptor
SOAPHandlerInterceptor
SoapOutInterceptor
WrappedOutInterceptor
BareOutInterceptor
In this chain, SoapOutInterceptor makes a call to WrappedOutInterceptor and BareOutInterceptor, and when all following interceptors finish, the control returns back to SoapOutInterceptor. This is wrong, because all interceptors followed by SoapOutInterceptor are called inside SoapOutInterceptor. The fundamental reason why we doing this is because stax. We need to write the end element of soap envelop in SoapOutInterceptor when BareOutInterceptor finishes writing soap body (SoapOutInterceptor.handleMessage(), line 91).
I have been thinking about this problem, unfortunately can not figure out good
fix. Less ideal fixes I can think about are:
1. Write an advanced chain. This chain is possible to configure a sub chain for each main node on the chain.
2. Do sth with Stax. I m checking if we can do anything by replacing
XMLStreamWriter with XMLEventWriter. Or at lease, we can hope stax can provide
some kind of callback support for writing.
3. Merge SoapOutInterceptor/WrappedOutInterceptor/BareOutInterceptor to one interceptor. This makes sense as essentially they are doing one job - writing soap message. This can be done by either making WrappedOutInterceptor/BareOutInterceptor a util style class or explicitly instantiate those interceptors inside SoapOutInterceptor.
Actually I think this is a general problem when we moved to stax. In the short
term, probably 3 is the easiest way to fix the problem. But please do speck out
if you can have any better ideas. Thanks.
Cheers,
Jervis
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
