Ok, I don't want to look like the mad scientist who comes up with the craziest theory always but I humbly think I'm talking about the same issue of allowing the SOAPMsgCtx to co-exist without corrupting (or rather effecting) the Axis2 system. However I also feel that I lack knowledge of some discussions which were in the mailing lists (Silly me) so I won't push the msgCtxtFactory theory anymore.
BTW is this SOAPMC needed to be implemented as part of Axis2 ? The original mail seems to imply that the SOAP specific methods were specifically for Synapse, in which case the particular 'Ctxt' needs to be part of Synapse and not Axis2!
Am I deeply mislead or missing a crucial piece of logic here ?

On 11/13/05, Sanjiva Weerawarana <[EMAIL PROTECTED] > wrote:
Hi Paul,

> If I am in Synapse I am looking at a message on the wire. And I have
> to decide which way it is going. So in general I have a complex
> calculation to make:
>
> 1. Look at the transport (i.e. is it an HTTP response)
> 2. See if it has a relatesTo header
> 3. Look at the To: header (maybe it is anon)
> etc.
>
> If it is an In Out* mep, then the In.isResponse=false and the
> out.isResponse is true for both following messages.

Let's do this- when we figure out how Axis2 and Synapse will work
together (at the message level, not architecturally) let's see whether
there's a way to have such a flag.

I think the important point is that from Synapse's point of view, we
want to know whether the message is going to the service vs. coming from
the service; we don't particularly care whether its a "response" or not.
That is, for an outbound MEP, I assume we'll want to apply the rules for
messages going out of the service and not the ones for messages coming
in, right? In which case talking about "is it a response or not" is the
wrong topic.

Sanjiva.




--
Ajith Ranabahu

Reply via email to