> -----Original Message----- > From: Kulp, John Daniel > Sent: Tuesday, October 24, 2006 11:39 PM > To: [email protected] > Cc: Liu, Jervis > Subject: Re: Problem with interceptor chain > > > > Jervis, > > > 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 > > > Out of curiosity, why couldn't the SOAPHandlerInterceptor do the same > thing. Make it: > > WrapperClassOutInterceptor > LogicalHandlerInterceptor > MessageSenderInterceptor > StaxOutInterceptor > SOAPHandlerInterceptor > SoapOutInterceptor > WrappedOutInterceptor > BareOutInterceptor > > Basically, the SOAPHandlerInterceptor would create a StAX writer that > writes to the SAAJ model/DOM and then calls: > message.getInterceptorChain().doIntercept(message); > > When that returns, the SAAJ model should be fully built up at > which point > you can call the SAAJ handlers. When they are done, stream > the SAAJ to > the output stream. > Actually, this is what I am trying to do today. Yesterday, I thought I need to move SOAPHandlerInterceptor after BareOutInterceptor in order to access SAAJ model, which is proved a bit hard to do as outputStream has been flushed to httpStream at the end of SoapOutInterceptor. What I am doing now is wrapping the invocation of SoapOutInterceptor inside SOAPHandlerInterceptor, this requires creating a new empty AbstractCachedOutputStream, creating a stAX writer from this AbstractCachedOutputStream then replacing the XMLStreamWriter in message content with the stAX writer created in SOAPHandlerInterceptor. When SoapOutInterceptor returns, copy the content of AbstractCachedOutputStream to the OutputStream passed in by StaxOutInterceptor. After this step, SAAJ handlers can build up SOAP message from AbstractCachedOutputStream, if SOAPMessage is changed, stream SOAPMessage to outputStream.
I have not spent much time to look at how ws_addressing and ws_rm interceptors work yet, I hope this approch wont break ws_addressing and ws_rm interceptors. Generally speaking, our interceptor lacks of a mechanism to return the control from the wrapped interceptor to the main flow when message.getInterceptorChain().doIntercept(message) is called. I.e., all the following interceptors in the chain after the call of message.getInterceptorChain().doIntercept(message) are wrapped in the interceptor that calls message.getInterceptorChain().doIntercept(message). Certainly this is not the behavior we want from the interceptor chain. For example, we wont have stream interceptors anymore, if we do have, a stream interceptor will be wrapped inside SoapOutInterceptor which is obviously wrong, unless we move stream interceptor's phase USER_STREAM to be somewhere before PRE_PROTOCOL, which makes whole thing even more confusing. Anyway, my feeling is that the use of message.getInterceptorChain().doIntercept(message) and the "wrapped interceptors" makes it hard to understand the actual flow of interceptor chain. For example, if we simply look into PhaseManagerImpl, SOAPHandlerInterceptor's phase is USER_PROTOCOL, one's first reaction would be this phase should be after WRITE and MARSHAL, because that is the place where all protocol info get fully built up. But we put USER_PROTOCOL right after PRE_PROTOCOL mainly to get around some implementation problems(such as the problem I mentioned above). > > -- > J. Daniel Kulp > Principal Engineer > IONA > P: 781-902-8727 C: 508-380-7194 F:781-902-8001 > [EMAIL PROTECTED] >
