On Tue, Aug 17, 2010 at 11:06 AM, Supun Kamburugamuva <[email protected]>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. > +1 Good idea! Thanks, Hiranya > > 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 > -- Hiranya Jayathilaka Senior Software Engineer; WSO2 Inc.; http://wso2.org E-mail: [email protected]; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com
_______________________________________________ Carbon-dev mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
