We are doing this for efficiency. We don't want to have to copy from an AxisMC into a SynapseMC. And I don't agree that this is not a useful *general* concept. It is nothing special to Synapse. It is simply a view of the MC that doesn't expose the internals of the programming model. In fact, the AXIS client and server programming model would be cleaner if it used SOAPMessageContext :-) Why should users of Axis2 know about the internals?
Paul
On 11/11/05, Ajith Ranabahu <[EMAIL PROTECTED]> wrote:
Hi all,
I see that folks have different views on putting this particular SOAPMessageContext, most probably as part of Axis2 itself would be slightly inappropriate since Axis2 can survive nicely without it :).
Here's my plan to make both worlds happy. Instead of just creating message contexts inside, we provide a MessageContextFactory that is settable from outside (probably through Axis2.xml). This makes it flexible enough for Synapse to introduce it's own context and Axis2 never needs to know about Synapse or anything! SOAPMsgCtxt can remain as part of Synapse rather than Axis2
thoughts?On 11/11/05, Eran Chinthaka < [EMAIL PROTECTED]> wrote:
Paul Fremantle wrote:
>Ok folks
>
>1) I will remove processingFault and inFaultFlow.
>2) I think we can remove MessageInformationHeaders from the interface
>3) I'm not sure I agree that the isResponse is never useful in a pure Axis2
>context. Is it not an aspect of a pure SOAP message which direction it is
>going in?
>
>
I think no. The one who handles messages should know that.
1. If you look at a SOAP message on the wire, can you see which
direction it is going ?
2. And if this message context is a part of an IN OUT OUT MEP, which
response are you talking about ? Remember Axis2 can be extended to
support *any* MEP.
In Axis2, You should be able to get this from the message label which
you can get from the AxisOperation.
(If you want an answer of how to implement this functionality in
Synapse, I'd love to answer in Synapse-dev :-) )
-- Chinthaka
--
Ajith Ranabahu
