synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mukund Balasubramanian" <muk...@infravio.com>
Subject Re: Mediator interface
Date Sun, 09 Oct 2005 08:22:47 GMT
While I agree that using message context is not as clean as you would like it to be (look at
any of the mediations in the current source code base), there is a cost associated with managing
the lifecycle of an entirely new context object.

While we can have a rule then tying the lifecycles of the two contexts together (making axis
mc the cxontainer of synapse mc), I believe it is more appropriate not to fight the axis and
synapse dependency and focus only on designing for flexibility that has enough value.

In other words, the cleaner implementation using a synapse container and mc does not, in my
opinion, justify the effort.

Mukund Balasubramanian



-----Original Message-----
From: ant elder <ant.elder@gmail.com>
To: synapse-dev@ws.apache.org <synapse-dev@ws.apache.org>
Sent: Fri Oct 07 15:12:16 2005
Subject: RE: Mediator interface

What do people think about having a new Synapse MessageContext interface instead of using
the AXIS2 MessageContext class? It makes Synapse quite invasive - a mediation has dependencies
on both Synapse and AXIS2.

An aim of Synapse mediations is to be based on the SOAP Infoset, but using the AXIS2 classes
brings in far more than that, eg the AXIS2 MC has methods relating to AXIS2 config - modules,
SystemConfiguration etc.  And as its a class not an interface you can't easily mock it up
for unit testing mediation beans in isolation, you endup needing mocks for all sorts of unrelated
AXIS2 classes. Which surely that goes against Synapse being a non-invasive container for mediation
POJOs? 

Similar thing with the AXISFault. I agree with what Eric said earlier about not using AXISFault.
If mediation exceptions are going to be fundamentally SOAPy faults then AXISFault represents
more than that.

       ...ant

PS. Hi guys



Mime
View raw message