we copy servicecomb.* to cse.*, read some configuration items by cse.*,
and read others by servicecomb.*
i think, it's not a good idea.
if we copy cse.* to servicecomb.*, then we can do:
1.read all configuration items by servicecomb.*
2.compatible to old versions
2018-06-13 11:08 GMT+08:00 bismy <bi...@qq.com>:
> 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?
