* Now talking on #apache-synapse
* brown.freenode.net sets mode +n #apache-synapse
* brown.freenode.net sets mode +s #apache-synapse
* #apache-synapse :[freenode-info] if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
* paulfremantle (email@example.com) has joined #apache-synapse
saminda Hi Paul
saminda <exactlyone/> comming right up. Thank you for the help
saminda It was really a nice pattern with RH and RHandler
paulfremantle good im glad you like it
saminda do support notification at this point
paulfremantle well its up to the RH
paulfremantle we need to pass the pointer to the ResourceHelper when we register ResourceHandlers
paulfremantle and then they can notify if necessary
paulfremantle and otherwise the ResouceHelper can ask them
saminda just one more question,
paulfremantle we may need a mechanism to say whether ResourceHandlers pull or push
saminda do Synaspe Register the RH or Mediator Register the RH
saminda at what level will be the registration happen
paulfremantle i think it makes sense at the Synapse level
* pvikas (firstname.lastname@example.org) has joined #apache-synapse
paulfremantle hi Vikas
pvikas hi guys..
saminda hi mate
* Hariharasudhan (email@example.com) has joined #apache-synapse
Hariharasudhan hi guys !
pvikas not many people around? i think we should wait for sometime befre starting... what say?
paulfremantle Hi harry
Hariharasudhan hi paul !
saminda oh, does the notification happen, the mediators who will implement the ResourceUpdateAware interface
pvikas are we talking about the resource handler, helper? updating resources at regular intervals??
paulfremantle saminda.... the idea is that if the RHandler notifies the
RHelper, then the RHelper has a list of all mediators that used that
information. The RHelper will then call notify on all of them.
paulfremantle we can start again vikas.... saminda and I were just chatting about the resource handler and helper
* Soumadeep (firstname.lastname@example.org) has joined #apache-synapse
Soumadeep hi guys
saminda hi Somadeep
Soumadeep Soumadeep ;-)
paulfremantle so shall we start out with the ResourceHelper/Handler?
saminda yes Soumadeep :-)
Soumadeep I like what Paul said..
* ant__ (email@example.com) has joined #apache-synapse
Soumadeep it will suffice
ant__ hi. sorry quite late
paulfremantle hi Ant
Hariharasudhan hi Ant
saminda Hi Ant
Soumadeep Hi Ant
pvikas hi Ant
* karni (firstname.lastname@example.org) has joined #apache-synapse
Soumadeep ANt is really popular :-)
paulfremantle another subject we could look at is the <exactlyone> model
paulfremantle (aka switch)
* venkat (email@example.com) has joined #apache-synapse
Soumadeep When you guys are done with switching... can we discuss about whether we need a context for Mediators
saminda well <exactlyone/> is the predecessor of <switch/> in one sense
paulfremantle the idea is fairly simple
paulfremantle each Rule based mediator (regex, xpath etc) sets a property in the message context which says if it matched or not
paulfremantle the <ExactlyOne> mediator runs through all children until one matches
paulfremantle its like switch
paulfremantle except you can have it match on different things....
saminda yes, but it mixes <regex/> and <xpath/>
paulfremantle i.e. you can have a regex then an xpath
paulfremantle exactly saminda
paulfremantle yes its influenced by wsp:exactlyone
paulfremantle but it is ordered
paulfremantle i.e. its execution not declaration
saminda paul one thing, <exactlyone/> should support only <regex/> and <xpaths/>
saminda it should not contain mediators like <classmediator/>. <servicemediator/> etc
saminda they are static and alway pass
pvikas isn't switch always on a condition??
paulfremantle yes this is not exactly switch
saminda this time around condition will be provided by either <xpath/> or <regex/>
paulfremantle saminda.... the other alternative is that it only continues if the mediator say "didn't match"
saminda they are the conditional mediators
saminda <default/> will do it
paulfremantle so shall we move on to mediator context?
Soumadeep Like I mentioned earlier... do you think there would be a need for one?
paulfremantle can you give me the interface?
paulfremantle what you mean?
saminda is this one related to the MedationContext i've put up long time ago
saminda a context that exist per message
saminda like Axis2's operationContex
Soumadeep something like when the processor encounters a mediator and
we have some property associated with that specific mediator, shouldn't
it be just available to that mediator per se
paulfremantle can you give me a code example?
Soumadeep Synapse Process I mean
Soumadeep Just a sec
Soumadeep let me pull it up
Soumadeep In ClassMediatorConfigurator:
Soumadeep Iterator itr = el.getChildrenWithName(new QName("ParameterObject"));
SynapseObject so =
Soumadeep wait let me give you context
Soumadeep Synapse.xml Fragment
Soumadeep <classmediator name="Management" class="org.apache.synapse.mediators.resource.ResourceMediator">
<Attribute name="size" type="INTEGER">2</Attribute>
Soumadeep Paul,I know your aversion towards SynapseObject... so just ignore.. it
paulfremantle so is the idea to be able to share properties amongst mediators?
Soumadeep yes... and also have a mediator specific place holder
ant__ but this is static config context right? Not just things any mediator can set on the messagecontext?
paulfremantle good question ant
paulfremantle so in Axis2 terms this is the ****Description
paulfremantle not the ****Context
* Mukund (firstname.lastname@example.org) has joined #apache-synapse
saminda one more thingy, This will cause SynaspeObject to be a core feature
* Rajesh_Koilpilla (email@example.com) has joined #apache-synapse
paulfremantle so firstly there is already a place to put properties in the SynapseEnvironment
paulfremantle at the moment there is a "addProcessor" and "lookupProcessor" on SynapseEnvironment
paulfremantle i think the simple model would be for Mediators to use the get/setProperty in SynapseEnvironment
Mukund I'm sorry, I dont have so much of context
Mukund but isnt SynapseEnvironment transient
Mukund or is it persisted in Syanpse.xml
Mukund isnt that the problem we are trying to solve
paulfremantle the SynapseEnv is loaded from the Synapse.xml
Mukund ah ok
Mukund but of course
Mukund there needs to be global configuration in synapse.xml
Mukund to load the global mediator agnostic properties
saminda meaning ??
Mukund in the SynapseEnv
paulfremantle yes we do need that
paulfremantle i have a suggestion
paulfremantle firstly, we should allow setting of the named properties in the SynEnv from the synapse.xml
Mukund we agree
Mukund the location where it needs to be maintained in synapse.xml is?
paulfremantle secondly, we should allow the properties in a mediator to be loaded using the redirection of a resource handler
paulfremantle <ref uri="synapse.xml
paulfremantle hit enter halfway through a thought.....
paulfremantle i guess what im trying to write is that you should be
able to "import" or refer to properties elsewhere in the same way you
can refer to other mediators
paulfremantle we need to add a section in synapse.xml
saminda so synapse.xml has rules and some import references to elseware
Mukund yes, shouldnt the imports always be at the beginning
saminda thus the main purpose of synapse.xml is not to have rules, but to hvae rules+imports
Mukund I think random inserts in the middle are like refs
Mukund and external references of resources are like imports
saminda so are we thinking of seperating the two
Mukund which one are we talking about
paulfremantle well ordering in XML isn't important but I agree that for readability it should be at the beginning
Mukund imports - obsolutely great idea
Mukund should be at the beginning
saminda like synapse.xml for Synapse stuff and ruleadmin.xml for mediator stuff ??
Mukund but how is this related to global properties
Mukund imports are a different construct
paulfremantle i guess what im proposing is that the synapse xml can be constructed of both inline xml and imports
paulfremantle and either can be referenced from the main ruleset and mediators
Mukund no issues
paulfremantle i hoped we were agreeing! :-)
Mukund that's new
paulfremantle you are right that imports and references are orthogonal
Mukund how do we do references
Mukund do we need them
paulfremantle at the moment we only do references for mediators
paulfremantle not for properties
paulfremantle but i think we can extend the model easily
saminda with the <property/> you have introduce
saminda using it with <define/> we can reference simple properties
paulfremantle saminda it is independent of <property>
paulfremantle if we needed to we could do it at the XML level
Mukund isnt that xinclude?
paulfremantle guys... im afraid I have to head out early
paulfremantle yes mukund
Mukund we should just use xinclude
Mukund for inline includes
Mukund and do a synapse specific import
Mukund which will be diffferent
Mukund is there a schema for synapse xml
Mukund should we try to agree upon one
paulfremantle no! not yet
Mukund I know I suggested this in the f2f
paulfremantle we should build one
Mukund and also tried working on one :-(
Mukund let me spend some time trying to come up with one
Mukund you can leave if you got to
paulfremantle can someone post the chat log?
Mukund of couse we will
Mukund is there anything else on the agenda
saminda i can
paulfremantle well we didn't get deep into SynapseObject
paulfremantle but maybe we should continue that on the mailing list
saminda ADB will do fine for now :)
Mukund wow, longer thread
Mukund ADB will be fine
Mukund if we decide on XML fragments
Mukund but I dont think we are in agreement on XMl fragments yet