I will come up with the set of mediators to be re-factored and the modified syntax for each mediator. I think, backward compatibility will come in to the picture here. So, how should we deal with it?
On Wed, Oct 5, 2011 at 9:54 AM, Srinath Perera <[email protected]> wrote: > Are we agreeing to Revamping? Hiranya, do you have any concerns? > > On Tue, Oct 4, 2011 at 12:15 PM, Amila Suriarachchi <[email protected]> > wrote: > > > > > > On Tue, Oct 4, 2011 at 11:45 AM, Srinath Perera <[email protected]> > wrote: > >> > >> +1 .. if we can replace all with one mediator .. that is great! but we > >> have to carefully design the syntax to make sure final result is > >> natural for all cases. > > > > I think there are two ends for this. One is making it general. Other > think > > is make common case simple. > > > > Current filter (it actually does some thing like if) mediator > configurations > > can be as follows. > > > > <filter xpath="//ns1:foo/ns1:bar/text() == 'test'"> > > <then /> > > <else /> > > </filter> > > <filter source="//ns1:foo/ns2:bar/text()" regex="test"> > > <then /> > > <else /> > > </filter> > > > > former 'xpath' is referred to an xpath returning a boolean while the > > 'source' attribute refer to an xpath returning a text value. Here it has > > tried to cover different specific scenarios which make that particular > > occasion to use it easily. > > > > But we if follow an method like BPEL by using another copy mediator (in > fact > > I think these are not mediators but some language constructs). It would > have > > written like this. > > > > <variable name='foo' > > > > > <copy> > > <from source='soapbody' xpath="//ns1:foo/ns1:bar/text()"/> > > <to source='$foo' /> > > </copy> > > > > <if condition="$foo =='test'"> > > <then/> > > <else/> > > </if> > > > > then it is more generic. And no need to repeat the xpath, source > veriables > > with each mediator. But for a simple xpath based filter need to use > another > > copy mediator etc .. > > > > thanks, > > Amila. > > > > > > > > > > > >> > >> --Srinath > >> > >> On Fri, Sep 30, 2011 at 3:03 PM, Kasun Indrasiri <[email protected]> > wrote: > >> > Hi all, > >> > In the current ESB implementation we have couple of mediators for > >> > message > >> > routing. While 'Filter' and 'Switch' mediators provide basic level of > >> > message filtering, router mediator is also doing very similar to what > >> > filter/switch mediators do. The usage of Router mediator is rare and > >> > often > >> > got replaced by filter/switch mediators. So, IMO, Router Mediator is > >> > redundant, unless it provides some advance/complex routing logic > >> > support. > >> > In the ESB 4.0.0 release, we introduces 'Conditional Router', which is > >> > intended to route messages based on HTTP headers, query parameters and > >> > url. > >> > However, this doesn't support routing based on message payload. But > >> > unlike > >> > 'Router', the 'Conditional Router' introduces uses the concepts of > >> > 'Evaluators' (And, Or, Match, Equal, Not) that can be utilize to > >> > construct > >> > complex routing logics. > >> > eg: > >> > <conditionalRouter continueAfter="false"> > >> > <conditionalRoute breakRoute="false"> > >> > <condition> > >> > <and xmlns=""> > >> > <match type="header" > >> > source="my_custom_header1" regex="foo.*"/> > >> > <match type="url" > >> > regex="/services/StockQuoteProxy.*"/> > >> > </and> > >> > </condition> > >> > <target sequence="cnd2_seq"/> > >> > </conditionalRoute> > >> > <conditionalRoute breakRoute="false"> > >> > <condition> > >> > <and xmlns=""> > >> > <match type="header" > >> > source="my_custom_header2" regex="bar.*"/> > >> > <equal type="param" source="qparam1" > >> > value="qpv_foo"/> > >> > <or> > >> > <match type="url" > >> > regex="/services/StockQuoteProxy.*"/> > >> > <match type="header" > >> > source="my_custom_header3" regex="foo.*"/> > >> > </or> > >> > <not> > >> > <equal type="param" > source="qparam2" > >> > value="qpv_bar"/> > >> > </not> > >> > </and> > >> > </condition> > >> > <target sequence="cnd3_seq"/> > >> > </conditionalRoute> > >> > </conditionalRouter> > >> > So, we can easily add message level routing capability(so that we can > >> > drop > >> > Router mediator) to Conditional Router and with that we'll get the > power > >> > of > >> > using evaluators for message level routing as well. Having bunch of > >> > mediators that's doing the similar thing, cause a negative effect on > >> > ESB's > >> > usability. > >> > (Most of the pointed listed here, were discussed during last > code-review > >> > of > >> > Group-D.) > >> > > >> > > >> > [1] http://wso2.org/project/esb/java/4.0.0/docs/mediator_guide.html > >> > > >> > Thanks, > >> > -- > >> > Kasun Indrasiri > >> > Associate Technical Lead > >> > WSO2, Inc.; http://wso2.com > >> > lean.enterprise.middleware > >> > > >> > cell: +94 71 536 4128 > >> > Blog : http://kasunpanorama.blogspot.com/ > >> > > >> > >> > >> > >> -- > >> ============================ > >> Srinath Perera, Ph.D. > >> Senior Software Architect, WSO2 Inc. > >> Visiting Faculty, University of Moratuwa > >> Member, Apache Software Foundation > >> Research Scientist, Lanka Software Foundation > >> Blog: http://srinathsview.blogspot.com/ > >> _______________________________________________ > >> Carbon-dev mailing list > >> [email protected] > >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > > > > > > > -- > ============================ > Srinath Perera, Ph.D. > http://www.cs.indiana.edu/~hperera/ > http://srinathsview.blogspot.com/ > -- Kasun Indrasiri Associate Technical Lead WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 71 536 4128 Blog : http://kasunpanorama.blogspot.com/
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
