Hi Ruwen, > > In pre-production or production this is rather the opposite of what you > > want. There changes shall be bundled (some kind of change package) and > > applied at a certain point in time. Each change should be versioned and > > part of a history. It than should be possible to revert (fall back) to > > any former version. What do you think of the following idea: > > > > If an administrator logs in to the administration console, everything is > > read-only by default. If he would like to change any option, he had to > > open a new change package. He can then change as many options as he > > like. Every change will be part of the opened change package, but not > > applied to any running instance of the esb. If the administrator decides > > to activate a change package, a new configuration version will be > > created and all changes will be applied. In some kind of history view > > the admin could change to any of the former version and activate that. > > > > What do others think about this suggestion? > > > Even though we have an indirect method of handling this using svn, I > think it is nice to implement your idea integrated to the WSO2 ESB > console. We had this discussion earlier and drifted from that with the > other work load. I think now we are in a better position to implement > this. While utilizing a web console in this way could be a big gain for some users, others will always prefer automated shell solutions. This will always be the same fight. :-) By the way personally I see svn or cvs just as one option how to implement the versioning backend. The best solution would be to encapsulate the versioning backend with some kind of API and let the end user decide/configure where to store the configuration. Valid options might include any hibernate supported relational database (maybe the integrated derby database by default), or svn/cvs repositories. I wouldn't consider svn as a bad solution. This could also be part of an automated process. Sometimes versioning of configuration could also help in testing/development environments to hunt some bugs or narrow down some problems related to certain configurations.
Regards, Eric _______________________________________________ Esb-java-user mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
