Re: SOAPMessageContext

[Eran Chinthaka]

hmm interesting !! ant elder wrote: The way I thought that could work, for example by an Axis2 TransportListener communicating with an Axis2 Sender, is that there would be an Axis2 specific SynapseMessage implementation, say Axis2SynapseMessageImpl which would have a getter for the Axis2 MessageContext. So Axis2 specific classes could know/see the SynapseMessage is an instance of an Axis2SynapseMessageImpl and cast it to get at the getter for the real underlying MessageContext. Non Axis2 specific code wouldn't know or care about the Axis2'ness of the SynapseMessage. Also, as the AxisEngine.receive takes a MessageContext not a SynapseMessage but the Synapse MediatorMessageReceiver will probably want to create a SynapseMessage for the MessageContext, the Axis2SynapseMessageImpl would store all the fields in SynapseMessage as properties in the MessageContext. So the MediatorMessageReceiver could just do new Axis2SynapseMessageImpl(mc) and then for eg a Mediator calling getProperty on the SynapseMessage will find any properties that were set prior to the AxisEngine.receive being called. ...ant On 11/14/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote: I kinda like this idea. IMO, this is better than having SOAPMC in Axis2. BTW, I'd like to propose one more thing. Shall we provide some way of accessing the hidden message context via SynapseMessage. Let me explain this a bit, before getting hammered ;-) SynapseMessage will have the methods that we think now it should contain, and it basically hides all the other methods in the Axis2 message context. But what if, one day a user comes up with a good use case, where that thing can not be implemented with the methods that we've defined in the SOAPMesage, BUT, the message context has the information to implement that. We have two options. 1. to add a method to the SynapseMessage, exposing that method in MC. 2. to provide a method or a way to access the underlying message context. The disadvantage in the above method 1 is that, whenever some one needs that kind of methods we have to keep on adding methods to the SynapseMessage, which MAY ultimately end up being "almost" like Axis2 MessageContext. But the second method relieves us from that. Just an idea popped in to my mind. ant elder wrote: FYI, there's been some discussions on the new Axis2 SOAPMessageContext interface for Synapse over on axis-dev: http://marc.theaimsgroup.com/?t=113170616200001&r=1&w=1 Instead of a new Axis2 interface I suggested a Synapse specific message which delegates some calls to an Axis2 MessageContext. It would have all the methods that were going to be on the new Axis2 interface along with Synapse specific methods to get at the Synapse headers, config, environment etc. interface SynapseMessage { String getTo(); ... } SynapseMessageImpl { MessageContext mc; public SynapseMessageImpl(MessageContext mc) {this.mc <http://this.mc> < http://this.mc> = mc} String getTo() { return mc.geTo(); } ... } --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]