Sanjiva Weerawarana wrote:
Sorry for missing the chat. I'd like to make sure I understand the
proposed Env/Context/Config structure:
- SynapseConfig
- contains the model of the definitions & rules to execute
- contains named global properties and their values
- no xml stuff; that's a way of creating this config
- SynapseContext
- running context for any message
- contains message
- contains ref to SynapseConfig
- contains ref to SynapseEnvironment
- contains named local properties and their values; these
props are only good for the current message
- property lookup cascades - if its not found here it looks in
the parent config .. that way you don't have to worry whether
its a local or a global property
- SynapseEnvironment
- has methods for doing stuff (like sending a message)
- is stateless; all those methods take a SynapseContext in
- is not used except by programmers implementing mediators
- I guess we could just use a set of static methods to achieve
this too!
Is this correct?
yes..
In terms of packages, I'd propose:
o.a.synapse.context
SynapseContext
o.a.synapse.config
SynapseConfig
Mediator
SequenceMediator
(and the rest of the classes for the mediator model;
ala Axis* classes)
I think its better to keep mediators under o.a.synapse.mediators as it is..
o.a.synapse.deployment.*
code to read in the synapse.xml file and create the
config
o.a.synapse.core
SynapseEnvironment
We should move axis2 stuff into o.a.synapse.core.axis2 in this case
Looking at this, it seems to me SynapseEnvironment plays exactly the
same role that AxisEngine does: its the way code gets access to the
"core". As such, I'd like to rename it to:
o.a.synapse.engine
SynapseEngine
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
