On Tue, Aug 17, 2010 at 11:12 AM, Samisa Abeysinghe <[email protected]> wrote: > 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.
Yes we can directly use Registry resource versioning. But since we have a file based configuration we need to have versioning there as well. Thanks, Supun.. > > 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 > _______________________________________________ Carbon-dev mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
