On Tuesday, August 17, 2010, Supun Kamburugamuva <[email protected]> wrote: > We can extend this concept to have versioning for Synapse > Configurations as well. This is a basic user requirement.
+1 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. I hope this solution will be registry based as well. Samisa... > > 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 > _______________________________________________ Carbon-dev mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
