I created a task and will implement wjm's suggestion.
https://issues.apache.org/jira/browse/SCB-671 ------------------ ???????? ------------------ ??????: "Zen Lin"<zenlintechnofr...@gmail.com>; ????????: 2018??6??14??(??????) ????9:27 ??????: "dev"<dev@servicecomb.apache.org>; ????: Re: [DISCUSSION] How to migrate configurations from cse toservicecomb prefix If we consider a smooth transition for customers of the commercial version of ServiceComb, then we can consider compatibility of keep both of prefix cse and prefix servicecomb within a certain period?? and also provide a convention tool. Best Regards, --- Zen Lin zenlintechnofr...@gmail.com Focused on Micro Service and Apache ServiceComb 2018-06-14 8:50 GMT+08:00 Zen Lin <zenlintechnofr...@gmail.com>: > +1 to wjm's suggestion. > I think keep two prefix in ServiceComb will confuse the users. > Anyway, CSE is just a one of the business implement from a business > company, it has nothing to do with ServiceComb in a way. > If we reserve the old prefix now, and we also have to change it in near > future to keep ServiceComb is ServiceComb. > > Providing a conversion tool is a good idea which allow users easily adapt > to the new release. > Tool will be loosely coupled with the ServiecComb but Module will be part > of the core of the ServiceComb, I suggest we avoiding to keep anything > about cse in ServiceComb core. > > If providing a configuration changing module that is based on the > consideration of different configuration centers in future, I think it > would be feasible, but not based on the consideration of how to deal with > cse prefix in ServiceComb. > > Also, The idea of print error messages is good also, but this is another > topic, something like "how to make logs friendly and usable". > > > Best Regards, > --- > Zen Lin > zenlintechnofr...@gmail.com > Focused on Micro Service and Apache ServiceComb > > 2018-06-13 16:04 GMT+08:00 Yang Bo <oaky...@gmail.com>: > >> +1 for wjm's idea. >> The ultimate goal is to use servicecomb.* everywhere in code and >> configurations. >> We can provide a compatible layer to read the cse.* configurations and >> merge them into servicecomb.* and use serviccomb.* elsewhere in the code. >> >> Perhaps we can also provide a tool to transform all configuration files >> from cse.* to servicecomb.* to help user migrate, this should be quite >> simple. >> >> On Wed, Jun 13, 2018 at 2:57 PM Willem Jiang <willem.ji...@gmail.com> >> wrote: >> >> > Hi?? >> > >> > I think we can borrow some idea from Spring Boot. >> > There are some configuration change between Spring Boot 2 and Spring >> Boot >> > 1. >> > Spring Boot provides configuration change module to the mapping thing, >> or >> > print error message for the changed properties. >> > >> > Any thought? >> > >> > >> > Willem Jiang >> > >> > Twitter: willemjiang >> > Weibo: ????willem >> > >> > On Wed, Jun 13, 2018 at 11:08 AM, bismy <bi...@qq.com> wrote: >> > >> > > Hi, >> > > >> > > >> > > Currently we duplicate configurations for servicecomb prefix to cse >> > > prefix, and in code we can read configurations by cse prefix. That is: >> > > 1. Config file using servicecomb.x.y, can read in code with >> > > getProperty("servicecomb.x.y") and getProperty("cse.x.y") >> > > 2. Config file using cse.x.y, can read in code with >> > getProperty("cse.x.y") >> > > >> > > >> > > If we use cse prefix in code, this is the most portable way to read >> both >> > > cse.x.y and servicecomb.x.y configurations. >> > > >> > > >> > > However, this will leading us to write code always using cse, this is >> not >> > > our intention. We are asking users/developers to using servicecomb >> > > gradually. >> > > >> > > >> > > I suggest we use servicecomb prefix when adding new configuration >> items. >> > > But there maybe some axtra work users need to do. For example, >> > > >> > > >> > > One user's project using cse prefix: >> > > >> > > >> > > cse: >> > > function: >> > > a: false >> > > b: false >> > > >> > > >> > > And when we add a new configuration item: servicecomb.funciton.c, >> users >> > > must change the configuration file to one of the following: >> > > >> > > >> > > servicecomb: >> > > function: >> > > a: false >> > > b: false >> > > c: false >> > > >> > > >> > > >> > > >> > > or >> > > cse: >> > > function: >> > > a: false >> > > b: false >> > > >> > > servicecomb: >> > > function: >> > > c: false >> > > >> > > >> > > >> > > >> > > >> > > I think we need to encourage users using servicecomb when upgrading, >> and >> > > developers to use servicecomb prefix when adding new configuration >> > items. >> > > >> > > >> > > Any idea? >> > >> >> >> -- >> Best Regards, >> Yang. >> > >