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.
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
