Paul
On 11/15/05, Eran Chinthaka
<[EMAIL PROTECTED]> wrote:
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=1Instead of a new Axis2 interface I suggested a Synapse specific message which delegates some calls to an Axis2 MessageContext. It would have allthe
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]
