You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicecomb.apache.org by bismy <bi...@qq.com> on 2019/01/26 01:21:25 UTC

回复: [discuss] enhance boot log

I have an another suggestion to handle changes(generally suggestions to handle API changes for SDK):


    we check the deprecated usage and print error and exit the boot up process, log the suggestions to the user.  For example, we change servicecomb.foo to servicecomb.bar,  if users configure servicecomb.foo, we quit the bootup process, and suggest users to use servicebomb.bar. 


This suggestion can make users integration is always the recommended way and both SDK providers and users will benefit from the cooperation. However sometimes users will get quite angry about changes when they integrated new versions in a hurry and no integrations test for them to check the correctness. 


How about this suggestion? 




------------------ 原始邮件 ------------------
发件人: "Yang Bo"<oa...@gmail.com>;
发送时间: 2019年1月25日(星期五) 下午5:35
收件人: "dev"<de...@servicecomb.apache.org>;

主题: Re: [discuss] enhance boot log



+1 for collecting the important logs(warnings/errors) into a separate
place.
Perhaps we can also write this collected information both to the console
and to a designated log file.

The boot logs are so long that's almost impossible for someone to get the
meaningful information from them.

On Fri, Jan 25, 2019 at 5:02 PM Willem Jiang <wi...@gmail.com> wrote:

> Maybe we can add some lines in the release note to let the user know
> these warning messages are quit important when upgrading the
> java-chassis version.
> It's always good to write some upgrade documents to fill the information
> gap.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Jan 25, 2019 at 4:57 PM wjm wjm <zz...@gmail.com> wrote:
> >
> > sometimes, it just a warning, not fatal
> >
> > Willem Jiang <wi...@gmail.com> 于2019年1月25日周五 下午4:53写道:
> >
> > > If you want user to take a good look of the warning log, you can just
> > > abort the boot process by default.
> > > Just my 2 cents.
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Fri, Jan 25, 2019 at 4:43 PM wjm wjm <zz...@gmail.com> wrote:
> > > >
> > > > currently, when we find something not so good during boot, we will
> print
> > > > log immediately
> > > > eg:
> > > >
> > > >    - use deprecated configuration
> > > >    - port listen failed
> > > >    - ......
> > > >
> > > > most developers will not notice these important messages
> > > >
> > > > so maybe we can keep current implementation
> > > > and collect all the information, print them after boot
> > > > maybe like:
> > > > *************** important message ***************
> > > > warning:
> > > >   1.servicecomb.rest.client.thread-count is ambiguous, suggest to use
> > > > servicecomb.rest.client.verticle-count.
> > > > error:
> > > >   1.......
> > >
>


-- 
Best Regards,
Yang.

Re: [discuss] enhance boot log

Posted by yhs0092 <yh...@163.com>.
+1
It's necessary to inform users of their outdated usage.


Yours sincerely


Yao Haishi
yhs0092@163.com


On 1/26/2019 09:26,Willem Jiang<wi...@gmail.com> wrote:
+1, we can add the option for the user to keep the system booting,
just like the spring-boot's new option of
"spring.main.allow-bean-definition-overriding: true"
In this way,  we can let user know the configuration changes and the
user has the right to decide to change the configuration or not to.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sat, Jan 26, 2019 at 9:21 AM bismy <bi...@qq.com> wrote:

I have an another suggestion to handle changes(generally suggestions to handle API changes for SDK):


we check the deprecated usage and print error and exit the boot up process, log the suggestions to the user.  For example, we change servicecomb.foo to servicecomb.bar,  if users configure servicecomb.foo, we quit the bootup process, and suggest users to use servicebomb.bar.


This suggestion can make users integration is always the recommended way and both SDK providers and users will benefit from the cooperation. However sometimes users will get quite angry about changes when they integrated new versions in a hurry and no integrations test for them to check the correctness.


How about this suggestion?




------------------ 原始邮件 ------------------
发件人: "Yang Bo"<oa...@gmail.com>;
发送时间: 2019年1月25日(星期五) 下午5:35
收件人: "dev"<de...@servicecomb.apache.org>;

主题: Re: [discuss] enhance boot log



+1 for collecting the important logs(warnings/errors) into a separate
place.
Perhaps we can also write this collected information both to the console
and to a designated log file.

The boot logs are so long that's almost impossible for someone to get the
meaningful information from them.

