I'm not sure why you prefer putting the environment in the message than making it something we inject into mediators.
Can you explain the benefit?
Paul
On 11/14/05,
ant elder <[EMAIL PROTECTED]> wrote:
But there could be some Synapse specific context associated with each message couldn't there? There's the Synapse specific stuff like the property store Mediators can use to communicate with each other, or the list of stages making up the routing path we've been talking about.
So there could be several interfaces for these things or they could all be munged together into the one SynapseMessage interface along the lines of:
interface SynapseMessage {
get/set Envelope
get/set Body?
get/set all the WSA stuff
isRequest()
isResponse()
isFault()
get/set SOAP action
get/set MTOM and ReST stuff
synapseMessage copy()
// maybe there could be a getSynapseContext which would contain all the following:
Object getProperty(String)
setProperty(String, Object)
Iterator getPropertyNames()
List getNextStages()
setNextStages(List)
insertStage(Stage, afterStage)?
List getResponseStages()
setResponseStages(List)
insertResponseStage(Stage, afterStage)?
SynapseConfiguration getSynapseConfiguration()
injectMessage(SynapseMessage)
}
...antOn 11/14/05, Paul Fremantle <[EMAIL PROTECTED] > wrote:Ant
Depends what kind of code you want to write I guess. The reason I separated out the EnvAware and ConfigAware interfaces was because their lifecycle is different to the mediate() method. A mediator should only need to look at its config once.
PaulOn 11/14/05, ant elder < [EMAIL PROTECTED]> wrote:I guess that depends on where those other methods go.
I used to think they should be separate if possible and Synapse could use dependency injection or other interfaces if a Mediator needs access to the other methods, but now I'm starting to think that maybe that just makes things more complicated.
Everything is so nice a simple if there's just the Mediator and SynapseMessage interfaces. The alternative seems to be either a mediate method that has multiple parameters, or multiple Mediator interfaces so you can use a mediate method with just the parameters you require, or several other interfaces like ConfigurationAware, EnvironmentAware etc.
Its like the Axis2 MessageContext. An Axis handler has a simple invoke method which takes a MessageContext and that gives access to everything a handler might need, its not that a Handler has to implement a bunch of other interfaces depending on what it needs to do.
...ant
On 11/14/05, Paul Fremantle <[EMAIL PROTECTED] > wrote:Ant
I guess this would give us some nice independence from everything except OM. I would still prefer not to have all those extra method calls if we can help it.
PaulOn 11/14/05, ant elder <[EMAIL PROTECTED]> 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 = mc}
String getTo() { return mc.geTo(); }
...
}
