Hi all,
While looking at our transport senders I noticed that we are setting the
details of the response SOAP message in the operation context. Some
extracts are as follows.
if (msgContext.getOperationContext() != null) {
msgContext.getOperationContext()
.setProperty(MessageContext.TRANSPORT_IN, in);
}
if (opContext != null) {
opContext.setProperty(
HTTPConstants.MTOM_RECEIVED_CONTENT_TYPE,
header.getValue());
}
}
Reason for using the operation context for this is not clear to me.
AFAIK above logic breaks if we had a out-in-in MEP. There exist at
least two alternate paths we can follow.
1. we can create the response message context and use it to store these
details.
2 . we can keep these in the existing messagecontext (MC of the send)
and transfer to the response message context later, (we are already
doing this for
some of the properties)
Capturing these in the response message context makes it easy to come up
with a uniform builder creation logic for both server side receiving as
well as for the response receiving..
One more thing I noticed is about the transport header processing logic.
We are setting the transport headers as a property to the message context in
the servlet case. But we are not doing that in the case of receiving a
response from the commons sender. I'm not sure whether this due to any
perf reasons.. But IMHO we should be consistent in both cases..
Comments please...
Thanks,
Thilina
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