On Fri, Jan 25, 2019 at 5:02 PM Willem Jiang <wi...@gmail.com> wrote:

Maybe we can add some lines in the release note to let the user know
these warning messages are quit important when upgrading the
java-chassis version.
It's always good to write some upgrade documents to fill the information
gap.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Jan 25, 2019 at 4:57 PM wjm wjm <zz...@gmail.com> wrote:

sometimes, it just a warning, not fatal

Willem Jiang <wi...@gmail.com> 于2019年1月25日周五 下午4:53写道:

If you want user to take a good look of the warning log, you can just
abort the boot process by default.
Just my 2 cents.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Jan 25, 2019 at 4:43 PM wjm wjm <zz...@gmail.com> wrote:

currently, when we find something not so good during boot, we will
print
log immediately
eg:

- use deprecated configuration
- port listen failed
- ......

most developers will not notice these important messages

so maybe we can keep current implementation
and collect all the information, print them after boot
maybe like:
*************** important message ***************
warning:
1.servicecomb.rest.client.thread-count is ambiguous, suggest to use
servicecomb.rest.client.verticle-count.
error:
1.......




--
Best Regards,
Yang.

Re: [discuss] enhance boot log

Posted by Willem Jiang <wi...@gmail.com>.
+1, we can add the option for the user to keep the system booting,
just like the spring-boot's new option of
"spring.main.allow-bean-definition-overriding: true"
In this way,  we can let user know the configuration changes and the
user has the right to decide to change the configuration or not to.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sat, Jan 26, 2019 at 9:21 AM bismy <bi...@qq.com> wrote:
>
> I have an another suggestion to handle changes(generally suggestions to handle API changes for SDK):
>
>
>     we check the deprecated usage and print error and exit the boot up process, log the suggestions to the user.  For example, we change servicecomb.foo to servicecomb.bar,  if users configure servicecomb.foo, we quit the bootup process, and suggest users to use servicebomb.bar.
>
>
> This suggestion can make users integration is always the recommended way and both SDK providers and users will benefit from the cooperation. However sometimes users will get quite angry about changes when they integrated new versions in a hurry and no integrations test for them to check the correctness.
>
>
> How about this suggestion?
>
>
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "Yang Bo"<oa...@gmail.com>;
> 发送时间: 2019年1月25日(星期五) 下午5:35
> 收件人: "dev"<de...@servicecomb.apache.org>;
>
> 主题: Re: [discuss] enhance boot log
>
>
>
> +1 for collecting the important logs(warnings/errors) into a separate
> place.
> Perhaps we can also write this collected information both to the console
> and to a designated log file.
>
> The boot logs are so long that's almost impossible for someone to get the
> meaningful information from them.
>
> On Fri, Jan 25, 2019 at 5:02 PM Willem Jiang <wi...@gmail.com> wrote:
>
> > Maybe we can add some lines in the release note to let the user know
> > these warning messages are quit important when upgrading the
> > java-chassis version.
> > It's always good to write some upgrade documents to fill the information
> > gap.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Fri, Jan 25, 2019 at 4:57 PM wjm wjm <zz...@gmail.com> wrote:
> > >
> > > sometimes, it just a warning, not fatal
> > >
> > > Willem Jiang <wi...@gmail.com> 于2019年1月25日周五 下午4:53写道:
> > >
> > > > If you want user to take a good look of the warning log, you can just
> > > > abort the boot process by default.
> > > > Just my 2 cents.
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > > >
> > > > On Fri, Jan 25, 2019 at 4:43 PM wjm wjm <zz...@gmail.com> wrote:
> > > > >
> > > > > currently, when we find something not so good during boot, we will
> > print
> > > > > log immediately
> > > > > eg:
> > > > >
> > > > >    - use deprecated configuration
> > > > >    - port listen failed
> > > > >    - ......
> > > > >
> > > > > most developers will not notice these important messages
> > > > >
> > > > > so maybe we can keep current implementation
> > > > > and collect all the information, print them after boot
> > > > > maybe like:
> > > > > *************** important message ***************
> > > > > warning:
> > > > >   1.servicecomb.rest.client.thread-count is ambiguous, suggest to use
> > > > > servicecomb.rest.client.verticle-count.
> > > > > error:
> > > > >   1.......
> > > >
> >
>
>
> --
> Best Regards,
> Yang.