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.
>>
>
>

Reply via email to