servicecomb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <willem.ji...@gmail.com>
Subject Re: [DISCUSSION] How to migrate configurations from cse to servicecomb prefix
Date Wed, 13 Jun 2018 06:57:52 GMT
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 <bismy@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?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message