On Tue, Apr 27, 2010 at 2:43 PM, Ruwan Linton <ruwan.lin...@gmail.com>wrote:
> Congratulations! > > +1 for the iterative development approach. > > BTW: you could also contribute to the synapse 2.0 release ;-) > Sure I'm glad to do some fixs > > Thanks, > Ruwan > > > On Tue, Apr 27, 2010 at 12:04 PM, Charith Wickramarachchi < > charith.dhanus...@gmail.com> wrote: > >> Hi all , >> >> My GSoC proposal got accepted.So i would like to thanks you all for the >> support and ideas you gave. >> I have start working on a patch for the in memory message store.Personally >> i prefer to do this project in an iterative way so that i can provide >> patches and it will get reviewed and get apply to the tunk time to time. >> >> I'll be glad to get your feedbacks while doing the project. >> >> thanks, >> /Charith >> >> >> >> On Wed, Apr 7, 2010 at 2:32 PM, Charith Wickramarachchi < >> charith.dhanus...@gmail.com> wrote: >> >>> I submited the Proposal in the Google OpenSource Program WebSite >>> >>> Following are the links to Proposal in Google Space and Apache Wiki Space >>> >>> >>> >>> http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/charith/t127030145826<http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/charith/t127030145826> >>> >>> >>> http://wiki.apache.org/general/charith/gsoc2010/synapse_deadLetter >>> >>> thanks, >>> Charith >>> >>> On Fri, Apr 2, 2010 at 2:28 PM, Charith Wickramarachchi < >>> charith.dhanus...@gmail.com> wrote: >>> >>>> I add the project proposal to the Apache Wiki >>>> space.http://wiki.apache.org/general/charith/gsoc2010/synapse_deadLetter >>>> >>>> >>>> thanks, >>>> Charith >>>> >>>> >>>> On Fri, Apr 2, 2010 at 12:20 AM, Charith Wickramarachchi < >>>> charith.dhanus...@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Apr 1, 2010 at 10:50 AM, Hiranya Jayathilaka < >>>>> hiranya...@gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Sun, Mar 28, 2010 at 1:25 PM, Charith Wickramarachchi < >>>>>> charith.dhanus...@gmail.com> wrote: >>>>>> >>>>>>> Thanks you for your feed back. >>>>>>> >>>>>>> I updated it with the changes you proposed.You can find the new >>>>>>> document here >>>>>>> [1]<http://socghop.appspot.com/document/show/user/charith/deadletterchannel_apache_synapse> >>>>>>> >>>>>> >>>>>> Charith, formatting of the document seems to be messed up a little >>>>>> bit. >>>>>> >>>>> >>>>> Yes. i 'm having a issue with google docs provided in the Summer of >>>>> code site. >>>>> google >>>>> >>>>>> Please have a look. Also once you are done, shall we bring this into >>>>>> the Apache Wiki. I'd like to have everything related to this >>>>>> >>>>> project in the ASF space. >>>>>> Sure.I'll put new proposal in a Apache Wiki Space. >>>>>> >>>>> >>>>> /charith >>>>> >>>>> >>>>>> Thanks, >>>>>> Hiranya >>>>>> >>>>>> >>>>>>> >>>>>>> thanks, >>>>>>> Charith >>>>>>> >>>>>>> [1 >>>>>>> ]http://socghop.appspot.com/document/show/user/charith/deadletterchannel_apache_synapse >>>>>>> >>>>>>> <http://socghop.appspot.com/document/show/user/charith/deadletterchannel_apache_synapse> >>>>>>> >>>>>>> On Sun, Mar 28, 2010 at 10:32 AM, Hiranya Jayathilaka < >>>>>>> hiranya...@gmail.com> wrote: >>>>>>> >>>>>>>> Hi Charith, >>>>>>>> >>>>>>>> On Sat, Mar 27, 2010 at 2:35 PM, Charith Wickramarachchi >>>>>>>> <charith.dhanus...@gmail.com> wrote: >>>>>>>> > Hi, >>>>>>>> > >>>>>>>> > I wrote draft Proposal for the Project and its available at [1] >>>>>>>> > your feed backs on changes or improvements to the proposal is >>>>>>>> highly >>>>>>>> > appreciated. >>>>>>>> >>>>>>>> I had a quick look at the proposal. Pretty good stuff. I would also >>>>>>>> like to see a sample message store configuration in the document >>>>>>>> along >>>>>>>> with an endpoint configuration which uses the message store. Also I >>>>>>>> believe you can include the mediator development (currently listed >>>>>>>> under optional features) in the second development phase. I don't >>>>>>>> think writing a mediator takes that much time. >>>>>>>> >>>>>>>> Also please cite the source of your diagram ;) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Hiranya >>>>>>>> >>>>>>>> > >>>>>>>> > [1] >>>>>>>> http://socghop.appspot.com/document/show/user/charith/deadletterchannel_synapse >>>>>>>> > >>>>>>>> > On Wed, Mar 24, 2010 at 10:40 AM, Charith Wickramarachchi >>>>>>>> > <charith.dhanus...@gmail.com> wrote: >>>>>>>> >> >>>>>>>> >> Thank you all for your feedbacks. >>>>>>>> >> >>>>>>>> >> I'm currently looking at the Synapse Fault Handling Mechanism to >>>>>>>> Find a >>>>>>>> >> way to implement this. >>>>>>>> >> As far as i understand synapse uses a Stack base Fault handling >>>>>>>> Mechanism >>>>>>>> >> to achieve fault handling >>>>>>>> >> at the different Levels of the Sequences and Endpoints in a >>>>>>>> correct >>>>>>>> >> order. >>>>>>>> >> >>>>>>>> >> I'm having some questions now. >>>>>>>> >> >>>>>>>> >> Implementing this with the Endpoint fault handling is clear to >>>>>>>> me.Where we >>>>>>>> >> can put the redelivery parameters/policies and Message Store at >>>>>>>> the end >>>>>>>> >> point so that at a failure it will considerer that parameters >>>>>>>> before >>>>>>>> >> executing the fault handler (so it will try to re deliver it >>>>>>>> according to >>>>>>>> >> the parameters /policy s specified and if failed it will store >>>>>>>> the Message >>>>>>>> >> ). As Amila said there we can use WS-RM policies. >>>>>>>> >> >>>>>>>> >> Do we need to impliment this with the Sequences too ? >>>>>>>> >> >>>>>>>> >> Then we need to have a machansim to find how to determine the >>>>>>>> sequnce name >>>>>>>> >> and at which level this message has failed from the stored Meta >>>>>>>> data (Since >>>>>>>> >> same sequnces can be re used at deffrent levels). >>>>>>>> >> >>>>>>>> >> my next Question is about Stroing the Message? >>>>>>>> >> >>>>>>>> >> Since idea if storing the message is to be able to re generate >>>>>>>> the same >>>>>>>> >> message again. Are we going to store the MessageContext object ? >>>>>>>> (And in a >>>>>>>> >> persistent storage case we can use a Adapter and serialise that >>>>>>>> object.)Or >>>>>>>> >> is there a better memory effcient way? >>>>>>>> >> >>>>>>>> >> WDYT? >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> On Mon, Mar 22, 2010 at 10:57 AM, Amila Suriarachchi >>>>>>>> >> <amilasuriarach...@gmail.com> wrote: >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi >>>>>>>> >>> <charith.dhanus...@gmail.com> wrote: >>>>>>>> >>>> >>>>>>>> >>>> Hi, >>>>>>>> >>>> >>>>>>>> >>>> Thanks for the reply and your feed back. I looked in to the >>>>>>>> Apache Camel >>>>>>>> >>>> DeadLetter channel features and its uses. >>>>>>>> >>>> And also FUSE Mediation Router support this EIP too.[1]. >>>>>>>> >>>> >>>>>>>> >>>> As per my current understanding Re delivery policies plays a >>>>>>>> major role >>>>>>>> >>>> when supporting this Pattern.Where users can configure the re >>>>>>>> delivery >>>>>>>> >>>> policy so that system will retry to deliver before message >>>>>>>> added to the >>>>>>>> >>>> Message store according to the policy defined. >>>>>>>> >>> >>>>>>>> >>> one option is to use ws-rm. which gives you a standard mechanism >>>>>>>> of >>>>>>>> >>> handling retransmissions. >>>>>>>> >>> >>>>>>>> >>> thanks, >>>>>>>> >>> Amila. >>>>>>>> >>>> >>>>>>>> >>>> And also i found that there is a requirement to make enable to >>>>>>>> execute a >>>>>>>> >>>> sequence after message is added to the message store(or just >>>>>>>> before adding >>>>>>>> >>>> to Message Store). >>>>>>>> >>>> So that it can be used to send notifications to the pre >>>>>>>> configured >>>>>>>> >>>> persons telling that Messages has been added to the Message >>>>>>>> store/Dead >>>>>>>> >>>> letter channel. >>>>>>>> >>>> >>>>>>>> >>>> I'm currently looking in to the Synapse code and architecture >>>>>>>> to figure >>>>>>>> >>>> out ways of implementing this.So your feed back is highly >>>>>>>> appreciated. >>>>>>>> >>>> >>>>>>>> >>>> As i understand synapse Currenty has a mechanism to plug custom >>>>>>>> >>>> configuration elements. >>>>>>>> >>>> ConfigurationFactoryAndSerializerFinder does that. So it looks >>>>>>>> like that >>>>>>>> >>>> the requirement Hiranya Mentioned about beging able to plug >>>>>>>> custom Message >>>>>>>> >>>> Stores easily can be archived using that Service provider >>>>>>>> machanishm. >>>>>>>> >>>> >>>>>>>> >>>> Your ideas on better ways of implimenting this feature is >>>>>>>> highly >>>>>>>> >>>> appriciated. >>>>>>>> >>>> >>>>>>>> >>>> thanks, >>>>>>>> >>>> /Charith >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> [1] >>>>>>>> http://fusesource.com/docs/router/1.6/eip/MsgCh-DeadLetter.html >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> On Thu, Mar 18, 2010 at 9:09 PM, Hiranya Jayathilaka >>>>>>>> >>>> <hiranya...@gmail.com> wrote: >>>>>>>> >>>>> >>>>>>>> >>>>> Hi Charith, >>>>>>>> >>>>> >>>>>>>> >>>>> There are actually several ways we can tackle this problem. >>>>>>>> And right >>>>>>>> >>>>> now even I'm not sure which approach is the best. We need to >>>>>>>> discuss >>>>>>>> >>>>> the options we got and then get to a suitable and feasible >>>>>>>> solution. >>>>>>>> >>>>> >>>>>>>> >>>>> One solution is to introduce a new top level component (as you >>>>>>>> have >>>>>>>> >>>>> suggested) for the message stores. The sequences already have >>>>>>>> the >>>>>>>> >>>>> onError attribute which can be used to specify a custom fault >>>>>>>> sequence >>>>>>>> >>>>> to be executed in case of an error. If a custom fault sequence >>>>>>>> is not >>>>>>>> >>>>> specified the default fault sequence will take over the >>>>>>>> control. Proxy >>>>>>>> >>>>> services also have the concept of fault sequences. So we need >>>>>>>> to >>>>>>>> >>>>> figure out how to link up this concept of fault sequences with >>>>>>>> the >>>>>>>> >>>>> message store top level element. One option would be to write >>>>>>>> a >>>>>>>> >>>>> mediator which can be placed in a fault sequence. The mediator >>>>>>>> will >>>>>>>> >>>>> take the faulty message and place it in a specified message >>>>>>>> store. >>>>>>>> >>>>> >>>>>>>> >>>>> On the other hand we can just have the mediator. The message >>>>>>>> store >>>>>>>> >>>>> concept can be built into the mediator itself so we don't need >>>>>>>> a new >>>>>>>> >>>>> top level element. This approach however has the disadvantage >>>>>>>> of not >>>>>>>> >>>>> being able to share and reuse a single message store instance >>>>>>>> across >>>>>>>> >>>>> the Synapse configuration. >>>>>>>> >>>>> >>>>>>>> >>>>> Another possible approach is to have the message store top >>>>>>>> level >>>>>>>> >>>>> element and then introduce an onError attribute to the >>>>>>>> endpoint top >>>>>>>> >>>>> level element. This is the approach suggested by Ruwan at [1]. >>>>>>>> >>>>> >>>>>>>> >>>>> Please consider all these options when working on your >>>>>>>> proposal. Also >>>>>>>> >>>>> please take a look at some existing implementations of the >>>>>>>> dead letter >>>>>>>> >>>>> channel pattern. FYI Apache Camel supports this pattern.If we >>>>>>>> can >>>>>>>> >>>>> reuse some of the stuff done in Camel that would be fine too. >>>>>>>> >>>>> Personally though I prefer having our native implementation of >>>>>>>> the >>>>>>>> >>>>> dead letter channel pattern. And to be frank I does like the >>>>>>>> idea of >>>>>>>> >>>>> having the message store as a top level element in Synapse. >>>>>>>> >>>>> >>>>>>>> >>>>> I'm sure other members of the team also have a lot of ideas >>>>>>>> with >>>>>>>> >>>>> regard to this project. Let's give them sometime and see what >>>>>>>> they >>>>>>>> >>>>> think too :) >>>>>>>> >>>>> >>>>>>>> >>>>> Thanks, >>>>>>>> >>>>> Hiranya >>>>>>>> >>>>> >>>>>>>> >>>>> [1] - https://issues.apache.org/jira/browse/SYNAPSE-263 >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> On Thu, Mar 18, 2010 at 12:36 PM, Charith Wickramarachchi >>>>>>>> >>>>> <charith.dhanus...@gmail.com> wrote: >>>>>>>> >>>>> > Hi Hiranya, >>>>>>>> >>>>> > >>>>>>>> >>>>> > This I went through idea you mention in the proposal. >>>>>>>> >>>>> > >>>>>>>> >>>>> > This is the picture of the High level design in my mind >>>>>>>> after looking >>>>>>>> >>>>> > into >>>>>>>> >>>>> > it. >>>>>>>> >>>>> > The Message Store will be a high level synapse >>>>>>>> configuration >>>>>>>> >>>>> > construct (at >>>>>>>> >>>>> > the sequence , endpoint ... )level. >>>>>>>> >>>>> > >>>>>>>> >>>>> > >>>>>>>> >>>>> > Ex >>>>>>>> >>>>> > <msg_store name ="foo" class = >>>>>>>> >>>>> > "org.apache.synapse.core.JDBCMessageStore" >>>>>>>> >>>>> > .....> >>>>>>>> >>>>> > Other message store specific details goes here ex : >>>>>>>> scheduling >>>>>>>> >>>>> > info , >>>>>>>> >>>>> > user names , urls >>>>>>>> >>>>> > </msg_store> >>>>>>>> >>>>> > >>>>>>>> >>>>> > and sequences and the endpoints must be able to point to >>>>>>>> this store >>>>>>>> >>>>> > with a >>>>>>>> >>>>> > parameter like "on fault" >>>>>>>> >>>>> > and also there can be multiple message stores that can be >>>>>>>> reused. >>>>>>>> >>>>> > >>>>>>>> >>>>> > Is this the idea in your mind? >>>>>>>> >>>>> > >>>>>>>> >>>>> > WDYT? your feed back will be highly appreciated so that i >>>>>>>> can improve >>>>>>>> >>>>> > my >>>>>>>> >>>>> > proposal. >>>>>>>> >>>>> > >>>>>>>> >>>>> > thank, >>>>>>>> >>>>> > /Charith >>>>>>>> >>>>> > >>>>>>>> >>>>> > On Thu, Mar 18, 2010 at 12:03 PM, Charith Wickramarachchi >>>>>>>> >>>>> > <charith.dhanus...@gmail.com> wrote: >>>>>>>> >>>>> >> >>>>>>>> >>>>> >> Hi, >>>>>>>> >>>>> >> >>>>>>>> >>>>> >> I m a Undergraduate Interested in this Project idea. I have >>>>>>>> worked >>>>>>>> >>>>> >> with >>>>>>>> >>>>> >> the synapse code base So i 'm glad to do this project as my >>>>>>>> GSoC >>>>>>>> >>>>> >> project. >>>>>>>> >>>>> >> >>>>>>>> >>>>> >> I'm now looking in to the ways of designing and >>>>>>>> implementing this.I >>>>>>>> >>>>> >> m >>>>>>>> >>>>> >> willing to have more design level ideas regarding this. >>>>>>>> >>>>> >> >>>>>>>> >>>>> >> I'll come up with a proposal for this soon. >>>>>>>> >>>>> >> >>>>>>>> >>>>> >> thanks, >>>>>>>> >>>>> >> >>>>>>>> >>>>> >> Charith >>>>>>>> >>>>> >> >>>>>>>> >>>>> >> On Wed, Mar 17, 2010 at 5:20 PM, Hiranya Jayathilaka (JIRA) >>>>>>>> >>>>> >> <j...@apache.org> wrote: >>>>>>>> >>>>> >>> >>>>>>>> >>>>> >>> [GSoC] Implement a Dead Letter Channel for Synapse >>>>>>>> >>>>> >>> -------------------------------------------------- >>>>>>>> >>>>> >>> >>>>>>>> >>>>> >>> Key: SYNAPSE-618 >>>>>>>> >>>>> >>> URL: >>>>>>>> >>>>> >>> https://issues.apache.org/jira/browse/SYNAPSE-618 >>>>>>>> >>>>> >>> Project: Synapse >>>>>>>> >>>>> >>> Issue Type: New Feature >>>>>>>> >>>>> >>> Components: Core, Endpoints >>>>>>>> >>>>> >>> Reporter: Hiranya Jayathilaka >>>>>>>> >>>>> >>> Fix For: FUTURE >>>>>>>> >>>>> >>> >>>>>>>> >>>>> >>> >>>>>>>> >>>>> >>> Currently when Synapse attempts to send a message and if >>>>>>>> it fails, >>>>>>>> >>>>> >>> following actions can be configured to deal with the >>>>>>>> error: >>>>>>>> >>>>> >>> >>>>>>>> >>>>> >>> * Execute a fault sequence and handle the failed request >>>>>>>> gracefully >>>>>>>> >>>>> >>> * Fail-over to a different endpoint >>>>>>>> >>>>> >>> >>>>>>>> >>>>> >>> In addition to these, Synapse ESB should support the "dead >>>>>>>> letter >>>>>>>> >>>>> >>> channel" enterprise integration pattern to deal with >>>>>>>> various errors >>>>>>>> >>>>> >>> that >>>>>>>> >>>>> >>> might occur during mediation or while sending. With the >>>>>>>> dead letter >>>>>>>> >>>>> >>> channel, >>>>>>>> >>>>> >>> the failed message will be put into a message store in the >>>>>>>> ESB. >>>>>>>> >>>>> >>> Later the >>>>>>>> >>>>> >>> ESB can retry to send the messages in the message store. >>>>>>>> >>>>> >>> >>>>>>>> >>>>> >>> We should be able to have multiple implementations of the >>>>>>>> actual >>>>>>>> >>>>> >>> message >>>>>>>> >>>>> >>> store and should be able to configure which store to use >>>>>>>> for a >>>>>>>> >>>>> >>> particular >>>>>>>> >>>>> >>> scenario. Users should be able to implement their own >>>>>>>> message >>>>>>>> >>>>> >>> stores and >>>>>>>> >>>>> >>> plug into the ESB easily. To start with we can have a >>>>>>>> simple >>>>>>>> >>>>> >>> in-memory >>>>>>>> >>>>> >>> message store and a persisting store based on JDBC or JMS. >>>>>>>> >>>>> >>> >>>>>>>> >>>>> >>> References: >>>>>>>> >>>>> >>> http://www.eaipatterns.com/DeadLetterChannel.html >>>>>>>> >>>>> >>> https://issues.apache.org/jira/browse/SYNAPSE-263 >>>>>>>> >>>>> >>> >>>>>>>> >>>>> >>> Possible Mentors: >>>>>>>> >>>>> >>> Hiranya Jayathilaka >>>>>>>> >>>>> >>> >>>>>>>> >>>>> >>> >>>>>>>> >>>>> >>> -- >>>>>>>> >>>>> >>> This message is automatically generated by JIRA. >>>>>>>> >>>>> >>> - >>>>>>>> >>>>> >>> You can reply to this email to add a comment to the issue >>>>>>>> online. >>>>>>>> >>>>> >>> >>>>>>>> >>>>> >>> >>>>>>>> >>>>> >>> >>>>>>>> >>>>> >>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>> >>> To unsubscribe, e-mail: >>>>>>>> dev-unsubscr...@synapse.apache.org >>>>>>>> >>>>> >>> For additional commands, e-mail: >>>>>>>> dev-h...@synapse.apache.org >>>>>>>> >>>>> >>> >>>>>>>> >>>>> >> >>>>>>>> >>>>> >> >>>>>>>> >>>>> >> >>>>>>>> >>>>> >> -- >>>>>>>> >>>>> >> Charith Dhanushka Wickramarachchi >>>>>>>> >>>>> >> http://charithwiki.blogspot.com/ >>>>>>>> >>>>> >> >>>>>>>> >>>>> > >>>>>>>> >>>>> > >>>>>>>> >>>>> > >>>>>>>> >>>>> > -- >>>>>>>> >>>>> > Charith Dhanushka Wickramarachchi >>>>>>>> >>>>> > http://charithwiki.blogspot.com/ >>>>>>>> >>>>> > >>>>>>>> >>>>> > >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> -- >>>>>>>> >>>>> Hiranya Jayathilaka >>>>>>>> >>>>> Software Engineer; >>>>>>>> >>>>> WSO2 Inc.; http://wso2.org >>>>>>>> >>>>> E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 >>>>>>>> >>>>> Blog: http://techfeast-hiranya.blogspot.com >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >>>>>>>> >>>>> For additional commands, e-mail: dev-h...@synapse.apache.org >>>>>>>> >>>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> -- >>>>>>>> >>>> Charith Dhanushka Wickramarachchi >>>>>>>> >>>> http://charithwiki.blogspot.com/ >>>>>>>> >>>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> -- >>>>>>>> >>> Amila Suriarachchi >>>>>>>> >>> WSO2 Inc. >>>>>>>> >>> blog: http://amilachinthaka.blogspot.com/ >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> -- >>>>>>>> >> Charith Dhanushka Wickramarachchi >>>>>>>> >> http://charithwiki.blogspot.com/ >>>>>>>> >> >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > -- >>>>>>>> > Charith Dhanushka Wickramarachchi >>>>>>>> > http://charithwiki.blogspot.com/ >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Hiranya Jayathilaka >>>>>>>> Software Engineer; >>>>>>>> WSO2 Inc.; http://wso2.org >>>>>>>> E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 >>>>>>>> Blog: http://techfeast-hiranya.blogspot.com >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@synapse.apache.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Charith Dhanushka Wickramarachchi >>>>>>> http://charithwiki.blogspot.com/ >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Hiranya Jayathilaka >>>>>> Software Engineer; >>>>>> WSO2 Inc.; http://wso2.org >>>>>> E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 >>>>>> Blog: http://techfeast-hiranya.blogspot.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Charith Dhanushka Wickramarachchi >>>>> http://charithwiki.blogspot.com/ >>>>> >>>>> >>>> >>>> >>>> -- >>>> Charith Dhanushka Wickramarachchi >>>> http://charithwiki.blogspot.com/ >>>> >>>> >>> >>> >>> -- >>> Charith Dhanushka Wickramarachchi >>> http://charithwiki.blogspot.com/ >>> >>> >> >> >> -- >> Charith Dhanushka Wickramarachchi >> http://charithwiki.blogspot.com/ >> >> > > > -- > Ruwan Linton > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb > WSO2 Inc.; http://wso2.org > email: ru...@wso2.com; cell: +94 77 341 3097 > blog: http://ruwansblog.blogspot.com > -- Charith Dhanushka Wickramarachchi http://charithwiki.blogspot.com/
