On 8/17/10 11:06 AM, Supun Kamburugamuva wrote: > We can extend this concept to have versioning for Synapse > Configurations as well. This is a basic user requirement. When user > does a change to a synapse configuration and save it we can give a new > version to the configuration and later user can decide which version > should be active. Exactly, you read my mind :-)
Further, in the future, when we have the configuration referencing mechanism and the mediation debugger, we should be able to play a message via a non active developing version of the configuration and debug it, while developing. After it is done, you can make it the active one. Yes, I am talking about the ESB 4.0 :-) Ruwan > Thanks, > Supun.. > > On Tue, Aug 17, 2010 at 10:18 AM, Samisa Abeysinghe<[email protected]> wrote: >> >> On Tue, Aug 17, 2010 at 9:20 AM, Hiranya Jayathilaka<[email protected]> >> wrote: >>> >>> On Tue, Aug 17, 2010 at 7:39 AM, Samisa Abeysinghe<[email protected]> >>> wrote: >>>> >>>> On Mon, Aug 16, 2010 at 10:54 AM, Supun Kamburugamuva<[email protected]> >>>> wrote: >>>>> There are two ways to implement this. >>>>> >>>>> 1. We can simply read the configuration from the file system and them >>>>> override the current synapse configuration with the sample >>>>> configuration. This leads to the destruction of current configuration. >>>>> >>>>> 2. The second approach is to build the synapse configuration from the >>>>> beginning. This includes initializing the persistence again to fit the >>>>> sample etc. This preserves the current ESB configuration. >>>> In case of the test automation framework, what we are doing is to use >>>> admin services and update the synapse config with the admin service calls. >>> I don't think any of the existing admin services fit the task in hand. IMO >>> we need a new admin service. All the existing services are built around a >>> single Synapse config. But the samples component should be able to manage >>> multiple configurations - the main configuration and many sample >>> configurations. Switching to a sample config should not wipe out the main >>> config. >>> >>>> The rationale is that, we have the provision for users to edit the >>>> synapse config with management console and update that via admin service >>>> and >>>> get ESB to work on the new updated config. >>>> We already have the test automation team doing this. >>>> >>>> I think we can re-use that code and build this sample component based on >>>> that. >>> Well, I'm not aware of the latest status of the test framework. Do you >>> mean it has the ability to create multiple configurations and switch among >>> them if needed (without wiping out each other)? If that capability is there >>> then we +1 for reusing it. >> I do not think that is possible as of now. I think what we have is that, for >> each sample, we create and add new config elements. >> Automation folks, please chime in. >> >> Thanks, >> Samisa... >> >> Samisa Abeysinghe >> VP Engineering >> WSO2 Inc. >> http://wso2.com >> http://wso2.org >> >> >> >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >> > _______________________________________________ > Carbon-dev mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > -- Ruwan Linton Software Architect& Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.com Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: [email protected]; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton tweet: http://twitter.com/ruwanlinton _______________________________________________ Carbon-dev mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
