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?
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)
o.a.synapse.deployment.*
code to read in the synapse.xml file and create the
config
o.a.synapse.core
SynapseEnvironment
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]
