Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.3.0

[wjm wjm]

+1 (binding)

zzz...@gmail.com  于2021年6月24日周四 上午9:08写道：

> +1 (binding)
>
> ---Original---
> *From:* "bismy"
> *Date:* Tue, Jun 22, 2021 20:43 PM
> *To:* "dev";
> *Subject:* [VOTE] Release Apache ServiceComb Java-Chassis version 2.3.0
>
> Hello All,
>
>
> This is a call for a Vote to release Apache ServiceComb Java-Chassis version 
> 2.3.0
>
> Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12349940
>
> Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.3.0/
>
> Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1464/
>
> Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/2.3.0
>
> Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
>
>
> Voting will start now ( Tuesday, 22 Jun, 2021) and will remain openfor 
> at-least 72 hours, Request all PMC members to give their vote.
>
> [ ] +1 Release this package as 2.3.0
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> On the behalf of ServiceComb Team
>
> Liu Bao
>

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.2.0

[wjm wjm]

+1 binding

bismy  于2021年2月26日周五 上午10:20写道：

> Hello All,
>
> This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 2.2.0
>
> Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12349527
>
> Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.2.0/
>
> Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1457
>
> Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/2.2.0
>
> Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
>
> Voting will start now ( Tuesday, 19 Jan, 2021) and will remain openfor
> at-least 72 hours, Request all PMC members to give their vote.
>
> [ ] +1 Release this package as 2.2.0
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> On the behalf of ServiceComb Team
>
> Liu Bao

Re: [DISCUSSSION]about servicecomb java chassis release plan

[wjm wjm]

+1

bismy  于2021年2月9日周二 下午5:48写道：

> Hi all,
>
>
> In order to meet customers requirements of continuous intergration, I am
> going to change the schedule of java chassis release plan. As
>
>
> 1. release minor versions without vote and no RN is provided. e.g. I will
> release 2.1.6, 2.1.7, etc at any possible time without the vote process,
> and no RN is provided. I only add a tag in github.
> 2. release major versions in about 2~3 months, and the process is the same
> as we did before. e.g. I will release 2.2.0 according to the release
> schedule in JIRA, and vote before release this version.
>  And I will add release notes from 2.1.5 to 2.2.0.
>
>
> Please feedback if you got any questions.

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.1.5

[wjm wjm]

+1 (binding)

bismy  于2021年1月20日周三 下午2:41写道：

> This is my +1
>
>
>
>
> --原始邮件--
> 发件人:
>   "dev"
> <
> willem.ji...@gmail.com;
> 发送时间:2021年1月19日(星期二) 下午5:36
> 收件人:"dev"
> 主题:Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.1.5
>
>
>
> +1 （binding）
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Tue, Jan 19, 2021 at 10:23 AM bismy  
>  Hello All,
> 
>  This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 2.1.5
> 
>  Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626version=12349435
> 
> 
> ;
>  Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.1.5/
> 
> 
> ;
>  Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1452
> 
> 
> ;
>  Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/2.1.5
> 
> 
> ;
>  Release CommitID : ad3bd675d2f305335cb4b4d65866205a5380eb43
> 
>  Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
>  ;
>  Voting will start now ( Tuesday, 19 Jan, 2021) and will remain
> openfor at-least 72 hours, Request all PMC members to give their vote.
> 
>  [ ] +1 Release this package as 2.1.5
>  [ ] +0 No Opinion
>  [ ] -1 Do not release this package because
> 
>  On the behalf of ServiceComb Team
> 
>  Liu Bao

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.3.2

[wjm wjm]

+1 (Binding)

checked: mvn clean install -Pit

Willem Jiang  于2020年12月29日周二 下午3:40写道：

> +1. （Binding）
> I checked the release note， git tag， source kit.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Dec 28, 2020 at 5:43 PM bismy  wrote:
> >
> > Hello All,
> >
> > This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 1.3.2
> >
> > Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12349314
> >
> > Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.3.2/
> >
> > Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1451
> >
> > Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/1.3.2
> >
> > Release CommitID :  cef9dedbd7a84a9845458c5c372c01021e821750
> >
> > Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> >
> > Voting will start now ( Monday, 28 Dec, 2020) and will remain openfor
> at-least 72 hours, Request all PMC members to give their vote.
> >
> > [ ] +1 Release this package as 1.3.2
> > [ ] +0 No Opinion
> > [ ] -1 Do not release this package because
> >
> > On the behalf of ServiceComb Team
> >
> > Liu Bao
>

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.1.3

[wjm wjm]

+1 (binding)

* maven clean install -Pit
* verified by a business framework based on 2.1.3

Willem Jiang  于2020年11月27日周五 下午10:59写道：

> +1 (binding)
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Nov 27, 2020 at 5:10 PM bismy  wrote:
> >
> > Hello All,
> >
> > This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 2.1.3
> >
> > Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12349313
> >
> > Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.1.3/
> >
> > Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1450
> >
> > Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/2.1.3
> >
> > Release CommitID :  b7a9cb4bc86d770a9c4c304071324384e5081408
> >
> > Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> >
> > Voting will start now ( Wednesday, 27 Nov, 2020) and will remain openfor
> at-least 72 hours, Request all PMC members to give their vote.
> >
> > [ ] +1 Release this package as 2.1.3
> > [ ] +0 No Opinion
> > [ ] -1 Do not release this package because
> >
> > On the behalf of ServiceComb Team
> >
> > Liu Bao
>

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.3.1

[wjm wjm]

+1

checked mvn clean install -Pit

bismy  于2020年10月28日周三 下午3:17写道：

> Hello All,
>
> This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 1.3.1
>
> Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12346561
>
> Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.3.1/
>
> Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1448
>
> Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/1.3.1
>
> Release CommitID :  e370e6455a21ab4edfc5a15a84057d65a5c82722
>
> Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
>
> Voting will start now ( Wednesday, 28 Oct, 2020) and will remain openfor
> at-least 72 hours, Request all PMC members to give their vote.
>
> [ ] +1 Release this package as 1.3.1
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> On the behalf of ServiceComb Team
>
> Liu Bao

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.1.2

[wjm wjm]

+1

checked mvn clean install -Pit

bismy  于2020年10月28日周三 上午9:30写道：

> Hello All,
>
> This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 2.1.2
>
> Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626version=12348680
>
> Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.1.2/
>
> Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1447
>
> Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/2.1.2
>
> Release CommitID :ae8c6e4e7b2a499e738cd7c2d5e696d6540652d8
>
> Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
>
> Voting will start now ( Wednesday, 28 Oct, 2020) and will remain openfor
> at-least 72 hours, Request all PMC members to give their vote.
>
> [ ] +1 Release this package as 2.1.2
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> On the behalf of ServiceComb Team
>
> Liu Bao

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.1.1

[wjm wjm]

+1

checked mvn clean install -Pit

yhs0092  于2020年8月12日周三 上午11:55写道：

> +1
> I have checked,
> local build is OK,
>
> tag and commitId is OK.
>
>
>
>
>
> Yours sincerely
>
>
> Yao Haishi
> yhs0...@163.com
>
>
> At 2020-08-12 11:09:50, "bismy"  wrote:
> >Hello All,
> >
> >This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 2.1.1
> >
> >Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626version=12348418
> >
> >Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.1.1/
> >
> >Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1446/
> >
> >Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/2.1.1
> >
> >Release CommitID : e84f4c8c1b94c48656727e084043a4ad58d91633
> >
> >Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> >
> >Voting will start now ( Monday, 12 Aug, 2020) and will remain openfor
> at-least 72 hours, Request all PMC members to give their vote.
> >
> >[ ] +1 Release this package as 2.1.1
> >[ ] +0 No Opinion
> >[ ] -1 Do not release this package because
> >
> >On the behalf of ServiceComb Team
> >
> >Liu Bao
>

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.1.1

[wjm wjm]

+1

checked mvn clean install -Pit

bismy  于2020年8月12日周三 上午10:51写道：

> Hello All,
>
> This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 2.1.1
>
> Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626version=12348418
>
> Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.1.1/
>
> Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1446/
>
> Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/2.1.1
>
> Release CommitID :e84f4c8c1b94c48656727e084043a4ad58d91633
>
> Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
>
> Voting will start now ( Monday, 23 March, 2020) and will remain openfor
> at-least 72 hours, Request all PMC members to give their vote.
>
> [ ] +1 Release this package as 2.0.2
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> On the behalf of ServiceComb Team
>
> Liu Bao

Re: Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.1.0

[wjm wjm]

+1 Binding.

Build from source OK.
Rat check OK.

yhs0092  于2020年6月30日周二 下午2:09写道：

> +1 binding
>
>
> I have checked,
> 1. Release commit id and Tag are good.
> 2. mvn clean install -Pit build is good.
> 3. source code of Release Candidate is consistent with GitHub code repo.
>
>
> Yours sincerely
>
>
> Yao Haishi
> yhs0...@163.com
>
> At 2020-06-29 11:11:18, "Yang Bo"  wrote:
> >+1 Binding.
> >
> >Build from source OK.
> >Rat check OK.
> >
> >Minor issue:
> >The github release assets' file name contains version numbers only. Better
> >to be consistent with the apache dist repo.
> >https://github.com/apache/servicecomb-java-chassis/archive/2.1.0.zip
> >
> >On Sun, Jun 28, 2020 at 8:10 PM bismy  wrote:
> >
> >> Hello All,
> >>
> >> This is a call for a Vote to release Apache ServiceComb Java-Chassis
> >> version 2.1.0
> >>
> >> Release Notes :
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626version=12348247
> >>
> >> Release Candidate :
> >>
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.1.0/
> >>
> >> Staging Repo :
> >>
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1445/
> >>
> >> Release Tag :
> >> https://github.com/apache/servicecomb-java-chassis/releases/tag/2.1.0
> >>
> >> Release CommitID :ccd5bf989bcaf8838a58712f5c41357149d2b0c0
> >>
> >> Keys to verify the Release Candidate :
> >> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> >>
> >> Voting will start now ( Monday, 23 March, 2020) and will remain openfor
> >> at-least 72 hours, Request all PMC members to give their vote.
> >>
> >> [ ] +1 Release this package as 2.0.2
> >> [ ] +0 No Opinion
> >> [ ] -1 Do not release this package because
> >>
> >> On the behalf of ServiceComb Team
> >>
> >> Liu Bao
> >
> >
> >
> >--
> >Best Regards,
> >Yang.
>

Re: [disscuss][java-chassis] provide new mechanism: Filter, which can replace old extensions

[wjm wjm]

another way is not conside compatible
old project use old extensions, but we mark old extensions deprecated, and
delete them after months
new project use new filter extension

wjm wjm  于2020年5月26日周二 上午9:39写道：

> in compatible mode, default filter chain is:
>
> servicecomb:
>   filter-chains:
> enabled: true
> producer:
>   rest:
> default: schedule, http-server-filters, handlers
>
>
> in this chains:
> 1. http-server-filters wrap all old http server filters, their execute
> logic same to old version
> 2. handlers wrap old handler chain, their execute logic same to old version
>
>
> Willem Jiang  于2020年5月26日周二 上午8:06写道：
>
>> It looks like the handlers are assembled in the filter chain in the
>> WrapHandlersToFilter class.
>> How can we setup the order between the filter and handler?
>>
>> Willem Jiang
>>
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>>
>> On Mon, May 25, 2020 at 3:37 PM wjm wjm  wrote:
>> >
>> > thanks for the reply,
>> >
>> > for your question, the wrapper maybe like:
>> >
>> > class WrapHandlersToFilter implements Filter{
>> >   private List handlers;
>> >
>> >   public CompletableFuture onFilter(Invocation invocation,
>> > FilterNode nextNode) {
>> > process all handler
>> >   }
>> > }
>> >
>> >
>> >
>> > the priority of filters, is their order in the configuration.
>> >
>> > and i update the configuration description, make it simpler.
>> >
>> > Willem Jiang  于2020年5月23日周六 上午10:04写道：
>> >
>> > > Hi wjm,
>> > >
>> > > It's great that we can keep polishing the ServiceComb Java-Chassis.
>> > > I just add a comment by asking some question about this new feature
>> on the
>> > > JIRA.
>> > >
>> > > Willem Jiang
>> > >
>> > > Twitter: willemjiang
>> > > Weibo: 姜宁willem
>> > >
>> > > On Fri, May 22, 2020 at 5:32 PM wjm wjm  wrote:
>> > > >
>> > > > please read content in:
>> https://issues.apache.org/jira/browse/SCB-1929#
>> > >
>>
>

Re: [disscuss][java-chassis] provide new mechanism: Filter, which can replace old extensions

[wjm wjm]

in compatible mode, default filter chain is:

servicecomb:
  filter-chains:
enabled: true
producer:
  rest:
default: schedule, http-server-filters, handlers


in this chains:
1. http-server-filters wrap all old http server filters, their execute
logic same to old version
2. handlers wrap old handler chain, their execute logic same to old version


Willem Jiang  于2020年5月26日周二 上午8:06写道：

> It looks like the handlers are assembled in the filter chain in the
> WrapHandlersToFilter class.
> How can we setup the order between the filter and handler?
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, May 25, 2020 at 3:37 PM wjm wjm  wrote:
> >
> > thanks for the reply,
> >
> > for your question, the wrapper maybe like:
> >
> > class WrapHandlersToFilter implements Filter{
> >   private List handlers;
> >
> >   public CompletableFuture onFilter(Invocation invocation,
> > FilterNode nextNode) {
> > process all handler
> >   }
> > }
> >
> >
> >
> > the priority of filters, is their order in the configuration.
> >
> > and i update the configuration description, make it simpler.
> >
> > Willem Jiang  于2020年5月23日周六 上午10:04写道：
> >
> > > Hi wjm,
> > >
> > > It's great that we can keep polishing the ServiceComb Java-Chassis.
> > > I just add a comment by asking some question about this new feature on
> the
> > > JIRA.
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Fri, May 22, 2020 at 5:32 PM wjm wjm  wrote:
> > > >
> > > > please read content in:
> https://issues.apache.org/jira/browse/SCB-1929#
> > >
>

Re: [disscuss][java-chassis] provide new mechanism: Filter, which can replace old extensions

[wjm wjm]

thanks for the reply,

for your question, the wrapper maybe like:

class WrapHandlersToFilter implements Filter{
  private List handlers;

  public CompletableFuture onFilter(Invocation invocation,
FilterNode nextNode) {
process all handler
  }
}



the priority of filters, is their order in the configuration.

and i update the configuration description, make it simpler.

Willem Jiang  于2020年5月23日周六 上午10:04写道：

> Hi wjm,
>
> It's great that we can keep polishing the ServiceComb Java-Chassis.
> I just add a comment by asking some question about this new feature on the
> JIRA.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, May 22, 2020 at 5:32 PM wjm wjm  wrote:
> >
> > please read content in:  https://issues.apache.org/jira/browse/SCB-1929#
>

[disscuss][java-chassis] provide new mechanism: Filter, which can replace old extensions

[wjm wjm]

please read content in:  https://issues.apache.org/jira/browse/SCB-1929#

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.0.1

[wjm wjm]

+1

RKD <2513931...@qq.com> 于2020年3月23日周一 下午9:09写道：

> +1
>
>
>
>
> --Original--
> From:"bismy" Date:Mon, Mar 23, 2020 07:48 PM
> To:"dev"
> Subject:[VOTE] Release Apache ServiceComb Java-Chassis version 2.0.1
>
>
>
> Hello All,
>
> This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 2.0.1
>
> Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626version=12346986
>
> Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.0.1/rc-1/
>
> Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1426/
>
> Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/2.0.1
>
> Release CommitID : 8b375d55286851b23a89784f8635ec617ea8c2af
>
> Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
>
> Voting will start now ( Monday, 23 March, 2020) and will remain openfor
> at-least 72 hours, Request all PMC members to give their vote.
>
> [ ] +1 Release this package as 2.0.1
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> On the behalf of ServiceComb Team
>
> Liu Bao

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.0.0

[wjm wjm]

+1
- git tag and commit id is OK.
- mvn clean install -Pit build OK.

Willem Jiang  于2020年2月20日周四 上午8:59写道：

> I guess it may relate to the docker maven plugin, it looks the version
> is too old :(.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Feb 19, 2020 at 12:07 PM Daniel Qian 
> wrote:
> >
> > Hi, Bao Liu
> >
> > I checked source code by method mentioned in offitial website link[1].
> > I used both `mvn clean install -Pdocker -Pit ` and `mvn clean install
> > -Pdocker -Pdemo-run-release -Pit`, and
> > `org.apache.servicecomb.metrics.core.TestVertxMetersInitializer` was
> > stucked, here is the stack trace generated by jstack[2]. BTW, the
> > issue is only reproducible on my Mac, not reproducible on a linux
> > machine, so I think it's not an issue.
> >
> > Besides, I checked Staging Repository by cd into demo and run `mvn
> > clean install -Pdocker -Pstaging ` (this method is also mentioned in
> > the official website[4]). Unfortunately, the build failed on `Java
> > Chassis::Demo::POJO::Client`, here is the error log[3]
> >
> > [1]:
> https://servicecomb.apache.org/cn/developers/release-validation-guide/#%E9%AA%8C%E8%AF%81%E6%BA%90%E4%BB%A3%E7%A0%81%E5%8A%9F%E8%83%BD%E6%AD%A3%E7%A1%AE
> > [2]:
> https://gist.github.com/chanjarster/614f349205ffd712b64afd041973b9a7#file-stack-txt
> > [3]:
> https://gist.github.com/chanjarster/614f349205ffd712b64afd041973b9a7#file-demo-log
> > [4]:
> https://servicecomb.apache.org/cn/developers/release-validation-guide/#%E9%AA%8C%E8%AF%81staging-repository%E5%86%85%E7%9A%84%E5%BA%93%E6%AD%A3%E7%A1%AE
> >
> > Bao Liu  于2020年2月18日周二 下午10:24写道：
> > >
> > > BTW, when running in profile -Ddocker, do not miss `mvn clean install
> -Pdocker -Pdemo-run-release -Pit` , -Ddemo-run-release is for integration
> tests in demo folder to execute. Check scripts/travis.sh for details.
> > >
> > > On 2020/02/18 14:21:07, Bao Liu  wrote:
> > > > This is a unit test case and I run both locally and travis CI fine.
> Do you have any details about the stuck?
> > > >
> > > > On 2020/02/18 12:31:27, Daniel Qian  wrote:
> > > > > I got stuck on
> org.apache.servicecomb.metrics.core.TestVertxMetersInitializer
> > > > > when mvn clean install -Pdocker -Pit
> > > > > Did I miss something?
> > > > >
> > > > > yhs0092  于2020年2月18日周二 下午4:19写道：
> > > > > >
> > > > > > +1
> > > > > > Checks done:
> > > > > > - git tag and commit id is OK.
> > > > > > - mvn clean install -Pit build OK.
> > > > > > - basic function checked pass.
> > > > > > - the release candidate of source is OK.
> > > > > >
> > > > > >
> > > > > > Yours sincerely
> > > > > >
> > > > > >
> > > > > > Yao Haishi
> > > > > > yhs0...@163.com
> > > > > >
> > > > > >
> > > > > > On 2/17/2020 16:07，bismy wrote：
> > > > > > Hello All,
> > > > > >
> > > > > > This is a call for a Vote to release Apache ServiceComb
> Java-Chassis version 2.0.0
> > > > > >
> > > > > > Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12345196
> > > > > >
> > > > > > Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.0.0/rc01//
> > > > > >
> > > > > > Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1420
> > > > > >
> > > > > > Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/2.0.0
> > > > > >
> > > > > > Release CommitID : 16ee95b968e0ed8beed26bd9fdecb56376984f7d
> > > > > >
> > > > > > Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> > > > > >
> > > > > > Voting will start now ( Monday, 27 February, 2020) and will
> remain openfor at-least 72 hours, Request all PMC members to give their
> vote.
> > > > > >
> > > > > > [ ] +1 Release this package as 2.0.0
> > > > > > [ ] +0 No Opinion
> > > > > > [ ] -1 Do not release this package because
> > > > > >
> > > > > > On the behalf of ServiceComb Team
> > > > > >
> > > > > > Liu Bao
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Daniel Qian
> > > > > Apache Committer(chanjarster)
> > > > > blog：https://chanjarster.github.io
> > > > > github：https://github.com/chanjarster
> > > > > segmentfault: https://segmentfault.com/u/chanjarster
> > > > >
> > > >
> >
> >
> >
> > --
> > Daniel Qian
> > Apache Committer(chanjarster)
> > blog：https://chanjarster.github.io
> > github：https://github.com/chanjarster
> > segmentfault: https://segmentfault.com/u/chanjarster
>

Re: [DISCUSSION] Set all dependency version as properties in java-chasis-dependencies

[wjm wjm]

+1

Liubao (A)  于2019年8月12日周一 上午9:46写道：

> +1
>
> Thanks
>
> -邮件原件-
> 发件人: LA [mailto:liang951...@qq.com]
> 发送时间: 2019年8月9日 17:23
> 收件人: dev 
> 主题: [DISCUSSION] Set all dependency version as properties in
> java-chasis-dependencies
>
> Hi Team,
>
>
> In java-chasis-dependencies, some dependency versions are set as
> properties while others not. As DM, it is not very clear to show version
> informations and also not convenient for version updating.
> In spring-boot-dependencies and spring-cloud-dependencies, ALL version
> informations are set as properties in  tag which is quite
> graceful.
>
>
> It is a boring job to move all version infos to properties, however, it
> may helpful for further development so I am willing to do that if needed.
>
>
> Ang Li
>

Re: [DISCUSSION] About the static check for the source code of ServiceComb-Java-Chassis

[wjm wjm]

seems not too urgent?

yhs0092  于2019年7月7日周日 下午12:04写道：

> There are 115 problems pointed out by CheckStyle. The problem distribution
> is like below:
> - service-registry: 69
> - spring-boot2-starter-servlet: 9
> - spring-boot2-starter-discovery: 1
> - spring-boot-common: 3
> - spring-boot-starter-registry: 1
> - spring-boot-starter-transport: 1
> - spring-cloud-zuul-zipkin: 3
> - spring-boot-starter-discovery: 1
> - foundation-common: 27
>
>
> The problems are mainly about the name of consts, the constructor of
> utility classes, the length of lines, redundant modifiers and magic numbers.
> Other problems scanned by findbugs is not counted here. To fix these
> problems , there are too many files should be modified. I've created an
> issue[1] to track it and wait the weak type work finished.
>
>
> [1]: https://issues.apache.org/jira/browse/SCB-1354
>
>
> Yours sincerely
>
>
> Yao Haishi
> yhs0...@163.com
>
>
> On 7/7/2019 09:03，Willem Jiang wrote：
> Hi Haishi,
>
> Can you list the potential problems which you find?
> If they are not the blocker issues, I think we can start to fix them
> after the weak type work is finished.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sat, Jul 6, 2019 at 11:46 AM wjm wjm  wrote:
>
> ohoh, lots of source files?  maybe cause very difficult to merge weak type
> branch?
>
> yhs0092  于2019年7月5日周五 下午7:43写道：
>
> Hi, guys. I've run code static checks for the source code of
> ServiceComb-Java-Chassis and find several potential problems.
> I want to raise an issue to fix these problems. The changes may be
> distributed among a lot of source code files and they are all for code
> style and complexity improvement.
> Cause I've never handle such kind of issues, is there any thing I should
> be aware of?
>
>
> Yours sincerely
>
>
> Yao Haishi
> yhs0...@163.com
>
>
>

Re: [DISCUSSION] About the static check for the source code of ServiceComb-Java-Chassis

[wjm wjm]

ohoh, lots of source files?  maybe cause very difficult to merge weak type
branch?

yhs0092  于2019年7月5日周五 下午7:43写道：

> Hi, guys. I've run code static checks for the source code of
> ServiceComb-Java-Chassis and find several potential problems.
> I want to raise an issue to fix these problems. The changes may be
> distributed among a lot of source code files and they are all for code
> style and complexity improvement.
> Cause I've never handle such kind of issues, is there any thing I should
> be aware of?
>
>
> Yours sincerely
>
>
> Yao Haishi
> yhs0...@163.com
>
>

Re: [VOTE]Service mesh proposal

[wjm wjm]

+1

在 2019年6月21日星期五，Zheng Feng  写道：

> +1 binding
>
> Xiaoliang Tian  于2019年6月21日周五 下午4:41写道：
>
> > Hi All,
> >this is a call for vote to bring service mesh called "mesher" into
> > Apache Software Foundation (ASF) as ServiceComb's sub-project.
> >
> >
> > Voting will start now ( Wednesday, 5th June, 2019) and will
> > remain open for at-least 72 hours, Request all PMC members to
> > give their vote.
> > [ ] +1 Accept
> > [ ] +0 No Opinion
> > [ ] -1 Reject because...
> >
>

Re: [ANN] New ServiceComb committer:Tian XiaoLiang (田晓亮)

[wjm wjm]

Welcome ~

Zheng Feng  于2019年6月20日周四 上午9:46写道：

> Welcome to the team !
>
> Willem Jiang  于2019年6月20日周四 上午9:25写道：
>
> > Please join me and the rest of the ServiceComb PMC members in welcoming
> our
> > new ServiceComb committer: Tian Xiaoliang (田晓亮).
> >
> > Tian Xiaoliang has been with Apache ServiceComb for more than one
> > years by reviewing the code of servicecomb-service-center and
> > discussing techniques questions in the mailing list.  Recently he is a
> > very active key developer of the new subproject serivcecomb-kie.
> >
> > Congratulations to Tian Xiaoliang! Welcome!
> >
> > The Apache ServiceComb PMC.
> >
>

Re: Proposal for Holding an Apache ServiceComb Meetup as a Co-located Event in KubeCon & CloudNativeCon Summit China 2019

[wjm wjm]

+1

Liubao (A)  于2019年6月10日周一 上午11:27写道：

> +1. Glad to have this meetup.
>
> -邮件原件-
> 发件人: Willem Jiang [mailto:willem.ji...@gmail.com]
> 发送时间: 2019年6月10日 11:02
> 收件人: dev 
> 主题: Re: Proposal for Holding an Apache ServiceComb Meetup as a Co-located
> Event in KubeCon & CloudNativeCon Summit China 2019
>
> It's good to hold this kind of meetup to let more people to know about
> ServiceComb.
> Here is my +1 for the meetup.
> Please send out the meetup proposal earlier next time, so we can get more
> people from community to know about it.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Jun 10, 2019 at 10:08 AM Zen Lin 
> wrote:
> >
> > This is a Proposal for holding a Co-Located Event in KubeCon &
> > CloudNativeCon Summit China 2019 to help building ServiceComb's
> community.
> >
> > My suggestion is to hold a Meetup named "Apache ServiceComb Meetup
> > Hosted by Huawei", to share technologies and user cases of ServiceComb.
> > Because the time is tight, I have already talked to Huawei to get free
> > resources and sposorship for the meetup.
> >
> > Details of the plan is listed below,
> > - What is the topic focus of the event?
> > Topics are focused on  Apache Way related topics, user-practices
> > /technologies topics of Apache ServiceComb .
> > - Who is organising the event?
> > PMCs of ServiceComb (incubating) are the organizer
> > - When is the event?
> > June 24
> > - How many attendees are expected?
> > 60~100
> > - How much PMC involvement is there already?
> > 3
> > - Which marks are requested?
> > Two marks are requested,
> > 1. Name of "Apache ServiceComb Meetup "
> > 2. "Powered By" Apache logo of Apache ServiceComb
> > - Is this for profit or non-profit? (See "Event Profits And Donations")?
> > non-profit.
> >
> > By the way, I also suggest to have a booth about Apache ServiceComb in
> > KubeCon & CloudNativeCon Summit China 2019.
> >
> > Now, I would like to get suggestions from you guys, If it is agreed ,
> > I am going to create a vote for it.
> >
> >
> > Best Regards,
> > ---
> > Zen Lin
> > zenlintechnofr...@gmail.com
> > Focused on Micro Service and Apache ServiceComb
>

Re: Announce of new ServiceComb PMC member

[wjm wjm]

Congratulations  

Liubao (A)  于2019年6月10日周一 上午11:26写道：

> Congratulations to Yao Haishi.
>
> -邮件原件-
> 发件人: Zhang Lei [mailto:zhang_...@boco.com.cn]
> 发送时间: 2019年6月10日 11:05
> 收件人: dev@servicecomb.apache.org
> 主题: Re: Announce of new ServiceComb PMC member
>
> Congratulations.
>
> Lei Zhang
>
> > 在 2019年6月10日，上午10:53，Willem Jiang  写道：
> >
> > It is very rewarding to see that most of the contributors who became
> > committers continue to stay involved. Therefore, in recognition of
> > their continued contribution,  the Apache ServiceComb PMC invited
> > recently a committer to join the PMC, be even more involved and take a
> > greater responsibility in shaping the future of the ServiceComb
> > project.
> >
> > Please join me to welcome Yao Haishi as new Apache ServiceComb PMC
> > member. Many thanks for your past contributions and we look forward to
> > the same commitment in the future.
> >
> > Willem Jiang
> >
> > On behalf of the ServiceComb PMC
>
>

Re: [VOTE] Toolkit donation proposal

[wjm wjm]

+1

Zen Lin  于2019年6月10日周一 上午9:49写道：

> +1 (binding)
>
> Best Regards,
> ---
> Zen Lin
> zenlintechnofr...@gmail.com
> Focused on Micro Service and Apache ServiceComb
>
>
> Liubao (A)  于2019年6月10日周一 上午9:09写道：
>
> > +1
> >
> > -邮件原件-
> > 发件人: Willem Jiang [mailto:willem.ji...@gmail.com]
> > 发送时间: 2019年6月6日 19:03
> > 收件人: dev 
> > 主题: Re: [VOTE] Toolkit donation proposal
> >
> > My +1 (binding), it's great to see that we bring more tools to help user
> > to build their applications.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Thu, Jun 6, 2019 at 6:57 PM Bin Ma  wrote:
> > >
> > > Hi All,
> > >
> > > This is a call for a Vote to bring Toolkit[1] codebase into the Apache
> > > Software Foundation (ASF) as ServiceComb's sub-project.
> > >
> > > Reference: the mail thread link for the previous discussion[2].
> > >
> > > Voting will start now ( Wednesday, 5th June, 2019) and will remain
> > > open for at-least 72 hours, Request all PMC members to give their
> > > vote.
> > >
> > > [ ] +1 Accept
> > > [ ] +0 No Opinion
> > > [ ] -1 Reject because...
> > >
> > > [1] https://github.com/MabinGo/toolkit
> > > [2]
> > > https://lists.apache.org/thread.html/bba43e0116160dbdc7d1443c995a2b6fd
> > > c72f5e4e91f1e5208afc230@%3Cdev.servicecomb.apache.org%3E#
> > >
> > >
> > > Best Wishes & Regards
> > > ---
> > > Mabin
> >
>

Re: [PROPOSAL]create a new project for servicecomb toolkit

[wjm wjm]

+1

Bin Ma  于2019年5月28日周二 下午7:37写道：

> Thanks for your suggestions, I will get the scenarios you provided and put
> into the roadmap of the toolkit to consider how to implement.
>
>
> Best Wishes & Regards
> ---
> Mabin
>
>
>
> Liubao (A)  于2019年5月28日周二 上午9:52写道：
>
> > Very glad to hear this proposal. I have a draft idea[1] of contract based
> > software engineering based on tools.
> > And a brief idea[2] of managing contract of all microservices by web.
> >
> >
> > [1] https://bbs.huaweicloud.com/blogs/c998f257673711e9bd5a7ca23e93a891
> > [2] https://zhuanlan.zhihu.com/p/64064246
> >
> >
> > -邮件原件-
> > 发件人: Bin Ma [mailto:mabin1...@gmail.com]
> > 发送时间: 2019年5月27日 11:00
> > 收件人: dev@servicecomb.apache.org
> > 主题: [PROPOSAL]create a new project for servicecomb toolkit
> >
> > Hi All,
> >
> > In the process of supporting users to do micro-service transformation, we
> > encountered the following problems:
> > 1. For users who integrate multi-vendor applications, because the
> > development languages, habits, and frameworks of different vendors are
> > different, the entire system data and service standards are inconsistent,
> > users are difficult to integrate, and it is difficult to manage and
> control
> > the final delivery quality.
> > 2. For users who have evolved from legacy systems to microservices
> > architectures, additional learning and understanding of the
> > microservices-related framework details is required before the
> > microservices project can be designed, built, and developed according to
> > the selected microservices framework. For users, Need to be distracted to
> > focus on things outside the business.
> >
> > Based on the above reasons, combined with ServiceComb's service contract
> > management capabilities, we have implemented a contract-based
> microservice
> > development toolkit[1] with the goal of rapidly building microservices
> > projects based on popular microservices frameworks and programming
> models,
> > and supporting the automatic generation of contracts,code and
> documentation
> > to help users reduce micro-service entry costs, focus on business
> > development, and improve legacy system reconfiguration and development
> > efficiency during the microservice transformation phase.
> >
> > The framework and basic function of toolkit has been finished [1]
> >
> > The function of the toolkit is as follows:
> > 1. Code extraction service contract
> > In applications developed based on the SpringMVC/POJO/JAX-RS model,
> > one-click generation of service contract files conforming to the OpenAPI
> > specification.
> > 2. Service Contract Generation Micro Service Engineering Enter a service
> > contract that conforms to the OpenAPI specification, one-click generation
> > of a microservice project with ServiceComb/SpringCloud/Swagger as the
> base
> > microservice framework and SpringMVC/POJO/JAX-RS or SpringBoot as
> > programming model .
> > 3. Service contract and code consistency check Verify that the actual
> > implementation of the application (such as the data and service API) is
> > consistent with the agreed service contract description.
> > 4. Service contract / code generation document Enter a service contract
> > that conforms to the OpenAPI specification, one-click generation of a
> > document in html/word/pdf format.
> >
> > [1] https://github.com/MabinGo/toolkit
> >
> >
> > Best Wishes & Regards
> > ---
> > Mabin
> >
>

Re: [VOTE]create a new project servicecomb-fence

[wjm wjm]

+1

Liubao (A)  于2019年5月20日周一 下午8:28写道：

> Thank you for your kindly reminding. This is a call for a vote.
>
> -邮件原件-
> 发件人: Willem Jiang [mailto:willem.ji...@gmail.com]
> 发送时间: 2019年5月20日 19:24
> 收件人: dev 
> 主题: Re: [PROPOSAL]create a new project servicecomb-fence
>
> @Liubao，
>
> +1 for the proposal.
>
> If it's a vote, please add [VOTE] to the subject.
> We also need to add the mail thread link for the previous discussion[1].
>
> [1]
> https://lists.apache.org/thread.html/ace9961a86ab94c877d4601740d2170b977cda8228c45c79dcba4a97@%3Cdev.servicecomb.apache.org%3E
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
> On Thu, May 16, 2019 at 5:22 PM Liubao (A)  wrote:
> >
> > Hi all,
> >
> > As we discussed before , we will create a new project to provide
> authentication and authorization support for java-chassis, and
> servicecomb-fence is the name.
> >
> > Please feel free to vote or leave any suggestions.
> >
>

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.2.1 (RC-02)

[wjm wjm]

+1 (binding)


Checked basic function of ServiceComb-Java-Chassis

Jean-Baptiste Onofré  于2019年5月15日周三 下午9:46写道：

> +1 (binding)
>
> Regards
> JB
>
> On 13/05/2019 12:16, Mohammad Asif Siddiqui wrote:
> > Hello All,
> >
> > This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 1.2.1 (RC-02)
> >
> > Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12345364
>
> >
> > Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.2.1/rc-02/
>
> >
> > Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1400
>
> >
> > Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/1.2.1
> >
> > Release CommitID : 2701f56f0c1b989ff5ad7416211d9c117fa5337e
> >
> > Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> >
> > Voting will start now ( Monday, 13th May, 2019) and will remain open for
> at-least 72 hours, Request all PMC members to give their vote.
> >
> > [ ] +1 Release this package as 1.2.1
> > [ ] +0 No Opinion
> > [ ] -1 Do not release this package because
> >
> > On the behalf of ServiceComb Team
> > Mohammad Asif Siddiqui
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [PROPOSAL]start a new project to add security support for java-chassis

[wjm wjm]

+1
greate!!!

Liubao (A)  于2019年5月13日周一 下午4:51写道：

> Hi,
>
> I am working on integrating spring security to java-chassis to make
> developing authentication and authorization management easier. Now I have
> finished the framework and basic authorization management.
>
> This work is shown in [1].
>
>
> 1.   User's can create AuthenticationServer to manage users and roles
> and their confidential information.
>
> 2.   User's can add authentication in edge service.
>
> 3.   User's can add authentication and authorization in
> ResouceServer.  This work project two ways to specify authorization,
>
> using microservice.yaml like :
>
>
>
> ```
>
> servicecomb:
>
>   authencation:
>
> access:
>
>   needAuth: true
>
>   roles:
>
> HandlerAuthEndpoint:
>
>   adminSayHello: ADMIN
>
> ```
>
>
>
> or using method security
>
> ```
>
>   @PostMapping(path = "/adminSayHello")
>
>   @PreAuthorize("hasRole('ADMIN')")
>
>   public String adminSayHello(String name) {
>
> return name;
>
>   } ```
>
>
>   This test cases are show in project Client, in
> AuthenticationTestCase.java .
>
> I suggest to create a new project, servicecomb-security(or some other
> name), to hosting common components that can be reused to develop
> authentication and authorization.
>
> Future plans of this project(informal):
>
>
> 1.   Make OAUTH2 as the default implementation.  JWT is the most
> effective authentication mechanism for miscroservices, I think OAUTH2(or
> related Open Connect ID) is the best choice.  (based on spring security
> oauth2)
>
> 2.   Add common framework to connect other OAUTH2 parties. (like
> keycloak[2], or firebase[3])
>
> 3.   Others based on user's feedback.
>
>
> [1]
> https://github.com/apache/servicecomb-samples/tree/master/authentication
> [2] https://www.keycloak.org/docs/latest/securing_apps/index.html
> [3] https://firebase.google.com/docs/auth/
>
>
>
>
>
>

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.2.1

[wjm wjm]

yes, already merged.

Willem Jiang  于2019年5月9日周四 上午1:02写道：

> Please make sure the PR is merged, then we can start cut a new release
> again.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, May 8, 2019 at 9:15 AM wjm wjm  wrote:
> >
> > -1 (binding)
> >
> > @yaohai...@huawei.com 
> > this problem is caused by [SCB-1046] 2018/12/8 in 1.2.0
> > i have merged your PR
> >
> >
> >
> > Jean-Baptiste Onofré  于2019年5月8日周三 下午1:21写道：
> >
> > > +1 (binding)
> > >
> > > Regards
> > > JB
> > >
> > > On 06/05/2019 08:21, Mohammad Asif Siddiqui wrote:
> > > > Hello All,
> > > >
> > > > This is a call for a Vote to release Apache ServiceComb Java-Chassis
> > > > version 1.2.1
> > > >
> > > > Release Notes :
> > > >
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12345364
> > > >
> > > >
> > > > Release Candidate :
> > > >
> > >
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.2.1/rc-01/
> > > >
> > > >
> > > > Staging Repo :
> > > >
> > >
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1398
> > > >
> > > >
> > > > Release Tag :
> > > >
> https://github.com/apache/servicecomb-java-chassis/releases/tag/1.2.1
> > > >
> > > > Release CommitID : f12b685eb2f08524356f84bfacfc3b4f3244cf15
> > > >
> > > > Keys to verify the Release Candidate :
> > > > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> > > >
> > > > Voting will start now ( Monday, 6th May, 2019) and will remain open
> for
> > > > at-least 72 hours, Request all PMC members to give their vote.
> > > >
> > > > [ ] +1 Release this package as 1.2.1
> > > > [ ] +0 No Opinion
> > > > [ ] -1 Do not release this package because
> > > >
> > > > On the behalf of ServiceComb Team
> > > > Mohammad Asif Siddiqui
> > > >
> > >
> > > --
> > > Jean-Baptiste Onofré
> > > jbono...@apache.org
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> > >
>

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.2.1

[wjm wjm]

-1 (binding)

@yaohai...@huawei.com 
this problem is caused by [SCB-1046] 2018/12/8 in 1.2.0
i have merged your PR



Jean-Baptiste Onofré  于2019年5月8日周三 下午1:21写道：

> +1 (binding)
>
> Regards
> JB
>
> On 06/05/2019 08:21, Mohammad Asif Siddiqui wrote:
> > Hello All,
> >
> > This is a call for a Vote to release Apache ServiceComb Java-Chassis
> > version 1.2.1
> >
> > Release Notes :
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12345364
> >
> >
> > Release Candidate :
> >
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.2.1/rc-01/
> >
> >
> > Staging Repo :
> >
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1398
> >
> >
> > Release Tag :
> > https://github.com/apache/servicecomb-java-chassis/releases/tag/1.2.1
> >
> > Release CommitID : f12b685eb2f08524356f84bfacfc3b4f3244cf15
> >
> > Keys to verify the Release Candidate :
> > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> >
> > Voting will start now ( Monday, 6th May, 2019) and will remain open for
> > at-least 72 hours, Request all PMC members to give their vote.
> >
> > [ ] +1 Release this package as 1.2.1
> > [ ] +0 No Opinion
> > [ ] -1 Do not release this package because
> >
> > On the behalf of ServiceComb Team
> > Mohammad Asif Siddiqui
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

[discuss][java-chassis] gpg file in project

[wjm wjm]

i notice that we have gpg file in project:
https://github.com/apache/servicecomb-java-chassis/blob/master/gpg-sec.tar.enc

because we did not use automic release, the gpg file is useless, can we
delete it?

Re: [disscuss][java-chassis] plan to release java-chassis patch 1.2.1?

[wjm wjm]

discussed with @willem.jiang  , because only
"Optional" is new feature, we can  create 1.2.1 branch based on current
master(1.3.0-SNAPSHOT)

Willem Jiang  于2019年4月29日周一 上午9:14写道：

> I think we can start from 1.2.0 to avoid introduce new feature of 1.3.0.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Apr 29, 2019 at 8:37 AM wjm wjm  wrote:
> >
> > create 1.2.1 branch based on current master(1.3.0-SNAPSHOT)
> > or create a new branch based on 1.2.0 and then  cherry pick?
> >
> > Willem Jiang  于2019年4月29日周一 上午8:22写道：
> >
> > > Yeah,  we could release 1.2.1 for these important patches.
> > > As the 1.2.1 is a patch release, my suggestion is we back port the
> > > patches of bug fixing into the 1.2.x branch, and then cut the release
> > > candidate.
> > > @wjm do you mind mark the JIRAs of the bug with the fix version of
> > > 1.2.1, then we could start the cherry pick the patches into 1.2.x
> > > branch.
> > >
> > > Any thought?
> > >
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Sun, Apr 28, 2019 at 11:29 PM wjm wjm  wrote:
> > > >
> > > > there are some important fix for 1.2.0
> > > >
> > > >
> > > >- when create microservice meta failed, will destroy failed meta,
> but
> > > >leak to destroy related configuration resources, rarely happen,
> but
> > > it's a
> > > >leak problem.
> > > >- when log framework is log4j2, will leak some log4j2 marker
> object
> > > for
> > > >every request, serious leak problem
> > > >- default to disable inject x-cse-context from edge invoker, to
> > > >avoid security issue problem
> > > >
> > > >
> > > > other changes:
> > > >
> > > >- support consumer and producer return Optional type
> > > >- inspector swagger online test support work with servlet having
> web
> > > >root and servlet pattern
> > > >- inspector support view configuration items
> > > >- fix inspector swagger to html can not scroll problem
> > > >
> > > > do we plan to release a patch 1.2.1?
> > >
>

[disscuss][java-chassis] plan to release java-chassis patch 1.2.1?

[wjm wjm]

there are some important fix for 1.2.0


   - when create microservice meta failed, will destroy failed meta, but
   leak to destroy related configuration resources, rarely happen, but it's a
   leak problem.
   - when log framework is log4j2, will leak some log4j2 marker object for
   every request, serious leak problem
   - default to disable inject x-cse-context from edge invoker, to
   avoid security issue problem


other changes:

   - support consumer and producer return Optional type
   - inspector swagger online test support work with servlet having web
   root and servlet pattern
   - inspector support view configuration items
   - fix inspector swagger to html can not scroll problem

do we plan to release a patch 1.2.1?

[disscuss][java-chassis] is there any existing sensitive word filter component?

[wjm wjm]

https://github.com/apache/servicecomb-java-chassis/pull/1180

inspector of configuration need to change some value to "**", eg:
password

Re: [DISCUSS] Limit the memory consumption of ServiceComb-Java-Chassis integration tests

[wjm wjm]

+1

yhs0092  于2019年4月12日周五 上午11:09写道：

> Hi, currently our integration tests will run serveral microservice
> instances without limiting their memory consumption. As a result, I have to
> spare quite a large part of memory to ensure the execution of `mvn clean
> install -Pit` does not fail.
> Maybe we can set `-Xmx128m` to limit the heap size.
> Any ideas?
>
>
> Yours sincerely
>
>
> Yao Haishi
> yhs0...@163.com
>
>

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.2.0 (RC-03)

[wjm wjm]

ok
+1 binding

checked "Release Notes" and "Release Tag"

Willem Jiang  于2019年4月9日周二 上午10:15写道：

> Hi wjm,
>
> The 1.2.0 tag is 04c882b[1], it's right. Please don't use the link to
> compare with the master branch.
>
> [1]
> https://github.com/apache/servicecomb-java-chassis/commit/04c882beb1c8a75f15dfe7a0e68e44de158bbc2c
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Apr 8, 2019 at 11:05 PM wjm wjm  wrote:
> >
> > "release tag" still have problem?
> >
> https://github.com/apache/servicecomb-java-chassis/compare/1.2.0...master
> >
> > Mohammad Asif Siddiqui  于2019年4月8日周一 下午6:29写道：
> >
> > > Hello All,
> > >
> > > This is a call for a Vote to release Apache ServiceComb Java-Chassis
> > > version 1.2.0 (RC-03)
> > >
> > > Release Notes :
> > >
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12344561
> > >
> > >
> > > Release Candidate :
> > >
> > >
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.2.0/rc-03/
> > >
> > >
> > > Staging Repo :
> > >
> > >
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1392
> > >
> > >
> > > Release Tag :
> > > https://github.com/apache/servicecomb-java-chassis/releases/tag/1.2.0
> > >
> > > Release CommitID : 04c882beb1c8a75f15dfe7a0e68e44de158bbc2c
> > >
> > > Keys to verify the Release Candidate :
> > > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> > >
> > > Voting will start now ( Monday, 8th April, 2019) and will remain open
> for
> > > at-least 72 hours, Request all PMC members to give their vote.
> > >
> > > [ ] +1 Release this package as 1.2.0
> > > [ ] +0 No Opinion
> > > [ ] -1 Do not release this package because
> > >
> > > On the behalf of ServiceComb Team
> > > Mohammad Asif Siddiqui
> > >
>

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.2.0 (RC-03)

[wjm wjm]

"release tag" still have problem?
https://github.com/apache/servicecomb-java-chassis/compare/1.2.0...master

Mohammad Asif Siddiqui  于2019年4月8日周一 下午6:29写道：

> Hello All,
>
> This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 1.2.0 (RC-03)
>
> Release Notes :
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12344561
>
>
> Release Candidate :
>
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.2.0/rc-03/
>
>
> Staging Repo :
>
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1392
>
>
> Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/1.2.0
>
> Release CommitID : 04c882beb1c8a75f15dfe7a0e68e44de158bbc2c
>
> Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
>
> Voting will start now ( Monday, 8th April, 2019) and will remain open for
> at-least 72 hours, Request all PMC members to give their vote.
>
> [ ] +1 Release this package as 1.2.0
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> On the behalf of ServiceComb Team
> Mohammad Asif Siddiqui
>

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.2.0 (RC-02)

[wjm wjm]

yes, SCB-1240 better to be in 1.2.0.

Willem Jiang  于2019年4月8日周一 上午9:59写道：

> Oh,I'm sorry, it's my fault. I forgot to push the change of SCB-1240 into
> the
> release/1.2.0 branch in the weekend.
>
> Now the change is pushed into release/1.2.0 branch. Do we need to
> consider to recut the release?
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
> On Mon, Apr 8, 2019 at 9:09 AM wjm wjm  wrote:
> >
> > “Release Tag” is not correct?
> >
> > Mohammad Asif Siddiqui  于2019年4月6日周六 下午9:21写道：
> >
> > > Hello All,
> > >
> > > This is a call for a Vote to release Apache ServiceComb Java-Chassis
> > > version 1.2.0 (RC-02)
> > >
> > > Release Notes :
> > >
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12344561
> > >
> > >
> > > Release Candidate :
> > >
> > >
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.2.0/rc-02/
> > >
> > >
> > > Staging Repo :
> > >
> > >
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1385
> > >
> > >
> > > Release Tag :
> > > https://github.com/apache/servicecomb-java-chassis/releases/tag/1.2.0
> > >
> > > Release CommitID : 8b1723e2fcd2beb86ba05be8d32d3f1b64024eb1
> > >
> > > Keys to verify the Release Candidate :
> > > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> > >
> > > Voting will start now ( Saturday, 6th April, 2019) and will remain
> open for
> > > at-least 72 hours, Request all PMC members to give their vote.
> > >
> > > [ ] +1 Release this package as 1.2.0
> > > [ ] +0 No Opinion
> > > [ ] -1 Do not release this package because
> > >
> > > On the behalf of ServiceComb Team
> > > Mohammad Asif Siddiqui
> > >
>

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.2.0 (RC-02)

[wjm wjm]

“Release Tag” is not correct?

Mohammad Asif Siddiqui  于2019年4月6日周六 下午9:21写道：

> Hello All,
>
> This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 1.2.0 (RC-02)
>
> Release Notes :
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12344561
>
>
> Release Candidate :
>
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.2.0/rc-02/
>
>
> Staging Repo :
>
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1385
>
>
> Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/1.2.0
>
> Release CommitID : 8b1723e2fcd2beb86ba05be8d32d3f1b64024eb1
>
> Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
>
> Voting will start now ( Saturday, 6th April, 2019) and will remain open for
> at-least 72 hours, Request all PMC members to give their vote.
>
> [ ] +1 Release this package as 1.2.0
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> On the behalf of ServiceComb Team
> Mohammad Asif Siddiqui
>

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.2.0

[wjm wjm]

already merged.

Willem Jiang  于2019年4月5日周五 下午10:53写道：

> Hi wjm
>
> PR 1168, just added an application id , I think it should be fine to
> be part of java-chassis 1.2.0.
> Please verify it.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Apr 5, 2019 at 9:33 PM wjm wjm  wrote:
> >
> > yes, need some fix.
> >
> > https://github.com/apache/servicecomb-java-chassis/pull/1167already
> > merged.
> > https://github.com/apache/servicecomb-java-chassis/pull/1168 not
> > merged, need review and merge.
> >
> >
> > Willem Jiang  于2019年4月5日周五 下午3:40写道：
> >
> > > Hi Asif
> > >
> > > As the CI is not unstable recently, we need to include the fix of
> > > this PR[1] to fix it.
> > > So I have to vote -1 for this release.
> > >
> > >
> > > [1]https://github.com/apache/servicecomb-java-chassis/pull/1167
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Thu, Apr 4, 2019 at 12:25 AM Mohammad Asif Siddiqui
> > >  wrote:
> > > >
> > > > Hello All,
> > > >
> > > > This is a call for a Vote to release Apache ServiceComb Java-Chassis
> > > > version 1.2.0
> > > >
> > > > Release Notes :
> > > >
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12344561
> > > >
> > > >
> > > > Release Candidate :
> > > >
> > >
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.2.0/rc-01/
> > > >
> > > >
> > > > Staging Repo :
> > > >
> > >
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1382
> > > >
> > > >
> > > > Release Tag :
> > > >
> https://github.com/apache/servicecomb-java-chassis/releases/tag/1.2.0
> > > >
> > > > Release CommitID : 00c1d8e8324c358acdd3084ed5473c7f99270168
> > > >
> > > > Keys to verify the Release Candidate :
> > > > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> > > >
> > > > Voting will start now ( Wednesday, 3rd April, 2019) and will remain
> open
> > > > for at-least 72 hours, Request all PMC members to give their vote.
> > > >
> > > > [ ] +1 Release this package as 1.2.0
> > > > [ ] +0 No Opinion
> > > > [ ] -1 Do not release this package because
> > > >
> > > > On the behalf of ServiceComb Team
> > > > Mohammad Asif Siddiqui
> > >
>

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.2.0

[wjm wjm]

yes, need some fix.

https://github.com/apache/servicecomb-java-chassis/pull/1167already
merged.
https://github.com/apache/servicecomb-java-chassis/pull/1168 not
merged, need review and merge.


Willem Jiang  于2019年4月5日周五 下午3:40写道：

> Hi Asif
>
> As the CI is not unstable recently, we need to include the fix of
> this PR[1] to fix it.
> So I have to vote -1 for this release.
>
>
> [1]https://github.com/apache/servicecomb-java-chassis/pull/1167
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Thu, Apr 4, 2019 at 12:25 AM Mohammad Asif Siddiqui
>  wrote:
> >
> > Hello All,
> >
> > This is a call for a Vote to release Apache ServiceComb Java-Chassis
> > version 1.2.0
> >
> > Release Notes :
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12344561
> >
> >
> > Release Candidate :
> >
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.2.0/rc-01/
> >
> >
> > Staging Repo :
> >
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1382
> >
> >
> > Release Tag :
> > https://github.com/apache/servicecomb-java-chassis/releases/tag/1.2.0
> >
> > Release CommitID : 00c1d8e8324c358acdd3084ed5473c7f99270168
> >
> > Keys to verify the Release Candidate :
> > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> >
> > Voting will start now ( Wednesday, 3rd April, 2019) and will remain open
> > for at-least 72 hours, Request all PMC members to give their vote.
> >
> > [ ] +1 Release this package as 1.2.0
> > [ ] +0 No Opinion
> > [ ] -1 Do not release this package because
> >
> > On the behalf of ServiceComb Team
> > Mohammad Asif Siddiqui
>

Re: [PROPOSAL] ServiceComb MetaConfig

[wjm wjm]

do we have a mechanism to use the configuration with high performance？

Xiaoliang Tian  于2019年3月29日周五 下午5:27写道：

> sure, mainly forcus on management , ease of use, rollback, key value
> version control. value validation.
>
> first we support API, later UX.
>
> bismy  于2019年3月29日周五 下午4:08写道：
>
> > Provide a centered configuration management service is very important for
> > ServiceComb, because all microservice governance functions are based on
> > dynamic properties. In ServiceComb microservice view, now we currently
> use
> > following functions( implement archaius api using apollo and
> config-center)
> >
> >
> >   * pull/push configurations of key-value pair from configuration
> service.
> >
> >
> > in microservice view, no future functions is needed. So I guess the
> > suggested service mainly focus on management functions. How do you decide
> > to provide this functions? Add a management console or by REST api?
> >
> >
> > -- 原始邮件 --
> > 发件人: "Xiaoliang Tian";
> > 发送时间: 2019年3月29日(星期五) 下午2:14
> > 收件人: "dev";
> >
> > 主题: Re: [PROPOSAL] ServiceComb MetaConfig
> >
> >
> >
> > let's think how we change a timeout for a particular operation?
> > the key is xxx.usermanagement.user.getuser.timeout, is that key easy to
> be
> > manged by operator? I guess he has to learn a special key rule only make
> > sense in his team
> >
> > I want this timeout just be timeout, and easy to read
> > it bacame timeout(service= usermanagement  ,
> schema=user,opertion=getuser)
> >
> > Xiaoliang Tian  于2019年3月29日周五 下午12:15写道：
> >
> > >
> > > maybe the name confused，it is a service only for configurations，but the
> > key contains metadata
> > > key1:  log_level(service=cart, version=1.0, app=mall)
> > > key2:  log_level(service=cart, version=1.0, app=mall, ip=x.x.x.x)
> > > that is 2 different keys
> > >
> > > you can consider apollo has fixed metadata and one fixed view to math
> > > their own scenario.
> > >
> > > but in apollo,  key can be very complicated, user can not easily
> observe
> > > keys, a lot of metadata will be attacted to key name, just like ip to
> > > "log_level"
> > >
> > > Willem Jiang  于2019年3月29日周五 上午11:36写道：
> > >
> > >> Hi Xiaoliang,
> > >>
> > >> Do you propose we start a new project to manage the micro services
> meta
> > >> datas?
> > >> Currently we just have a solution to integrate with with Apollo for
> > >> configuration management, but what's the difference between the
> > >> service metadata and configuration?
> > >> I could help us to understand the proposal, if we can drop a clear
> line
> > >> for it.
> > >>
> > >>
> > >> Willem Jiang
> > >>
> > >> Twitter: willemjiang
> > >> Weibo: 姜宁willem
> > >>
> > >> On Fri, Mar 29, 2019 at 10:52 AM Xiaoliang Tian
> > >>  wrote:
> > >> >
> > >> > MetaConfig is  a  service for configuration management in an large
> > >> scaled
> > >> > distrbuted system.
> > >> >
> > >> > Currently we use ctrip appllo for config managment, but it is build
> > for
> > >> a
> > >> > paticular scenario. it has fixed schema
> > >> application,environment,cluster and
> > >> > namespace.  Each key belong to that schema.
> > >> >
> > >> > But it is not enough for operator to manage a complicated
> > >> infrasctructure
> > >> > or application cluster.
> > >> >
> > >> > So here is the proposal to build a brand new config management
> > service,
> > >> >
> > >> > *Features: *
> > >> > *key with rich metadata: *user can define metadata for a key , that
> > >> > distinguish from key to another key.  a key will not be stringed by
> > >> fixed
> > >> > schema.  metadata is like "env=test, service=cart, version=1.0" or
> > >> > "cluster=xxx"  or "env=test, service=cart, version=1.0, ip=x.x.x.x"
> > >> > *validator: *value can be checked by user defined python script, so
> in
> > >> > runtine if someone want to change this value, the script will check
> if
> > >> this
> > >> > value is properate.
> > >> > *encryption webhook: *. value can by ecrypt by your custom
> encryption
> > >> > service.
> > >> > *event producer:  *producer will send key changes event to a target
> > >> > service(kafka,rabbitmq, customed).
> > >> > *config view: *by setting metadata criteria, MetaConfig will
> > aggregate a
> > >> > view to return all key values which match those metadata, so that
> > >> operator
> > >> > can mange key in their own understading to a distributed system in
> > >> > seperated views.
> > >> > *config batch action: * with metadate, you can batch update, delete
> > key
> > >> > values. for example: update all "service=cart version=1.0"
> > configuration
> > >> > log level to "DEBUG" or just update  "service=cart version=1.0,
> > >> ip=x.x.x.x"
> > >> >  .
> > >> > *rich value type: *not ony plain text any more, but support to be
> > aware
> > >> of
> > >> > ini, json,yaml,xml and java properties
> > >> > *heterogenous configuration system: *able to manage configuration in
> > k8s
> > >> > and consul or even more, you can update, delete, and use config 

Re: [DISCUSS] Require the review before merging the PR

[wjm wjm]

+1

zhang_...@boco.com.cn  于2019年4月3日周三 下午3:25写道：

> +1
>
> > 在 2019年4月3日，下午2:55，Zheng Feng  写道：
> >
> > Hi,
> >
> > I just wonder if we can enable this setting [1] on servicecomb-pack [2]
> and
> > it could be helpful when reviewing the PR. I think at least one people
> > review the changes and approve before merging it. We have to raise a JIRA
> > for the infra team to do this setting. So I post this message here to see
> > if the others have any thought.
> >
> > Regards,
> > Zheng Feng
> >
> > [1]
> >
> https://help.github.com/en/articles/enabling-required-reviews-for-pull-requests
> > [2] https://github.com/apache/servicecomb-pack
>
>
> Zhang Lei.
>
>
>
>

Re: Any Ideas for ServiceComb projects for GSOC 2019???

[wjm wjm]

java-chassis:
  we have provide a new module named "inspector" to inspect internal data
of a microservice instance.
  currently we only have one feature in inspector: view/test/download
schemas
https://issues.apache.org/jira/browse/SCB-1188
https://issues.apache.org/jira/secure/attachment/12961872/image-2019-03-11-02-34-39-543.png

  we still need to add viewer of AppManager and DiscoveryTrees.
  that can help others to understand our consumer mechanism

  is this suitable?



Zheng Feng  于2019年4月3日周三 下午10:06写道：

> Hi all,
>
> I had one from the servicecomb-pack [1] which needs to implement the LRA
> spec. I think the student could learn
> 1. cooperate with the open source community. The LRA spec [2] is under the
> microprofile currently.
> 2. strong programming skill.
>
> The other question is we have to be the mentor to work with the student ?
> I'm not sure how much time it could spent on the GSOC project.
>
> Regards,
> Zheng Feng
>
> [1] https://issues.apache.org/jira/browse/SCB-1123
> [2]
>
> https://github.com/eclipse/microprofile-lra/blob/master/spec/src/main/asciidoc/microprofile-lra-spec.adoc
>
> Mohammad Asif Siddiqui  于2019年4月3日周三 下午9:14写道：
>
> > Hello All,
> >
> > As we know that Apache is an approved organization for GSOC 2019 so
> > ServiceComb being an Apache project also has an opportunity to engage in
> > this program.
> >
> > Currently we have not listed any ideas for GSOC 2019 for ServiceComb so
> if
> > someone from Java-Chassis, Service-Center, Saga & Pack has any ideas
> which
> > university students can implement it that would be great to list the
> > ideas.
> >
> > Mostly we will have lot of ideas which can be good for project but
> because
> > of the time constraints we are not able to implement it, so I think it's
> a
> > good time to list those ideas and see if some university student is
> > interested in implementing it so that it will be good for them as well as
> > good for community.
> >
> > We have discuss all the ideas in this mail thread and if everyone agrees
> to
> > some particular ideas then we can raise a Jira for the same.
> >
> > Regards
> > Asif
> >
>

Re: [VOTE] Release Apache ServiceComb Pack version 0.4.0 (RC-02)

[wjm wjm]

+1

checked release notes.

Zheng Feng  于2019年4月2日周二 下午2:13写道：

> +1 Release this package as 0.4.0
>
> I checked
> * The release tag is OK
> * The release candidate can be download and the signature is OK
> * Building and running the tests of the source codes is OK
> * Release notes is OK
>
>
>
> Mohammad Asif Siddiqui  于2019年4月2日周二 上午6:23写道：
>
> > Hi All,
> >
> > This is a call for Vote to release Apache ServiceComb Pack version 0.4.0
> > (RC-02)
> >
> > Release Candidate :
> >
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-pack/0.4.0/rc-02/
> >
> > Staging Repository :
> >
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1380
> >
> > Release Tag :
> > https://github.com/apache/servicecomb-pack/releases/tag/0.4.0
> >
> > Release CommitID : c2b1a6d603b0fb3d658a495da29d6f864995b538
> >
> > Release Notes :
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12344102
> >
> >
> > Keys to verify the Release Candidate :
> > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> >
> > Voting will start now ( Tuesday, 2nd April, 2019) and will remain open
> for
> > at-least 72 hours, Request all PMC members to give their vote.
> >
> > [ ] +1 Release this package as 0.4.0
> > [ ] +0 No Opinion
> > [ ] -1 Do not release this package because
> >
> > On the behalf of ServiceComb Team
> > Mohammad Asif Siddiqui
> >
>

Re: [VOTE] Release Apache ServiceComb Service-Center version 1.2.0

[wjm wjm]

[SCB-1059] - Bug fixes for v1.1.0

there are many fixes, it's better to list detail.

Willem Jiang  于2019年4月2日周二 上午10:17写道：

> +1 (binding)
> I checked the signed key and the license files and run the binary server
> on Mac.
>
> I just found a minor issue about the Notice file, we need to updated the
> year.
> It's not a blocker issue, I will submit a quick fix for it.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Mar 29, 2019 at 3:35 PM Mohammad Asif Siddiqui
>  wrote:
> >
> > Hi All,
> >
> > This is a call for a Vote to release Apache ServiceComb Service-Center
> version 1.2.0
> >
> > Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12344562
> >
> > Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-service-center/1.2.0/rc-01/
> >
> > Release Tag :
> https://github.com/apache/servicecomb-service-center/releases/tag/1.2.0
> >
> > Release CommitID : de7166e156ddb179429e8ac4739562513f95c21d
> >
> > Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> >
> > Guide to build the release from source :
> https://github.com/apache/servicecomb-service-center/tree/master/scripts/release
> >
> > Voting will start now ( Friday, 29th March, 2019) and will remain open
> for at-least 72 hours, Request all PMC members to give their vote.
> >
> > [ ] +1 Release this package as 1.2.0
> > [ ] +0 No Opinion
> > [ ] -1 Do not release this package because
> >
> > On the behalf of ServiceComb Team
> > Mohammad Asif Siddiqui
>

Re: [ANN] New ServiceComb committer: Zhang Lei (张磊）

[wjm wjm]

Congratulations~

bismy  于2019年4月2日周二 上午10:46写道：

> Great!
>
>
>
>
> -- 原始邮件 --
> 发件人: "Sure";
> 发送时间: 2019年4月2日(星期二) 上午10:18
> 收件人: "dev";
>
> 主题: 回复：[ANN] New ServiceComb committer: Zhang Lei (张磊）
>
>
>
> Congratulations!
>
>
>
>
> -- 原始邮件 --
> 发件人: Willem Jiang 
> 发送时间: 2019年4月1日 23:19
> 收件人: dev 
> 主题: 回复：[ANN] New ServiceComb committer: Zhang Lei (张磊）
>
>
>
> Sorry, there is a typo in the first mail.  The first sentence should be:
>
> Please join me and the rest of the ServiceComb PPMC members in welcoming
> our
> new ServiceComb committer: Zhang Lei (张磊).
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Apr 1, 2019 at 10:53 PM Willem Jiang 
> wrote:
> >
> > Please join me and the rest of the ServiceComb PPMC members in welcoming
> our
> > new ServiceComb committer: Zhang Lei (赵俊).
> >
> > Zhang Lei contribute the ServiceComb earlier this year， he is active
> > contributor on pack project and the mailing list, and we look
> > forward to many more contributions in the future.
> >
> > Congratulations to Zhang Lei! Welcome!
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem

Re: Release of ServiceComb

[wjm wjm]

https://github.com/apache/servicecomb-java-chassis/pull/1160
https://github.com/apache/servicecomb-java-chassis/pull/1159
https://issues.apache.org/jira/browse/SCB-1232
https://issues.apache.org/jira/browse/SCB-1226

Willem Jiang  于2019年3月31日周日 下午3:26写道：

> Hi wjm,
>
> Could you list the blocker issues?
> I think we need to keep tracing them to make sure we cut the release on
> time.
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sun, Mar 31, 2019 at 11:56 AM wjm wjm  wrote:
> >
> > sorry, java-chassis still have some issue need to be fixed.
> >
> > zhang_...@boco.com.cn  于2019年3月26日周二 上午10:36写道：
> >
> > > verification all passed with spring-boot-1 and spring-boot-2
> > >
> > > # Cluster
> > > 1. alpha cluster master node switch - Pass
> > > 2. random gRPC port - Pass
> > > 3. alpha cluster with random gRPC port - Pass
> > >
> > > # Eureka
> > > 4. alpha register to Eureka - Pass
> > > 5. alpha cluster register to Eureka - Pass
> > > 6. alpha cluster register to Eureka with random gRPC port - Pass
> > >
> > > # Consul
> > > 7. alpha register to Consul - Pass
> > > 8. alpha cluster register to Consul - Pass
> > > 9. alpha cluster register to Consul with random gRPC port - Pass
> > >
> > >
> > > # Test instruction
> > > 1. alpha cluster master node switch
> > >
> > > java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> > > --spring.profiles.active=prd \
> > > --server.port=0 \
> > > --alpha.server.port=8080 \
> > >
> > >
> --spring.datasource.url="jdbc:postgresql://localhost:5432/saga?useSSL=false"
> > > \
> > > --spring.datasource.username=saga-user \
> > > --spring.datasource.password=saga-password \
> > > --alpha.cluster.master.enabled=true
> > >
> > >
> > > java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> > > --spring.profiles.active=prd \
> > > --server.port=0 \
> > > --alpha.server.port=8081 \
> > >
> > >
> --spring.datasource.url="jdbc:postgresql://localhost:5432/saga?useSSL=false"
> > > \
> > > --spring.datasource.username=saga-user \
> > > --spring.datasource.password=saga-password \
> > > --alpha.cluster.master.enabled=true
> > >
> > >
> > > java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> > > --spring.profiles.active=prd \
> > > --server.port=0 \
> > > --alpha.server.port=8082 \
> > >
> > >
> --spring.datasource.url="jdbc:postgresql://localhost:5432/saga?useSSL=false"
> > > \
> > > --spring.datasource.username=saga-user \
> > > --spring.datasource.password=saga-password \
> > > --alpha.cluster.master.enabled=true
> > >
> > > 2. random gRPC port
> > >
> > > java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> > > --spring.profiles.active=prd \
> > > --server.port=0 \
> > > --alpha.server.port=0 \
> > >
> > >
> --spring.datasource.url="jdbc:postgresql://localhost:5432/saga?useSSL=false"
> > > \
> > > --spring.datasource.username=saga-user \
> > > --spring.datasource.password=saga-password
> > >
> > > 3. alpha cluster with random gRPC port
> > >
> > > repeat three times
> > > java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> > > --spring.profiles.active=prd \
> > > --server.port=0 \
> > > --alpha.server.port=0 \
> > >
> > >
> --spring.datasource.url="jdbc:postgresql://localhost:5432/saga?useSSL=false"
> > > \
> > > --spring.datasource.username=saga-user \
> > > --spring.datasource.password=saga-password
> > >
> > > 4. alpha register to Eureka
> > >
> > > java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> > > --spring.profiles.active=prd \
> > >
> > >
> --spring.datasource.url="jdbc:postgresql://localhost:5432/saga?useSSL=false"
> > > \
> > > --spring.datasource.username=saga-user \
> > > --spring.datasource.password=saga-password \
> > > --eureka.client.enabled=true \
> > > --eureka.cli

Re: Release of ServiceComb

[wjm wjm]

sorry, java-chassis still have some issue need to be fixed.

zhang_...@boco.com.cn  于2019年3月26日周二 上午10:36写道：

> verification all passed with spring-boot-1 and spring-boot-2
>
> # Cluster
> 1. alpha cluster master node switch - Pass
> 2. random gRPC port - Pass
> 3. alpha cluster with random gRPC port - Pass
>
> # Eureka
> 4. alpha register to Eureka - Pass
> 5. alpha cluster register to Eureka - Pass
> 6. alpha cluster register to Eureka with random gRPC port - Pass
>
> # Consul
> 7. alpha register to Consul - Pass
> 8. alpha cluster register to Consul - Pass
> 9. alpha cluster register to Consul with random gRPC port - Pass
>
>
> # Test instruction
> 1. alpha cluster master node switch
>
> java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> --spring.profiles.active=prd \
> --server.port=0 \
> --alpha.server.port=8080 \
>
> --spring.datasource.url="jdbc:postgresql://localhost:5432/saga?useSSL=false"
> \
> --spring.datasource.username=saga-user \
> --spring.datasource.password=saga-password \
> --alpha.cluster.master.enabled=true
>
>
> java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> --spring.profiles.active=prd \
> --server.port=0 \
> --alpha.server.port=8081 \
>
> --spring.datasource.url="jdbc:postgresql://localhost:5432/saga?useSSL=false"
> \
> --spring.datasource.username=saga-user \
> --spring.datasource.password=saga-password \
> --alpha.cluster.master.enabled=true
>
>
> java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> --spring.profiles.active=prd \
> --server.port=0 \
> --alpha.server.port=8082 \
>
> --spring.datasource.url="jdbc:postgresql://localhost:5432/saga?useSSL=false"
> \
> --spring.datasource.username=saga-user \
> --spring.datasource.password=saga-password \
> --alpha.cluster.master.enabled=true
>
> 2. random gRPC port
>
> java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> --spring.profiles.active=prd \
> --server.port=0 \
> --alpha.server.port=0 \
>
> --spring.datasource.url="jdbc:postgresql://localhost:5432/saga?useSSL=false"
> \
> --spring.datasource.username=saga-user \
> --spring.datasource.password=saga-password
>
> 3. alpha cluster with random gRPC port
>
> repeat three times
> java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> --spring.profiles.active=prd \
> --server.port=0 \
> --alpha.server.port=0 \
>
> --spring.datasource.url="jdbc:postgresql://localhost:5432/saga?useSSL=false"
> \
> --spring.datasource.username=saga-user \
> --spring.datasource.password=saga-password
>
> 4. alpha register to Eureka
>
> java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> --spring.profiles.active=prd \
>
> --spring.datasource.url="jdbc:postgresql://localhost:5432/saga?useSSL=false"
> \
> --spring.datasource.username=saga-user \
> --spring.datasource.password=saga-password \
> --eureka.client.enabled=true \
> --eureka.client.service-url.defaultZone=
> http://127.0.0.1:8761/eureka
>
> 5. alpha cluster register to Eureka
>
> java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> --spring.profiles.active=prd \
> --server.port=0 \
> --alpha.server.port=8080 \
>
> --spring.datasource.url="jdbc:postgresql://localhost:5432/saga?useSSL=false"
> \
> --spring.datasource.username=saga-user \
> --spring.datasource.password=saga-password \
> --alpha.cluster.master.enabled=true \
> --eureka.client.enabled=true \
> --eureka.client.service-url.defaultZone=
> http://127.0.0.1:8761/eureka
>
> java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> --spring.profiles.active=prd \
> --server.port=0 \
> --alpha.server.port=8081 \
>
> --spring.datasource.url="jdbc:postgresql://localhost:5432/saga?useSSL=false"
> \
> --spring.datasource.username=saga-user \
> --spring.datasource.password=saga-password \
> --alpha.cluster.master.enabled=true \
> --eureka.client.enabled=true \
> --eureka.client.service-url.defaultZone=
> http://127.0.0.1:8761/eureka
>
> java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> --spring.profiles.active=prd \
> --server.port=0 \
> --alpha.server.port=8082 \
>
> --spring.datasource.url="jdbc:postgresql://localhost:5432/saga?useSSL=false"
> \
> --spring.datasource.username=saga-user \
> --spring.datasource.password=saga-password \
> --alpha.cluster.master.enabled=true \
> --eureka.client.enabled=true \
> --eureka.client.service-url.defaultZone=
> http://127.0.0.1:8761/eureka
>
> 6. alpha cluster register to Eureka with random gRPC port
> repeat three times
>
> java -jar alpha-server-0.4.0-SNAPSHOT-exec.jar \
> --spring.profiles.active=prd \
> 

Re: There are two dependencies which have no License definition in java-chassis

[wjm wjm]

https://github.com/netzwerg/paleo Apache-2.0
https://github.com/bodiam/markdown-to-asciidoc  Apache-2.0

maybe can be fixed in:
https://github.com/apache/servicecomb-java-chassis/pull/1149

Willem Jiang  于2019年3月29日周五 下午5:56写道：

> When I using the maven license plugin to generate the license
> information for the java-chassis, I got the following error message:
>
> [WARNING] There are 2 dependencies with no license :
> [WARNING]  - ch.netzwerg--paleo-core--0.11.0
> [WARNING]  - nl.jworks.markdown_to_asciidoc--markdown_to_asciidoc--1.0
>
> We need to fix this issue before cutting java-chassis.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>

Re: Release of ServiceComb

[wjm wjm]

java-chassis is ready.

bismy  于2019年3月19日周二 下午5:32写道：

> It's fine to me.
>
>
>
>
> -- 原始邮件 --
> 发件人: "zhang_...@boco.com.cn";
> 发送时间: 2019年3月19日(星期二) 下午5:16
> 收件人: "dev";
>
> 主题: Re: Release of ServiceComb
>
>
>
> I will update the document about alpha support consul later today
>
> coolbeevip
> 
> BOCO
>
>
>
> > 在 2019年3月19日，下午4:54，Willem Jiang  写道：
> >
> > As we talked, it's time to prepare the release.
> > There is only ten days to the end of this month, we need to make sure
> > the branches are ready to go.
> > Please reply this mail if you have any other big patch need to go with
> > this release, otherwise we will start the release process shortly.
> >
> > @Asif  Do you mind start the release check?
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, Mar 6, 2019 at 2:29 PM Willem Jiang 
> wrote:
> >>
> >> It's time for us to think about ServiceComb release now.
> >>
> >> As usual, we will release ServiceComb Java-Chassis 1.2.0,  ServiceComb
> >> ServiceCenter  1.2.0 at the end of this month, then we will release
> >> ServiceComb Pack 0.4.0.
> >>
> >> Please reply the mail if you have any questions about the release plan.
> >>
> >> Willem Jiang
> >>
> >> Twitter: willemjiang
> >> Weibo: 姜宁willem

Re: Release of ServiceComb

[wjm wjm]

java -chassis just need to merge exist PR

Willem Jiang  于2019年3月19日周二 下午4:54写道：

> As we talked, it's time to prepare the release.
> There is only ten days to the end of this month, we need to make sure
> the branches are ready to go.
> Please reply this mail if you have any other big patch need to go with
> this release, otherwise we will start the release process shortly.
>
> @Asif  Do you mind start the release check?
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Mar 6, 2019 at 2:29 PM Willem Jiang 
> wrote:
> >
> > It's time for us to think about ServiceComb release now.
> >
> > As usual, we will release ServiceComb Java-Chassis 1.2.0,  ServiceComb
> > ServiceCenter  1.2.0 at the end of this month, then we will release
> > ServiceComb Pack 0.4.0.
> >
> > Please reply the mail if you have any questions about the release plan.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
>

Re: Google Summer of Code 2019 Mentor Registration

[wjm wjm]

What is the responsibilities of the mentor?

Willem Jiang  于2019年3月10日周日 下午3:51写道：

> FYI, if you want to be a Google Summer of Code mentor, you could
> follow the instructions below to do the registration work.
> From my experience, you may also need to setup a proposal in the JIRA
> and try to attract the eyes of the student. Then you need to put some
> efforts on mentoring the student remotely.  It could be fantastic
> experience to help the student understand the open source by working
> with them closely.
> Please let me know if you have any questions about this, I could offer
> some mentor tips for you.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
> -- Forwarded message -
> From: Ulrich Stärk 
> Date: Sat, Mar 9, 2019 at 3:49 AM
> Subject: Google Summer of Code 2019 Mentor Registration
> To: 
> Cc: d...@community.apache.org 
>
>
> Dear PMCs,
>
> I'm happy to announce that the ASF has made it onto the list of
> accepted organizations for
> Google Summer of Code 2019! [1,2]
>
> It is now time for mentors to sign up, so please pass this email on to
> your community and
> podlings. If you aren’t already subscribed to
> ment...@community.apache.org you should do so now else
> you might miss important information.
>
> Mentor signup requires two steps: mentor signup in Google's system [3]
> and PMC acknowledgement.
>
> If you want to mentor a project in this year's SoC you will have to
>
> 1. Be an Apache committer.
> 2. Request an acknowledgement from the PMC for which you want to
> mentor projects. Use the below
> template and *do not forget to copy ment...@community.apache.org*. We
> will use the email adress you
> indicate to send the invite to be a mentor for Apache.
>
> PMCs, read carefully please.
>
> We request that each mentor is acknowledged by a PMC member. This is
> to ensure the mentor is in good
> standing with the community. When you receive a request for
> acknowledgement, please ACK it and cc
> ment...@community.apache.org
>
> Lastly, it is not yet too late to record your ideas in Jira (see
> previous emails for details).
> Students will now begin to explore ideas so if you haven’t already
> done so, record your ideas
> immediately!
>
> Cheers,
>
> The Apache GSoC Team
>
> mentor request email template:
> 
> to: private@.apache.org
> cc: ment...@community.apache.org
> subject: GSoC 2019 mentor request for 
>
>  PMC,
>
> please acknowledge my request to become a mentor for Google Summer of
> Code 2018 projects for Apache
> .
>
> I would like to receive the mentor invite to 
>
> 
>
> 
>
> [1] https://summerofcode.withgoogle.com/organizations/
> [2] https://summerofcode.withgoogle.com/organizations/6614885824200704/
> [3] https://summerofcode.withgoogle.com/
>

Re: [discuss][java-chassis] new feature for inspect internal statusof a microservice instance

[wjm wjm]

do you mean microservice instance provide RESTful api
and a standalone instance to provide UI?

seems like another governance entry..

bismy  于2019年3月6日周三 下午4:13写道：

> I have an general idea to do this:
>
>
> 1. We do not need to create a new port for this feature, and share the
> microservice port. It has same security constraints like REST api.
> 2. We can provide both ui and REST api for this feature. Provided we need
> to easily access the ui from edge service(Is this possible to do it
> easily?).
> 3. We can start a new project, e.g. servicecomb-admin (or a module like in
> edge service do), users start this admin service along with microservices.
> So they can access admin service easily, do not need to care much about
> security constraints like service center console.
>
>
>
>
>
>
> -- 原始邮件 --
> 发件人: "willem.jiang";
> 发送时间: 2019年3月5日(星期二) 下午2:12
> 收件人: "dev";
>
> 主题: Re: [discuss][java-chassis] new feature for inspect internal statusof
> a microservice instance
>
>
>
> I think we can start from the instance troubleshooting solution first,
> then we can consider to let management console redirect the request to
> the certain instance.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Tue, Mar 5, 2019 at 11:54 AM wjm wjm  wrote:
> >
> > @yaohai...@huawei.com   agree to you.
> > but
> > 1.graphical user interface is not a problem, network is a problem
> >   browser maybe can not connect to the instance directly
> > 2.we must provide these features by governance console, the problem is if
> > we will provide it by instance also?
> >   when provide by governance console, it's more powerful than by instance
> >   because instance can only have self information, but governance can
> show
> > related instance's information.
> >
> > yhs0092  于2019年3月5日周二 上午11:23写道：
> >
> > > Here is just my personal consideration. It's indeed a complex problem
> when
> > > get involved in security issues.
> > >
> > >
> > > Once we decide this function is only provided directly by the service
> > > instances, users can only log into the micro-service clusters to get
> access
> > > to these informations. In such case we can assume that the security
> should
> > > be guaranteed by users themselves.
> > > There are still several problems:
> > > 1. Usually there are all Linux OS servers in a cluster,  with no
> graphical
> > > user interface. It may be hard to find a browser to read the
> informations.
> > > 2. If the instances enable Mutual TLS authentication, it may be
> difficult
> > > to get access to the informations directly. Or we can provide an
> isolated
> > > port for this feature, but it makes us further away from our security
> goal.
> > >
> > >
> > > If we provide a separate console service, maybe we can solve these
> > > problem. The console can be split into web page and backend service.
> The
> > > backend service can be deployed into the service cluster. It can be
> treated
> > > as a common micro-service, which means the security options of it can
> keep
> > > the same as other services. The web pages, if they are static page with
> > > html+js, can be deployed in the edge service. If users are concerned
> about
> > > the security issues, they can add authorization by themselves.
> > > I think this solution is flexible, but complex for many users.
> > >
> > >
> > > On conclusion, I guess if this feature is provided by service instances
> > > directly, it is less complex for us to implement it. While it may be
> not so
> > > practical in production environment. If this feature is provided by
> another
> > > console service, it's more complex, but there are more chances to
> apply it
> > > into a production environment.
> > >
> > >
> > > Yours sincerely
> > >
> > >
> > > Yao Haishi
> > > yhs0...@163.com
> > >
> > >
> > > On 3/5/2019 10:37，wjm wjm wrote：
> > > this feature should be for both development and production
> environment, so
> > > must conside security problem.
> > > currently i'm not sure what's the best way to control it.
> > >
> > > yhs0092  于2019年3月5日周二 上午10:28写道：
> > >
> > > That's a great idea!
> > > What is the positioning of this feature? If it's designed for
> development
> > > environment trouble-shooting, I guess it's okay the web pag

Re: [dicusssion]upgrade spring boot 2 dependency

[wjm wjm]

+1

bismy  于2019年3月6日周三 下午4:22写道：

> Now java chassis depend on spring boot 2 2.0.0.RELEASE, this version is
> quite old fashioned. Although users can use dependency management to use
> other versions, but sometimes it is difficult to do so. Spring boot 2
> changed rapidly and many compatible problems with spring 5 version.
>
>
> So I suggest to upgrade spring boot 2 to 2.1.2.RELEASE.
>
>
> Any ideas?

Re: Release of ServiceComb

[wjm wjm]

ok

Willem Jiang  于2019年3月6日周三 下午2:53写道：

> It's time for us to think about ServiceComb release now.
>
> As usual, we will release ServiceComb Java-Chassis 1.2.0,  ServiceComb
> ServiceCenter  1.2.0 at the end of this month, then we will release
> ServiceComb Pack 0.4.0.
>
> Please reply the mail if you have any questions about the release plan.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>

Re: [discuss][java-chassis] new feature for inspect internal status of a microservice instance

[wjm wjm]

@yaohai...@huawei.com   agree to you.
but
1.graphical user interface is not a problem, network is a problem
  browser maybe can not connect to the instance directly
2.we must provide these features by governance console, the problem is if
we will provide it by instance also?
  when provide by governance console, it's more powerful than by instance
  because instance can only have self information, but governance can show
related instance's information.

yhs0092  于2019年3月5日周二 上午11:23写道：

> Here is just my personal consideration. It's indeed a complex problem when
> get involved in security issues.
>
>
> Once we decide this function is only provided directly by the service
> instances, users can only log into the micro-service clusters to get access
> to these informations. In such case we can assume that the security should
> be guaranteed by users themselves.
> There are still several problems:
> 1. Usually there are all Linux OS servers in a cluster,  with no graphical
> user interface. It may be hard to find a browser to read the informations.
> 2. If the instances enable Mutual TLS authentication, it may be difficult
> to get access to the informations directly. Or we can provide an isolated
> port for this feature, but it makes us further away from our security goal.
>
>
> If we provide a separate console service, maybe we can solve these
> problem. The console can be split into web page and backend service. The
> backend service can be deployed into the service cluster. It can be treated
> as a common micro-service, which means the security options of it can keep
> the same as other services. The web pages, if they are static page with
> html+js, can be deployed in the edge service. If users are concerned about
> the security issues, they can add authorization by themselves.
> I think this solution is flexible, but complex for many users.
>
>
> On conclusion, I guess if this feature is provided by service instances
> directly, it is less complex for us to implement it. While it may be not so
> practical in production environment. If this feature is provided by another
> console service, it's more complex, but there are more chances to apply it
> into a production environment.
>
>
> Yours sincerely
>
>
> Yao Haishi
> yhs0...@163.com
>
>
> On 3/5/2019 10:37，wjm wjm wrote：
> this feature should be for both development and production environment, so
> must conside security problem.
> currently i'm not sure what's the best way to control it.
>
> yhs0092  于2019年3月5日周二 上午10:28写道：
>
> That's a great idea!
> What is the positioning of this feature? If it's designed for development
> environment trouble-shooting, I guess it's okay the web pages are provided
> by the micro-service instances directly. But if this feature is expected to
> work in production environment, which may contains massive micro-service
> instances, maybe it's better that service instances provide RESTful
> interfaces, and users get access to these informations via the console
> service.
>
>
> Yours sincerely
>
>
> Yao Haishi
> yhs0...@163.com
>
>
> On 3/5/2019 09:52，wjm wjm wrote：
> @zhang_lei
>
> ServiceComb can run with spring boot, but will not depend on spring boot.
>
>
> wjm wjm  于2019年3月5日周二 上午9:49写道：
>
> href of gif:
>
> https://issues.apache.org/jira/secure/attachment/12961084/swaggerAndDocument.gif
> and more question:
> how to define the security of the new feature
> should open a new port for the feature?
>
>
> wjm wjm  于2019年3月5日周二 上午9:20写道：
>
> currently it's difficult to collect internal status of a microservice
> instance when some problem happened.
> eg:
> routing depend on cached instances, discovery tree, strategy of
> governances, and so on
> when we resolving routing related problem, we can only guess the status
> of all related modules.
>
>
> so we should provide a way to inspect the internal status of a
> microservice instance at runtime, maybe include:
> discovery tree
> isolation
> eventbus
> view schemas as swagger or html/pdf..
> ..
> maybe like the gif:
>
>
>
>
> my question:
> provide these informations include related html/js/css by instance
> directly, or only by governance console
> if provide by both instance and governance console, that will cause
> duplicate development
>
> if provide by instance
> what's the name of the module? "inspector"?
> swagger to html depend on "asciidoctor", which depend on jruby, it's very
> heavy.
> in my demo, resource of swagger and asciidoctor all load from cdn, but for
> some customer's environment, maybe can not connect to internet.
> any other idea?
>

Re: [discuss][java-chassis] new feature for inspect internal status of a microservice instance

[wjm wjm]

this feature should be for both development and production environment, so
must conside security problem.
currently i'm not sure what's the best way to control it.

yhs0092  于2019年3月5日周二 上午10:28写道：

> That's a great idea!
> What is the positioning of this feature? If it's designed for development
> environment trouble-shooting, I guess it's okay the web pages are provided
> by the micro-service instances directly. But if this feature is expected to
> work in production environment, which may contains massive micro-service
> instances, maybe it's better that service instances provide RESTful
> interfaces, and users get access to these informations via the console
> service.
>
>
> Yours sincerely
>
>
> Yao Haishi
> yhs0...@163.com
>
>
> On 3/5/2019 09:52，wjm wjm wrote：
> @zhang_lei
>
> ServiceComb can run with spring boot, but will not depend on spring boot.
>
>
> wjm wjm  于2019年3月5日周二 上午9:49写道：
>
> href of gif:
> https://issues.apache.org/jira/secure/attachment/12961084/swaggerAndDocument.gif
> and more question:
> how to define the security of the new feature
> should open a new port for the feature?
>
>
> wjm wjm  于2019年3月5日周二 上午9:20写道：
>
> currently it's difficult to collect internal status of a microservice
> instance when some problem happened.
> eg:
>   routing depend on cached instances, discovery tree, strategy of
> governances, and so on
>   when we resolving routing related problem, we can only guess the status
> of all related modules.
>
>
> so we should provide a way to inspect the internal status of a
> microservice instance at runtime, maybe include:
> discovery tree
> isolation
> eventbus
> view schemas as swagger or html/pdf..
> ..
> maybe like the gif:
>
>
>
>
> my question:
> provide these informations include related html/js/css by instance
> directly, or only by governance console
> if provide by both instance and governance console, that will cause
> duplicate development
>
> if provide by instance
> what's the name of the module? "inspector"?
> swagger to html depend on "asciidoctor", which depend on jruby, it's very
> heavy.
> in my demo, resource of swagger and asciidoctor all load from cdn, but for
> some customer's environment, maybe can not connect to internet.
> any other idea?

Re: [discuss][java-chassis] new feature for inspect internal status of a microservice instance

[wjm wjm]

@zhang_lei
ServiceComb can run with spring boot, but will not depend on spring boot.

wjm wjm  于2019年3月5日周二 上午9:49写道：

> href of gif:
> https://issues.apache.org/jira/secure/attachment/12961084/swaggerAndDocument.gif
> and more question:
>
>- how to define the security of the new feature
>- should open a new port for the feature?
>
>
> wjm wjm  于2019年3月5日周二 上午9:20写道：
>
>> currently it's difficult to collect internal status of a microservice
>> instance when some problem happened.
>> eg:
>>   routing depend on cached instances, discovery tree, strategy
>> of governances, and so on
>>   when we resolving routing related problem, we can only guess the status
>> of all related modules.
>>
>> so we should provide a way to inspect the internal status of a
>> microservice instance at runtime, maybe include:
>>
>>- discovery tree
>>- isolation
>>- eventbus
>>- view schemas as swagger or html/pdf..
>>- ..
>>
>> maybe like the gif:
>> [image: swaggerAndDocument.gif]
>>
>> my question:
>>
>>- provide these informations include related html/js/css by instance
>>directly, or only by governance console
>>
>> if provide by both instance and governance console, that will
>> cause duplicate development
>>
>>- if provide by instance
>>   - what's the name of the module? "inspector"?
>>   - swagger to html depend on "asciidoctor", which depend on jruby,
>>   it's very heavy.
>>   - in my demo, resource of swagger and asciidoctor all load from
>>   cdn, but for some customer's environment, maybe can not connect to 
>> internet.
>>- any other idea?
>>
>>

Re: [discuss][java-chassis] new feature for inspect internal status of a microservice instance

[wjm wjm]

href of gif:
https://issues.apache.org/jira/secure/attachment/12961084/swaggerAndDocument.gif
and more question:

   - how to define the security of the new feature
   - should open a new port for the feature?


wjm wjm  于2019年3月5日周二 上午9:20写道：

> currently it's difficult to collect internal status of a microservice
> instance when some problem happened.
> eg:
>   routing depend on cached instances, discovery tree, strategy
> of governances, and so on
>   when we resolving routing related problem, we can only guess the status
> of all related modules.
>
> so we should provide a way to inspect the internal status of a
> microservice instance at runtime, maybe include:
>
>- discovery tree
>- isolation
>- eventbus
>- view schemas as swagger or html/pdf..
>- ..
>
> maybe like the gif:
> [image: swaggerAndDocument.gif]
>
> my question:
>
>- provide these informations include related html/js/css by instance
>directly, or only by governance console
>
> if provide by both instance and governance console, that will
> cause duplicate development
>
>- if provide by instance
>   - what's the name of the module? "inspector"?
>   - swagger to html depend on "asciidoctor", which depend on jruby,
>   it's very heavy.
>   - in my demo, resource of swagger and asciidoctor all load from
>   cdn, but for some customer's environment, maybe can not connect to 
> internet.
>- any other idea?
>
>

[discuss][java-chassis] new feature for inspect internal status of a microservice instance

[wjm wjm]

currently it's difficult to collect internal status of a microservice
instance when some problem happened.
eg:
  routing depend on cached instances, discovery tree, strategy
of governances, and so on
  when we resolving routing related problem, we can only guess the status
of all related modules.

so we should provide a way to inspect the internal status of a microservice
instance at runtime, maybe include:

   - discovery tree
   - isolation
   - eventbus
   - view schemas as swagger or html/pdf..
   - ..

maybe like the gif:
[image: swaggerAndDocument.gif]

my question:

   - provide these informations include related html/js/css by instance
   directly, or only by governance console

if provide by both instance and governance console, that will
cause duplicate development

   - if provide by instance
  - what's the name of the module? "inspector"?
  - swagger to html depend on "asciidoctor", which depend on jruby,
  it's very heavy.
  - in my demo, resource of swagger and asciidoctor all load from cdn,
  but for some customer's environment, maybe can not connect to internet.
   - any other idea?

Re: [discuss][java-chassis] change name of spring cloud starterin serviceComb

[wjm wjm]

agree to @bi...@qq.com 

and maybe it's better to merge into new branch "weak-type",  which belongs
to 2.0, and have some other incompatible features.

bismy  于2019年2月23日周六 下午5:54写道：

> This work should be done in a very carefully way, because it has
> compatibility concerns. My suggestion is not do it now. And the suggested
> name is not very good.
>
>
> Maybe the following list is better:
>
>
> For spring boot 1:
> servicecomb-spring-boot-starter-provider
> servicecomb-spring-boot-starter-discovery
> servicecomb-spring-boot-starter-transport
>
> ...
>
>
> For spring boot 2:
> servicecomb-spring-boot2-starter-standalone
> servicecomb-spring-boot2-starter-servlet
> servicecomb-spring-boot2-starter-gateway
>
> ...
>
>
>
>
> -- 原始邮件 --
> 发件人: "杨少琴";
> 发送时间: 2019年2月21日(星期四) 下午5:59
> 收件人: "杨少琴";
> 抄送: "dev";
> 主题: Re:Re:[discuss][java-chassis] change name of spring cloud starterin
> serviceComb
>
>
>
> Correct the error:
>
> spring-boot2-starter-servlet -> servlet-spring-boot2-starter
>
>
>
>
> 在 2019-02-21 17:49:53，"杨少琴"  写道：
>
> Hi All
>
>
> The following is a supplementary list of possible affected artifacts:
>
>
> spring-boot2-starter-standalone -> standalone-spring-boot2-starter
> spring-boot2-starter-servlet -> standalone-spring-boot2-starter
> spring-boot2-starter-gateway -> gateway-spring-boot2-starter
> spring-boot2-starter-discovery -> discovery-spring-boot2-starter
>
>
>
> At 2019-02-21 15:41:26, "杨少琴"  wrote:
>
> Hi All
>
>
> I will changed the names of some of the serviceComb artifacts to make them
> conform to the naming conventions recommended by spring, which will lead to
> changes in maven's dependency path
>
>
> Here is a list of possible affected artifacts:
>
>
> spring-boot-starter-provider -> provider-spring-boot-starter
> spring-boot-starter-discovery -> discovery-spring-boot-starter
> spring-boot-starter-transport -> transport-spring-boot-starter
> spring-boot-starter-parent -> parent-spring-boot-starter
> spring-boot-starter-servicecomb -> servicecomb-spring-boot-starter
> spring-boot-starter-registry -> registry-spring-boot-starter
> spring-boot-starter-configuration -> configuration-spring-boot-starter
> business-service-spring-boot-starter-archetype ->
> business-service-archetype-spring-boot-starter
>
>
> Reference link:
> https://github.com/apache/servicecomb-java-chassis/issues/1034#event-2067536914
>
>
>
>
>
>
>
>
>
> 【网易自营|30天无忧退货】真性价比：网易员工用纸“无添加谷风一木软抽面巾纸”，限时仅16.9元一提>>

Re: [discuss][java-chassis] change core mechanism from strong typetoweak type

[wjm wjm]

conclusion:
  before finish all feature of weak type, all related PR will be merged to
new branch: weak-type

wjm wjm  于2019年2月14日周四 上午1:27写道：

>
>
> bismy  于2019年2月12日周二 下午3:19写道：
>
>> - javaTypes
>>in org.apache.servicecomb.swagger.invocation.response.ResponseMeta not
>>always avaiable,maybe will affect filters and handlers
>> This is rarely used, I think.
>>
> yes, but app market already used it.
>
>
>>-
>> org.apache.servicecomb.swagger.invocation.SwaggerInvocation#swaggerArguments
>>not always  avaiable, or will be deleted ,maybe will
>> affect
>>filters and handlers
>> If we can provide a method to get the arguments if users
>> need them in some common scenarios? Such as primitive parameters.
>>
> yes, will provide getByParameterName, but it's belongs to interface changed
>
>
>>- highway will upgrade to highway2, because highway codec is not
>>compatible to standard protobuf,   this will cause
>>consumer and producer must upgrade together when they use highway.
>>    If user still use highway, not highway2(That is we keep
>> the old implementation), is it possible?
>>
> almost impossible, because too expensive. we should remain dynamic create
> class or rewrite protoStuff codec based on weak type
>
>
>
>>
>>
>> -- 原始邮件 --
>> 发件人: "zzzwjm";
>> 发送时间: 2019年2月11日(星期一) 下午4:48
>> 收件人: "dev";
>>
>> 主题: Re: [discuss][java-chassis] change core mechanism from strong
>> typetoweak type
>>
>>
>>
>> after change to weak type, not compatible include following at least:
>>
>>- javaTypes
>>in org.apache.servicecomb.swagger.invocation.response.ResponseMeta not
>>always avaiable,maybe will affect filters and handlers
>>-
>> org.apache.servicecomb.swagger.invocation.SwaggerInvocation#swaggerArguments
>>not always  avaiable, or will be deleted ,maybe will
>> affect
>>filters and handlers
>>- highway will upgrade to highway2, because highway codec is not
>>compatible to standard protobuf,   this will cause
>>consumer and producer must upgrade together when they use highway.
>>
>>
>> maybe other not comptible functions.
>>
>> bismy  于2019年2月11日周一 上午9:50写道：
>>
>> > Can you list notable changes that users need to know when upgrade to the
>> > new version? This can help us to make the decision.
>> >
>> >
>> > In my opinion, if users upgrade to new version, and they can make some
>> > code change without lose any function, we can go forward this PR. Plus
>> for
>> > running applications, one microservice upgrade does not cause others
>> > (providers/consumers) to upgrade is necessary.
>> >
>> >
>> > If the two conditions mentioned above not match, we need to create a new
>> > branch to merge this PR.
>> > -- 原始邮件 --
>> > 发件人: "zzzwjm";
>> > 发送时间: 2019年2月1日(星期五) 中午11:34
>> > 收件人: "dev";
>> >
>> > 主题: Re: [discuss][java-chassis] change core mechanism from strong type
>> > toweak type
>> >
>> >
>> >
>> > useful for all scenes, i just write edge as a example, because edge has
>> the
>> > most serious problem with jvm meta overflow
>> > edge and normal microservice share the same mechanism
>> >
>> > compatible problem include:
>> >
>> >- some customer's handler and filter customization maybe need some
>> >change, because:
>> >   -
>> >
>> org.apache.servicecomb.swagger.invocation.SwaggerInvocation#swaggerArguments
>> >   will change name or removed
>> >   - java datatype in operationMeta will not always present
>> >- abandon highway, change to highway2, because highway codec based on
>> >ProtoStuff, ProtoStuff depend on strong type and not compatible to
>> > ProtoBuf
>> >for some datatye
>> >- ..
>> >
>> >
>> >
>> > Willem Jiang  于2019年1月31日周四 下午9:07写道：
>> >
>> > > What's the difference between the strong type and weak type?
>> > > From the mail I can tell the weak type is useful in the edge service,
>> > > can we just us it in the edge service?
>> > >
>> > > BTW, W

Re: [discuss][java-chassis] change core mechanism from strong typetoweak type

[wjm wjm]

bismy  于2019年2月12日周二 下午3:19写道：

> - javaTypes
>in org.apache.servicecomb.swagger.invocation.response.ResponseMeta not
>always avaiable,maybe will affect filters and handlers
> This is rarely used, I think.
>
yes, but app market already used it.


>-
> org.apache.servicecomb.swagger.invocation.SwaggerInvocation#swaggerArguments
>not always  avaiable, or will be deleted ,maybe will
> affect
>filters and handlers
> If we can provide a method to get the arguments if users
> need them in some common scenarios? Such as primitive parameters.
>
yes, will provide getByParameterName, but it's belongs to interface changed


>- highway will upgrade to highway2, because highway codec is not
>compatible to standard protobuf,   this will cause
>consumer and producer must upgrade together when they use highway.
>    If user still use highway, not highway2(That is we keep the
> old implementation), is it possible?
>
almost impossible, because too expensive. we should remain dynamic create
class or rewrite protoStuff codec based on weak type



>
>
> -- 原始邮件 --
> 发件人: "zzzwjm";
> 发送时间: 2019年2月11日(星期一) 下午4:48
> 收件人: "dev";
>
> 主题: Re: [discuss][java-chassis] change core mechanism from strong
> typetoweak type
>
>
>
> after change to weak type, not compatible include following at least:
>
>- javaTypes
>in org.apache.servicecomb.swagger.invocation.response.ResponseMeta not
>always avaiable,maybe will affect filters and handlers
>-
> org.apache.servicecomb.swagger.invocation.SwaggerInvocation#swaggerArguments
>not always  avaiable, or will be deleted ,maybe will
> affect
>filters and handlers
>- highway will upgrade to highway2, because highway codec is not
>compatible to standard protobuf,   this will cause
>consumer and producer must upgrade together when they use highway.
>
>
> maybe other not comptible functions.
>
> bismy  于2019年2月11日周一 上午9:50写道：
>
> > Can you list notable changes that users need to know when upgrade to the
> > new version? This can help us to make the decision.
> >
> >
> > In my opinion, if users upgrade to new version, and they can make some
> > code change without lose any function, we can go forward this PR. Plus
> for
> > running applications, one microservice upgrade does not cause others
> > (providers/consumers) to upgrade is necessary.
> >
> >
> > If the two conditions mentioned above not match, we need to create a new
> > branch to merge this PR.
> > -- 原始邮件 --
> > 发件人: "zzzwjm";
> > 发送时间: 2019年2月1日(星期五) 中午11:34
> > 收件人: "dev";
> >
> > 主题: Re: [discuss][java-chassis] change core mechanism from strong type
> > toweak type
> >
> >
> >
> > useful for all scenes, i just write edge as a example, because edge has
> the
> > most serious problem with jvm meta overflow
> > edge and normal microservice share the same mechanism
> >
> > compatible problem include:
> >
> >- some customer's handler and filter customization maybe need some
> >change, because:
> >   -
> >
> org.apache.servicecomb.swagger.invocation.SwaggerInvocation#swaggerArguments
> >   will change name or removed
> >   - java datatype in operationMeta will not always present
> >- abandon highway, change to highway2, because highway codec based on
> >ProtoStuff, ProtoStuff depend on strong type and not compatible to
> > ProtoBuf
> >for some datatye
> >- ..
> >
> >
> >
> > Willem Jiang  于2019年1月31日周四 下午9:07写道：
> >
> > > What's the difference between the strong type and weak type?
> > > From the mail I can tell the weak type is useful in the edge service,
> > > can we just us it in the edge service?
> > >
> > > BTW, We need to be care if there is a API break change, heading to
> > > version 2.0.0 is a good way, is there any other big change we need to
> > > make in the java-chassis 2.0.0?
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Wed, Jan 30, 2019 at 8:39 PM wjm wjm  wrote:
> > > >
> > > > currently, core mechanism is strong type
> > > > that caused to generate class dynamically in many special
> classloader,
> > > it's
> > > > 

Re: [discuss][java-chassis] change core mechanism from strong type toweak type

[wjm wjm]

after change to weak type, not compatible include following at least:

   - javaTypes
   in org.apache.servicecomb.swagger.invocation.response.ResponseMeta not
   always avaiable,maybe will affect filters and handlers
   - 
org.apache.servicecomb.swagger.invocation.SwaggerInvocation#swaggerArguments
   not always  avaiable, or will be deleted ,maybe will affect
   filters and handlers
   - highway will upgrade to highway2, because highway codec is not
   compatible to standard protobuf,   this will cause
   consumer and producer must upgrade together when they use highway.


maybe other not comptible functions.

bismy  于2019年2月11日周一 上午9:50写道：

> Can you list notable changes that users need to know when upgrade to the
> new version? This can help us to make the decision.
>
>
> In my opinion, if users upgrade to new version, and they can make some
> code change without lose any function, we can go forward this PR. Plus for
> running applications, one microservice upgrade does not cause others
> (providers/consumers) to upgrade is necessary.
>
>
> If the two conditions mentioned above not match, we need to create a new
> branch to merge this PR.
> -- 原始邮件 --
> 发件人: "zzzwjm";
> 发送时间: 2019年2月1日(星期五) 中午11:34
> 收件人: "dev";
>
> 主题: Re: [discuss][java-chassis] change core mechanism from strong type
> toweak type
>
>
>
> useful for all scenes, i just write edge as a example, because edge has the
> most serious problem with jvm meta overflow
> edge and normal microservice share the same mechanism
>
> compatible problem include:
>
>- some customer's handler and filter customization maybe need some
>change, because:
>   -
> org.apache.servicecomb.swagger.invocation.SwaggerInvocation#swaggerArguments
>   will change name or removed
>   - java datatype in operationMeta will not always present
>- abandon highway, change to highway2, because highway codec based on
>ProtoStuff, ProtoStuff depend on strong type and not compatible to
> ProtoBuf
>for some datatye
>- ..
>
>
>
> Willem Jiang  于2019年1月31日周四 下午9:07写道：
>
> > What's the difference between the strong type and weak type?
> > From the mail I can tell the weak type is useful in the edge service,
> > can we just us it in the edge service?
> >
> > BTW, We need to be care if there is a API break change, heading to
> > version 2.0.0 is a good way, is there any other big change we need to
> > make in the java-chassis 2.0.0?
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, Jan 30, 2019 at 8:39 PM wjm wjm  wrote:
> > >
> > > currently, core mechanism is strong type
> > > that caused to generate class dynamically in many special classloader,
> > it's
> > > dangerous:
> > >
> > >- need to generate almost all business classes in edge, maybe cause
> > jvm
> > >meta overflow
> > >- unable to support advanced features of swagger, such as allOf
> > >- caused some unnecessary data model convert
> > >
> > >
> > > so we need to change core mechanism from strong type to weak type, we
> had
> > > disscussed this before.
> > >
> > > the new problem is,  because the two mechanism is not compatible, we
> must
> > > make decisions about:
> > >
> > >- if plan it to be version 2.0.0
> > >- if we create branch for it
> > >- if not create branch, then same functions will have two
> implements,
> > >how to named the package
> > >- if create branch, then i will replace old  implement directly,
> that
> > >cause compile problems
> > >
> > > any suggestion?
> >

Re: [discuss][java-chassis] change core mechanism from strong type to weak type

[wjm wjm]

useful for all scenes, i just write edge as a example, because edge has the
most serious problem with jvm meta overflow
edge and normal microservice share the same mechanism

compatible problem include:

   - some customer's handler and filter customization maybe need some
   change, because:
  - 
org.apache.servicecomb.swagger.invocation.SwaggerInvocation#swaggerArguments
  will change name or removed
  - java datatype in operationMeta will not always present
   - abandon highway, change to highway2, because highway codec based on
   ProtoStuff, ProtoStuff depend on strong type and not compatible to ProtoBuf
   for some datatye
   - ..



Willem Jiang  于2019年1月31日周四 下午9:07写道：

> What's the difference between the strong type and weak type?
> From the mail I can tell the weak type is useful in the edge service,
> can we just us it in the edge service?
>
> BTW, We need to be care if there is a API break change, heading to
> version 2.0.0 is a good way, is there any other big change we need to
> make in the java-chassis 2.0.0?
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Jan 30, 2019 at 8:39 PM wjm wjm  wrote:
> >
> > currently, core mechanism is strong type
> > that caused to generate class dynamically in many special classloader,
> it's
> > dangerous:
> >
> >- need to generate almost all business classes in edge, maybe cause
> jvm
> >meta overflow
> >- unable to support advanced features of swagger, such as allOf
> >- caused some unnecessary data model convert
> >
> >
> > so we need to change core mechanism from strong type to weak type, we had
> > disscussed this before.
> >
> > the new problem is,  because the two mechanism is not compatible, we must
> > make decisions about:
> >
> >- if plan it to be version 2.0.0
> >- if we create branch for it
> >- if not create branch, then same functions will have two implements,
> >how to named the package
> >- if create branch, then i will replace old  implement directly,  that
> >cause compile problems
> >
> > any suggestion?
>

[discuss][java-chassis] change core mechanism from strong type to weak type

[wjm wjm]

currently, core mechanism is strong type
that caused to generate class dynamically in many special classloader, it's
dangerous:

   - need to generate almost all business classes in edge, maybe cause jvm
   meta overflow
   - unable to support advanced features of swagger, such as allOf
   - caused some unnecessary data model convert


so we need to change core mechanism from strong type to weak type, we had
disscussed this before.

the new problem is,  because the two mechanism is not compatible, we must
make decisions about:

   - if plan it to be version 2.0.0
   - if we create branch for it
   - if not create branch, then same functions will have two implements,
   how to named the package
   - if create branch, then i will replace old  implement directly,  that
   cause compile problems

any suggestion?

Re: [discuss] change default settings of sync invocation executor

[wjm wjm]

https://github.com/apache/servicecomb-java-chassis/pull/1077

wjm wjm  于2019年1月25日周五 上午9:05写道：

> @yaohai...@huawei.com 
>   think about a business, normally 30 threads are enough, but when
> business is busy, maybe need 300 threads
>   if use fixed thread pool, then after process boot, Whether the business
> is busy or not, must create 300 threads
>   but if use thread pool with core/max/keepAlive configuration, thread
> pool will create thread when business is busy, and destroy thread when
> business is not so busy.
>
> @willem.jiang 
>   yes, the thread pool is for sync business logic, it's for worker thread
>   but we change from old CPU count thread to tomcat default setting.
>
> Willem Jiang  于2019年1月24日周四 下午10:58写道：
>
>> If the thread pool with the cpu core is for the netty boss thread, I
>> think it should be fine.
>> But if the thread pool is for the worker thread, it could be a problem
>> if there are lots of requests need to be processed.
>>
>> Willem Jiang
>>
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>>
>> On Thu, Jan 24, 2019 at 2:48 PM yhs0092  wrote:
>> >
>> > I agree that current default value of thread pool size is too small,
>> but I'm not sure about the disadvantages of the current fixed thread pool.
>> > Do you mean if multiple service instances is deployed on the same
>> machine, a fixed thread pool is not so flexible since the instances cannot
>> clean up some idle business thread?
>> >
>> >
>> > Yours sincerely
>> >
>> >
>> > Yao Haishi
>> > yhs0...@163.com
>> >
>> >
>> > On 1/24/2019 10:49，wjm wjm wrote：
>> > or default integrate only one ThreadPoolExecutor?
>> > because most customers TPS is not so high, no need to do this optimize
>> >
>> > wjm wjm  于2019年1月24日周四 上午10:35写道：
>> >
>> > currently we provide a default sync invocation executor:
>> >
>> > - default integrate two fixed thread pool
>> > - thread count for one pool is equals cpu count
>> >
>> > for most customers, thread count of one pool is too small, and fixed
>> > thread pool is not so good, so will change to:
>> >
>> > - default integrate two ThreadPoolExecutor
>> > - support to configure core/max thread count, keepAlive time and max
>> > queue size for one pool
>> > - default core thread: 25, same to tomcat
>> > - default max thread: 100, tomcat is 200, because we have 2 pool, so
>> > change to 100
>> > - default keepAlive: 1 minute, same to tomcat
>> > - default max queue size: Integer.MAX_VALUE, same to tomcat
>> >
>> >
>>
>

Re: [Discuss] Should we support inner class param type defined inREST service class?

[wjm wjm]

just trace it, no need to do anything now.

bismy  于2019年1月26日周六 上午9:19写道：

> I'd prefer not to support this feature, at least not encourage users to
> use this feature. Because we consider service interfaces and related models
> as public components to other services. The implementation class (that is
> the REST service implementation) is not a public component.
>
>
> This feature may not work fine when we distribute services using JAVA API(
> that the client import the exposed JAVA api to call the remote service).
>
>
>
>
> -- 原始邮件 --
> 发件人: "yhs0092";
> 发送时间: 2019年1月25日(星期五) 中午12:54
> 收件人: "dev@servicecomb.apache.org";
>
> 主题: Re:  [Discuss] Should we support inner class param type defined inREST
> service class?
>
>
>
> A new issue[1] is created. I'll analyse the root cause later.
>
>
> [1] https://issues.apache.org/jira/browse/SCB-1133
>
>
> Yours sincerely
>
>
> Yao Haishi
> yhs0...@163.com
>
>
> On 1/25/2019 10:46，wjm wjm wrote：
> +1
>
> but if too complex, can IMPL it in weak type engine.
>
> yhs0092  于2019年1月25日周五 上午9:55写道：
>
> Hello, I find out that currently it's not supported to define a inner
> class type in the REST service class as parameter. Should we allow such use
> case?
>
>
> For example, a REST service like below will cause
> javassist.NotFoundException:
> training.demo.provider.service.TestRestService.TestBodyParam
> @RestSchema(schemaId = "testSchema")
> @RequestMapping(path = "test")
> public class TestRestService {
> @PostMapping(path = "post")
> public String post(@RequestBody TestBodyParam body) {
> return null == body ? "null" : body.toString();
> }
>
> public static class TestBodyParam {
> // fields omitted
> }
> }
>
>
> But inner class field in an independent param class is OK:
> @RestSchema(schemaId = "testSchema")
> @RequestMapping(path = "test")
> public class TestRestService {
> @PostMapping(path = "post")
> public String post(@RequestBody TestBodyParam body) {
> return null == body ? "null" : body.toString();
> }
> }
> // define param type in an independent class
> public class TestBodyParam {
> private InnerBody innerBody;
> public static class InnerBody {
>
> // fields omitted
> }
> // fields omitted
> }
>
>
> As described above, in some case, the inner class param type works well.
> If you think this feature should be provided, I'll create a JIRA issue to
> track it.
>
>
> Yours sincerely
>
>
> Yao Haishi
> yhs0...@163.com

Re: [discuss] change default value of verticle instance count

[wjm wjm]

https://github.com/apache/servicecomb-java-chassis/pull/1074

wjm wjm  于2019年1月25日周五 下午6:20写道：

> oh. sorry, you are right
>
> 在 2019年1月25日星期五，Yang Bo  写道：
>
>> Is vertical-count a typo? Think it should be verticle-count.
>>
>> On Fri, Jan 25, 2019 at 5:36 PM wjm wjm  wrote:
>>
>> > new change:
>> >   all thread-count rename to vertical-count
>> >   still allow use old key, but when use old key will print warning log,
>> > notice it's ambiguous and deprecated, suggest to use new name
>> >
>> > 在 2019年1月24日星期四，wjm wjm  写道：
>> >
>> > > eventloop will not eat all cpus, OS will schedule all the threads.
>> > >
>> > > yhs0092  于2019年1月24日周四 上午9:49写道：
>> > >
>> > >> Hi, wjm. Thank you for your sharing.
>> > >> As you say that if CPU count is less than 8, it's suggested that the
>> > >> thread-count is set to the CPU count. There is still a doubt for me.
>> In
>> > the
>> > >> synchronous mode, since the business logic runs in business thread
>> pool,
>> > >> i.e. the executor, don't we need to leave some CPU cores for the
>> > business ?
>> > >>
>> > >>
>> > >> Yours sincerely
>> > >>
>> > >>
>> > >> Yao Haishi
>> > >> yhs0...@163.com
>> > >>
>> > >>
>> > >> On 1/24/2019 09:38，bismy wrote：
>> > >> +1
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> -- 原始邮件 --
>> > >> 发件人: "zzzwjm";
>> > >> 发送时间: 2019年1月24日(星期四) 上午9:30
>> > >> 收件人: "dev";
>> > >>
>> > >> 主题: [discuss] change default value of verticle instance count
>> > >>
>> > >>
>> > >>
>> > >> currently, we created four type verticle for net send/receive and
>> > reactive
>> > >> business logic:
>> > >>
>> > >> - rest client verticle
>> > >> - rest server verticle
>> > >> - highway client verticle
>> > >> - highway server verticle
>> > >>
>> > >> instances of them controlled by configurations:
>> > >>
>> > >> - servicecomb.rest.server.thread-count
>> > >> - servicecomb.rest.client.thread-count
>> > >> - servicecomb.highway.server.thread-count
>> > >> - servicecomb. highway.client.thread-count
>> > >>
>> > >> default value of the configurations are set to 1 all, because
>> framework
>> > >> can
>> > >> not know what's the best value for them, so we set the conservative
>> > value
>> > >>
>> > >> these default values makes almost all customers need to optimize
>> > >> the configuration, it's not so good.
>> > >> so suggest the default values to be:
>> > >>
>> > >> - if cpu count less than 8, then thread-count set to cpu count
>> > >> - if cpu count equals or big than 8, then thread-count set to 8
>> > >
>> > >
>> >
>>
>>
>> --
>> Best Regards,
>> Yang.
>>
>

Re: [discuss] change default value of verticle instance count

[wjm wjm]

oh. sorry, you are right

在 2019年1月25日星期五，Yang Bo  写道：

> Is vertical-count a typo? Think it should be verticle-count.
>
> On Fri, Jan 25, 2019 at 5:36 PM wjm wjm  wrote:
>
> > new change:
> >   all thread-count rename to vertical-count
> >   still allow use old key, but when use old key will print warning log,
> > notice it's ambiguous and deprecated, suggest to use new name
> >
> > 在 2019年1月24日星期四，wjm wjm  写道：
> >
> > > eventloop will not eat all cpus, OS will schedule all the threads.
> > >
> > > yhs0092  于2019年1月24日周四 上午9:49写道：
> > >
> > >> Hi, wjm. Thank you for your sharing.
> > >> As you say that if CPU count is less than 8, it's suggested that the
> > >> thread-count is set to the CPU count. There is still a doubt for me.
> In
> > the
> > >> synchronous mode, since the business logic runs in business thread
> pool,
> > >> i.e. the executor, don't we need to leave some CPU cores for the
> > business ?
> > >>
> > >>
> > >> Yours sincerely
> > >>
> > >>
> > >> Yao Haishi
> > >> yhs0...@163.com
> > >>
> > >>
> > >> On 1/24/2019 09:38，bismy wrote：
> > >> +1
> > >>
> > >>
> > >>
> > >>
> > >> -- 原始邮件 --
> > >> 发件人: "zzzwjm";
> > >> 发送时间: 2019年1月24日(星期四) 上午9:30
> > >> 收件人: "dev";
> > >>
> > >> 主题: [discuss] change default value of verticle instance count
> > >>
> > >>
> > >>
> > >> currently, we created four type verticle for net send/receive and
> > reactive
> > >> business logic:
> > >>
> > >> - rest client verticle
> > >> - rest server verticle
> > >> - highway client verticle
> > >> - highway server verticle
> > >>
> > >> instances of them controlled by configurations:
> > >>
> > >> - servicecomb.rest.server.thread-count
> > >> - servicecomb.rest.client.thread-count
> > >> - servicecomb.highway.server.thread-count
> > >> - servicecomb. highway.client.thread-count
> > >>
> > >> default value of the configurations are set to 1 all, because
> framework
> > >> can
> > >> not know what's the best value for them, so we set the conservative
> > value
> > >>
> > >> these default values makes almost all customers need to optimize
> > >> the configuration, it's not so good.
> > >> so suggest the default values to be:
> > >>
> > >> - if cpu count less than 8, then thread-count set to cpu count
> > >> - if cpu count equals or big than 8, then thread-count set to 8
> > >
> > >
> >
>
>
> --
> Best Regards,
> Yang.
>

Re: [discuss] change default value of verticle instance count

[wjm wjm]

new change:
  all thread-count rename to vertical-count
  still allow use old key, but when use old key will print warning log,
notice it's ambiguous and deprecated, suggest to use new name

在 2019年1月24日星期四，wjm wjm  写道：

> eventloop will not eat all cpus, OS will schedule all the threads.
>
> yhs0092  于2019年1月24日周四 上午9:49写道：
>
>> Hi, wjm. Thank you for your sharing.
>> As you say that if CPU count is less than 8, it's suggested that the
>> thread-count is set to the CPU count. There is still a doubt for me. In the
>> synchronous mode, since the business logic runs in business thread pool,
>> i.e. the executor, don't we need to leave some CPU cores for the business ?
>>
>>
>> Yours sincerely
>>
>>
>> Yao Haishi
>> yhs0...@163.com
>>
>>
>> On 1/24/2019 09:38，bismy wrote：
>> +1
>>
>>
>>
>>
>> -- 原始邮件 --
>> 发件人: "zzzwjm";
>> 发送时间: 2019年1月24日(星期四) 上午9:30
>> 收件人: "dev";
>>
>> 主题: [discuss] change default value of verticle instance count
>>
>>
>>
>> currently, we created four type verticle for net send/receive and reactive
>> business logic:
>>
>> - rest client verticle
>> - rest server verticle
>> - highway client verticle
>> - highway server verticle
>>
>> instances of them controlled by configurations:
>>
>> - servicecomb.rest.server.thread-count
>> - servicecomb.rest.client.thread-count
>> - servicecomb.highway.server.thread-count
>> - servicecomb. highway.client.thread-count
>>
>> default value of the configurations are set to 1 all, because framework
>> can
>> not know what's the best value for them, so we set the conservative value
>>
>> these default values makes almost all customers need to optimize
>> the configuration, it's not so good.
>> so suggest the default values to be:
>>
>> - if cpu count less than 8, then thread-count set to cpu count
>> - if cpu count equals or big than 8, then thread-count set to 8
>
>

Re: [discuss] enhance boot log

[wjm wjm]

sometimes, it just a warning, not fatal

Willem Jiang  于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  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...
>

[discuss] enhance boot log

[wjm wjm]

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

Re: [Discuss] Should we support inner class param type defined in REST service class?

[wjm wjm]

+1

but if too complex, can IMPL it in weak type engine.

yhs0092  于2019年1月25日周五 上午9:55写道：

> Hello, I find out that currently it's not supported to define a inner
> class type in the REST service class as parameter. Should we allow such use
> case?
>
>
> For example, a REST service like below will cause
> javassist.NotFoundException:
> training.demo.provider.service.TestRestService.TestBodyParam
> @RestSchema(schemaId = "testSchema")
> @RequestMapping(path = "test")
> public class TestRestService {
> @PostMapping(path = "post")
> public String post(@RequestBody TestBodyParam body) {
> return null == body ? "null" : body.toString();
>   }
>
> public static class TestBodyParam {
> // fields omitted
> }
> }
>
>
> But inner class field in an independent param class is OK:
> @RestSchema(schemaId = "testSchema")
> @RequestMapping(path = "test")
> public class TestRestService {
> @PostMapping(path = "post")
> public String post(@RequestBody TestBodyParam body) {
> return null == body ? "null" : body.toString();
>   }
> }
> // define param type in an independent class
> public class TestBodyParam {
> private InnerBody innerBody;
> public static class InnerBody {
>
> // fields omitted
> }
> // fields omitted
> }
>
>
> As described above, in some case, the inner class param type works well.
> If you think this feature should be provided, I'll create a JIRA issue to
> track it.
>
>
> Yours sincerely
>
>
> Yao Haishi
> yhs0...@163.com
>
>

Re: [discuss] change default settings of sync invocation executor

[wjm wjm]

@yaohai...@huawei.com 
  think about a business, normally 30 threads are enough, but when business
is busy, maybe need 300 threads
  if use fixed thread pool, then after process boot, Whether the business
is busy or not, must create 300 threads
  but if use thread pool with core/max/keepAlive configuration, thread pool
will create thread when business is busy, and destroy thread when business
is not so busy.

@willem.jiang 
  yes, the thread pool is for sync business logic, it's for worker thread
  but we change from old CPU count thread to tomcat default setting.

Willem Jiang  于2019年1月24日周四 下午10:58写道：

> If the thread pool with the cpu core is for the netty boss thread, I
> think it should be fine.
> But if the thread pool is for the worker thread, it could be a problem
> if there are lots of requests need to be processed.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Thu, Jan 24, 2019 at 2:48 PM yhs0092  wrote:
> >
> > I agree that current default value of thread pool size is too small, but
> I'm not sure about the disadvantages of the current fixed thread pool.
> > Do you mean if multiple service instances is deployed on the same
> machine, a fixed thread pool is not so flexible since the instances cannot
> clean up some idle business thread?
> >
> >
> > Yours sincerely
> >
> >
> > Yao Haishi
> > yhs0...@163.com
> >
> >
> > On 1/24/2019 10:49，wjm wjm wrote：
> > or default integrate only one ThreadPoolExecutor?
> > because most customers TPS is not so high, no need to do this optimize
> >
> > wjm wjm  于2019年1月24日周四 上午10:35写道：
> >
> > currently we provide a default sync invocation executor:
> >
> > - default integrate two fixed thread pool
> > - thread count for one pool is equals cpu count
> >
> > for most customers, thread count of one pool is too small, and fixed
> > thread pool is not so good, so will change to:
> >
> > - default integrate two ThreadPoolExecutor
> > - support to configure core/max thread count, keepAlive time and max
> > queue size for one pool
> > - default core thread: 25, same to tomcat
> > - default max thread: 100, tomcat is 200, because we have 2 pool, so
> > change to 100
> > - default keepAlive: 1 minute, same to tomcat
> > - default max queue size: Integer.MAX_VALUE, same to tomcat
> >
> >
>

Re: [discuss] change default settings of sync invocation executor

[wjm wjm]

or default integrate only one ThreadPoolExecutor?
because most customers TPS is not so high, no need to do this optimize

wjm wjm  于2019年1月24日周四 上午10:35写道：

> currently we provide a default sync invocation executor:
>
>- default integrate two fixed thread pool
>- thread count for one pool is equals cpu count
>
> for most customers, thread count of one pool is too small, and fixed
> thread pool is not so good, so will change to:
>
>- default integrate two ThreadPoolExecutor
>- support to configure core/max thread count, keepAlive time and max
>queue size for one pool
>- default core thread: 25, same to tomcat
>- default max thread: 100, tomcat is 200, because we have 2 pool, so
>change to 100
>- default keepAlive: 1 minute, same to tomcat
>- default max queue size: Integer.MAX_VALUE, same to tomcat
>
>

[discuss] change default settings of sync invocation executor

[wjm wjm]

currently we provide a default sync invocation executor:

   - default integrate two fixed thread pool
   - thread count for one pool is equals cpu count

for most customers, thread count of one pool is too small, and fixed thread
pool is not so good, so will change to:

   - default integrate two ThreadPoolExecutor
   - support to configure core/max thread count, keepAlive time and max
   queue size for one pool
   - default core thread: 25, same to tomcat
   - default max thread: 100, tomcat is 200, because we have 2 pool, so
   change to 100
   - default keepAlive: 1 minute, same to tomcat
   - default max queue size: Integer.MAX_VALUE, same to tomcat

Re: [discuss] change default value of verticle instance count

[wjm wjm]

eventloop will not eat all cpus, OS will schedule all the threads.

yhs0092  于2019年1月24日周四 上午9:49写道：

> Hi, wjm. Thank you for your sharing.
> As you say that if CPU count is less than 8, it's suggested that the
> thread-count is set to the CPU count. There is still a doubt for me. In the
> synchronous mode, since the business logic runs in business thread pool,
> i.e. the executor, don't we need to leave some CPU cores for the business ?
>
>
> Yours sincerely
>
>
> Yao Haishi
> yhs0...@163.com
>
>
> On 1/24/2019 09:38，bismy wrote：
> +1
>
>
>
>
> -- 原始邮件 --
> 发件人: "zzzwjm";
> 发送时间: 2019年1月24日(星期四) 上午9:30
> 收件人: "dev";
>
> 主题: [discuss] change default value of verticle instance count
>
>
>
> currently, we created four type verticle for net send/receive and reactive
> business logic:
>
> - rest client verticle
> - rest server verticle
> - highway client verticle
> - highway server verticle
>
> instances of them controlled by configurations:
>
> - servicecomb.rest.server.thread-count
> - servicecomb.rest.client.thread-count
> - servicecomb.highway.server.thread-count
> - servicecomb. highway.client.thread-count
>
> default value of the configurations are set to 1 all, because framework can
> not know what's the best value for them, so we set the conservative value
>
> these default values makes almost all customers need to optimize
> the configuration, it's not so good.
> so suggest the default values to be:
>
> - if cpu count less than 8, then thread-count set to cpu count
> - if cpu count equals or big than 8, then thread-count set to 8

[discuss] change default value of verticle instance count

[wjm wjm]

currently, we created four type verticle for net send/receive and reactive
business logic:

   - rest client verticle
   - rest server verticle
   - highway client verticle
   - highway server verticle

instances of them controlled by configurations:

   - servicecomb.rest.server.thread-count
   - servicecomb.rest.client.thread-count
   - servicecomb.highway.server.thread-count
   - servicecomb. highway.client.thread-count

default value of the configurations are set to 1 all, because framework can
not know what's the best value for them, so we set the conservative value

these default values makes almost all customers need to optimize
the configuration, it's not so good.
so suggest the default values to be:

   - if cpu count less than 8, then thread-count set to cpu count
   - if cpu count equals or big than 8, then thread-count set to 8

Re: Java-Chassis interceptor

[wjm wjm]

for option 2, the two events must be the same thread, and can set and clear
safely

Willem Jiang  于2019年1月22日周二 上午9:12写道：

> Hi jimin,
>
> Thanks for the suggestion.
> I think the hardest part of this work is handling thread switching
> work,  event we could clean up the OmegaContext when the
> InvocationBusinessMethodFinishEvent happened, we still need to find
> the right moment to setup the OmegaContext.  So I think the option 1
> is the best way to go.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Jan 21, 2019 at 10:51 PM wjm wjm  wrote:
> >
> > all the following solutions can support this:
> > 1.implement a handle, and require customers to configure it to be the
> last
> > handler
> >
> > @Override
> > public void handle(Invocation invocation, AsyncResponse asyncResp)
> > throws Exception {
> >   set context
> >
> >   try {
> > invocation.next(asyncResp);
> >   } finally {
> > clear context
> >   }
> > }
> >
> >
> > 2.subscribe events:
> > org.apache.servicecomb.core.event.InvocationBusinessMethodStartEvent
> to
> > set context, this event means business method will be invoked in this
> thread
> >
>  org.apache.servicecomb.core.event.InvocationBusinessMethodFinishEvent to
> > clear context, this event means business method already returned in this
> > thread, for async method, this not means response data model is ready.
> >
> > we can get EventBus by
> org.apache.servicecomb.core.SCBEngine#getEventBus
> >
> > Willem Jiang  于2019年1月21日周一 下午5:16写道：
> >
> > > Hi,
> > >
> > > Current we got an issue[1] to clean up the OmegaContext after the
> > > invocation on the server side to clean up the thread local variable
> > > which OmegaContext set.
> > > Now I have a question for the handler of servicecomb java-chassis. How
> > > can I do the same thing on the java-chassis SagaProviderHandler[2]?
> > >
> > > [1]https://github.com/apache/servicecomb-pack/issues/384
> > > [2]
> > >
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-transport/omega-transport-servicecomb/src/main/java/org/apache/servicecomb/pack/omega/transport/servicecomb/SagaProviderHandler.java
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
>

Re: [discuss] change mechanism of java chassis POJO consumerparamters mapping

[wjm wjm]

in most times, customers can add one parameter in producer, but compatible
to old versions
in this time, we force customers must upgrade their consumers, it's too bad.

if map parameters by index, add any new parameter in a wrapper like
"QueryWrapper", a logic error will occur
but if map parameters by name, only add new parameters which
have duplicated name will cause the error

so i think, map by name still is better.



bismy  于2019年1月21日周一 下午3:28写道：

> I do not think your suggestion is a good idea, and I'd prefer not change
> it and remain the same.
>
>
> You problem comes from the semantics of the definition:
>void method(QueryWrapper querys, int p2);
> For query parameter querys (type of QueryWrapper) do not mean one
> parameter, but many parameters based on it's structure, it a special
> grammar for POJO queries. So the client code can be:
>void method(int x, int y, int p2)
> or
>void method(int x, int y, int z, int p2)
>
>
> When you add a new name for QueryWrapper, it equals to you add a parameter
> for
>void method(int x, int y, int p2) to void method(int x, int y, int z,
> int p2)
> and it's a change should be noticed that client should change the
> invocation code.
>
>
> Benefit for your suggestion is that users can add new parameters for an
> API, and I think this scenario is a CHANGE, and should change client code,
> but not adapt to it.
>
>
> And if you use parameter name to handle this, their will cause conflicts.
> For example, add an x for this method:
>void method(QueryWrapper querys, int x, int y);
>
>
> And We need to consider other problems like name in
> @RequestParam("name1")  is different with parameter name.
>
>
> In conclusion, I prefer not to handle this scenario.
>
>
> -- 原始邮件 --
> 发件人: "zzzwjm";
> 发送时间: 2019年1月18日(星期五) 凌晨0:17
> 收件人: "dev@servicecomb.apache.org";
>
> 主题: Re: [discuss] change mechanism of java chassis POJO consumerparamters
> mapping
>
>
>
> java8 support present interface method parameter name
> need to add compile argument, not debug option
>
> 在 2019年1月17日星期四，Willem Jiang  写道：
>
> > Java compile will remove the parameters name by default. We faced the
> > same problem in CXF simple frontend.
> > The solution could be enable the debug option in the compiler or add
> > annotation to the parameters.
> >
> > If we decide to setting the option on the compiler, we should not only
> > throw exception in the runtime, but also document it.
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Thu, Jan 17, 2019 at 5:23 PM wjm wjm  wrote:
> > >
> > > Scenes：
> > > 1.producer is springMVC dev mode
> > >   class QueryWrapper {
> > > int x;
> > > int y;
> > >   }
> > >   void method(QueryWrapper querys, int p2);
> > >
> > >   will produce swagger operation, have 3 parameters: x, y, p2
> > >
> > > 2.consumer is POJO dev mode, declare a interface:
> > >   interface TestIntf {
> > > void method(int x, int y, int p2);
> > >   }
> > >   until now, everything is ok.
> > >
> > > 3.producer upgrade
> > >   class QueryWrapper {
> > > int x;
> > > int y;
> > > int z;
> > >   }
> > >   will produce swagger operation, have 4 parameters: x,y,z,p2
> > >
> > >   in this time, old POJO consumers will have problems:
> > > assign x to x, y to y, p2 to z
> > >   that's because we map parameters by their index
> > >
> > > to resolve the problem:
> > >   we need to map parameters by their name
> > >   this require customers change their compile argument in pom.xml to
> > allow
> > > interface present method parameter name
> > >   if did not add compile argument, SDK can throw exception, and print
> how
> > > to add the compile argument.
> > >
> > >   any idea?
> >

Re: Java-Chassis interceptor

[wjm wjm]

all the following solutions can support this:
1.implement a handle, and require customers to configure it to be the last
handler

@Override
public void handle(Invocation invocation, AsyncResponse asyncResp)
throws Exception {
  set context

  try {
invocation.next(asyncResp);
  } finally {
clear context
  }
}


2.subscribe events:
org.apache.servicecomb.core.event.InvocationBusinessMethodStartEvent to
set context, this event means business method will be invoked in this thread
org.apache.servicecomb.core.event.InvocationBusinessMethodFinishEvent to
clear context, this event means business method already returned in this
thread, for async method, this not means response data model is ready.

we can get EventBus by org.apache.servicecomb.core.SCBEngine#getEventBus

Willem Jiang  于2019年1月21日周一 下午5:16写道：

> Hi,
>
> Current we got an issue[1] to clean up the OmegaContext after the
> invocation on the server side to clean up the thread local variable
> which OmegaContext set.
> Now I have a question for the handler of servicecomb java-chassis. How
> can I do the same thing on the java-chassis SagaProviderHandler[2]?
>
> [1]https://github.com/apache/servicecomb-pack/issues/384
> [2]
> https://github.com/apache/servicecomb-pack/blob/master/omega/omega-transport/omega-transport-servicecomb/src/main/java/org/apache/servicecomb/pack/omega/transport/servicecomb/SagaProviderHandler.java
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>

Re: [DISCUSSION] create a new project servicecomb-samples

[wjm wjm]

+1

and old samples can move to new repository

bismy  于2019年1月21日周一 下午3:34写道：

> Hello all,
>
>
> I suggest the create a new project servicecomb-samples to hosting code of
> servicecomb examples. Currently we have samples in each project, but is not
> enough for reasons:
>
>
> 1. Create new examples will make project huge and hard to distribute.
> 2. We can not create examples based on released version.
> 3. Lack of examples to show integrated features use both of java-chassis
> and saga features.
>
>
> Any ideas?

Re: [VOTE]Tracking the Github issue discussions to dev@servicecomb.apache.org

[wjm wjm]

+1

just one change: keep answer questions.

Willem Jiang  于2019年1月21日周一 下午4:05写道：

> I'm agree with Liubao.
>
> The background of moving the github issue is to attract more users by
> sporting the popular way of asking question in github issue.
> If we treat github issue as the mailing list of
> us...@servicecomb.apache.org, if we can keep answer the question and
> the question are archived, I think it should be fine. We don't need to
> do anything to routing the mail around.
>
> BTW, when I draft the board report, I include the github activities
> with the mail activities.
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Jan 21, 2019 at 3:36 PM bismy  wrote:
> >
> > For my personal preferences, we don't need to change anything, and now
> everything works fine.
> >
> >
> > 1. We discussion problem is dev mailing list. Users can send their
> questions though mail.
> > 2. Users submit issues or ask questions in issues @github, I subscribe
> notifications from github and answers questions @github.
> >
> >
> > We can encourage users to discuss problems using mailing list and
> submit/discuss issues @github.
> >
> >
> > -- 原始邮件 --
> > 发件人: "Zen Lin";
> > 发送时间: 2019年1月15日(星期二) 中午12:07
> > 收件人: "dev";
> >
> > 主题: Re: [VOTE]Tracking the Github issue discussions to
> dev@servicecomb.apache.org
> >
> >
> >
> > If there is no one knows how the Infra team track the github notification
> > to commits list, I am going to ask the Infra team for the details, and
> will
> > help to research the feasibility of separation.
> >
> > Best Regards,
> > ---
> > Zen Lin
> > zenlintechnofr...@gmail.com
> > Focused on Micro Service and Apache ServiceComb
> >
> >
> > Zen Lin  于2019年1月15日周二 上午11:56写道：
> >
> > > Is there anyone knows how Infra group  track the github notification to
> > > comm...@servicecomb.apache.org?
> > > If it is using github API, it is work to seperate github issue.
> > >
> > > Best Regards,
> > > ---
> > > Zen Lin
> > > zenlintechnofr...@gmail.com
> > > Focused on Micro Service and Apache ServiceComb
> > >
> > >
> > > Willem Jiang  于2019年1月15日周二 上午11:44写道：
> > >
> > >> We cannot just redirect the question to the Infra team without doing
> > >> the research first.
> > >> My suggestion is we need to do some research to figure out how to
> > >> separate the github issue notification from the github notification
> > >> stream.
> > >> Then we can give the Infra team instructions to do the work with their
> > >> admin right.
> > >> If we cannot get there, we could consider to disable the github issue
> > >> function to let user use mail to ask questions directly.
> > >>
> > >> Willem Jiang
> > >>
> > >> Twitter: willemjiang
> > >> Weibo: 姜宁willem
> > >>
> > >> On Tue, Jan 15, 2019 at 9:54 AM Zen Lin 
> > >> wrote:
> > >> >
> > >> > Yeah,
> > >> > If we track the github issue to dev mail, we can watch the issue
> > >> > contents in the dev mailing list.
> > >> > If you want your reply can posted to the github issue, you can
> > >> > reply the mail sent by github, in that way, the reply can be posted
> > >> > on issue and also be sent to the dev mailing list.
> > >> >
> > >> > Anyway,  as Willem said, we now have tracked the github
> > >> > notification to comm...@servicecomb.apache.org, we just need
> > >> > to seperate them from the github notification.
> > >> >
> > >> > Hi Willem,
> > >> > As I known, this will be implemented by Apache Infra group.
> > >> > What about to create a vote for this, and then I will create an
> > >> > issue to Apache Infra,
> > >> > or just create a mail to copy to infrastructure-...@apache.org
> > >> >
> > >> > Best Regards,
> > >> > ---
> > >> > Zen Lin
> > >> > zenlintechnofr...@gmail.com
> > >> > Focused on Micro Service and Apache ServiceComb
> > >> >
> > >> >
> > >> > Willem Jiang  于2019年1月15日周二 上午9:27写道：
> > >> >
> > >> > > I don't think we can bridge the dev mail to the github issue, but
> it
> > >> > > makes sense that to send the notification or the github issue to
> the
> > >> > > dev mailing list.
> > >> > > Now we need to figure out if we can seperate the github
> notification
> > >> > > by checking if it comes from github issues.
> > >> > >
> > >> > > Willem Jiang
> > >> > >
> > >> > > Twitter: willemjiang
> > >> > > Weibo: 姜宁willem
> > >> > >
> > >> > > On Mon, Jan 14, 2019 at 10:00 PM Zheng Feng 
> > >> wrote:
> > >> > > >
> > >> > > > I wonder if it can only watch the github issues by using the dev
> > >> mailing
> > >> > > > list or we can reply the thread and it could be posted to the
> github
> > >> > > issue
> > >> > > > automatically ?
> > >> > > >
> > >> > > > Zen Lin  于2019年1月14日周一 下午8:38写道：
> > >> > > >
> > >> > > > > How about to create a new proposal discussion for split github
> > >> issue
> > >> > > track
> > >> > > > > from commits mailing list to dev mailing list?
> > >> > > > > I think discussion in github issue is quite different from
> > >> commits,
> > >> > > they
> > >> > > > > are similar to the 

Re: [discuss] change mechanism of java chassis POJO consumer paramters mapping

[wjm wjm]

java8 support present interface method parameter name
need to add compile argument, not debug option

在 2019年1月17日星期四，Willem Jiang  写道：

> Java compile will remove the parameters name by default. We faced the
> same problem in CXF simple frontend.
> The solution could be enable the debug option in the compiler or add
> annotation to the parameters.
>
> If we decide to setting the option on the compiler, we should not only
> throw exception in the runtime, but also document it.
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Thu, Jan 17, 2019 at 5:23 PM wjm wjm  wrote:
> >
> > Scenes：
> > 1.producer is springMVC dev mode
> >   class QueryWrapper {
> > int x;
> > int y;
> >   }
> >   void method(QueryWrapper querys, int p2);
> >
> >   will produce swagger operation, have 3 parameters: x, y, p2
> >
> > 2.consumer is POJO dev mode, declare a interface:
> >   interface TestIntf {
> > void method(int x, int y, int p2);
> >   }
> >   until now, everything is ok.
> >
> > 3.producer upgrade
> >   class QueryWrapper {
> > int x;
> > int y;
> > int z;
> >   }
> >   will produce swagger operation, have 4 parameters: x,y,z,p2
> >
> >   in this time, old POJO consumers will have problems:
> > assign x to x, y to y, p2 to z
> >   that's because we map parameters by their index
> >
> > to resolve the problem:
> >   we need to map parameters by their name
> >   this require customers change their compile argument in pom.xml to
> allow
> > interface present method parameter name
> >   if did not add compile argument, SDK can throw exception, and print how
> > to add the compile argument.
> >
> >   any idea?
>

[discuss] change mechanism of java chassis POJO consumer paramters mapping

[wjm wjm]

Scenes：
1.producer is springMVC dev mode
  class QueryWrapper {
int x;
int y;
  }
  void method(QueryWrapper querys, int p2);

  will produce swagger operation, have 3 parameters: x, y, p2

2.consumer is POJO dev mode, declare a interface:
  interface TestIntf {
void method(int x, int y, int p2);
  }
  until now, everything is ok.

3.producer upgrade
  class QueryWrapper {
int x;
int y;
int z;
  }
  will produce swagger operation, have 4 parameters: x,y,z,p2

  in this time, old POJO consumers will have problems:
assign x to x, y to y, p2 to z
  that's because we map parameters by their index

to resolve the problem:
  we need to map parameters by their name
  this require customers change their compile argument in pom.xml to allow
interface present method parameter name
  if did not add compile argument, SDK can throw exception, and print how
to add the compile argument.

  any idea?

Re: community online discussion

[wjm wjm]

gitter?

Willem Jiang  于2019年1月4日周五 下午4:09写道：

> Hi  Team,
>
> Any thoughts about it?
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Dec 24, 2018 at 9:17 AM Willem Jiang 
> wrote:
> >
> > Hi Team
> >
> > We are try to run the biweekly meeting online[1] to get a chance to
> > talk the further development of ServiceComb. We tried to use the
> > zoom[2] for the meeting and wiki[1] for the tracing the result of the
> > meeting about the ServiceComb Pack project.  We could also leverage
> > the gitter[3] to start the discussion if the time schedule is not suit
> > for everyone.  We could encourage more people to get involved with our
> > development by sharing our road map with community.
> >
> > I highly recommend java-chassis and service-center to start the this
> > kind of on line discussion to let more people in the community to know
> > about our current development roadmap.
> >
> > Please let me know if you have any questions about it.
> >
> > [1]
> https://cwiki.apache.org/confluence/display/SERVICECOMB/Community+Meeting
> > [2]https://zoom.us/meeting/552485685
> > [3]https://gitter.im/ServiceCombUsers/Lobby
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
>

Re: Board Report of ServiceComb

[wjm wjm]

+1

Willem Jiang  于2018年12月5日周三 下午6:06写道：

> Hi Asif,
>
> Thanks for the suggestion. I will updated the board report with the
> new version of introduction.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Tue, Dec 4, 2018 at 2:04 PM Mohammad Asif Siddiqui
>  wrote:
> >
> > +1
> >
> > Suggestion :  I guess we can re-visit and update the description of
> ServiceComb.( ServiceComb is a full stack microservice framework which
> provides a set of SDK's, Service Registry and Transaction Management
> Services for rapid development of Cloud native applications.)
> >
> > Regards
> > Asif
> >
> > On 2018/12/03 15:18:41, Jean-Baptiste Onofré  wrote:
> > > +1
> > >
> > > it looks good to me.
> > >
> > > Thanks,
> > > Regards
> > > JB
> > >
> > > On 03/12/2018 09:44, Willem Jiang wrote:
> > > > Hi Team,
> > > >
> > > > Here is the draft of the board report this month (We need to submit
> it
> > > > to the board before 12 Dec). Please let me know if any thing is
> > > > missing or you have any questions about it.
> > > >
> > > > ## Description:
> > > >  -  a microservice framework that provides a set of tools and
> > > > components to make development and deployment of cloud applications
> > > > easier.
> > > >
> > > > ## Issues:
> > > >  -  There are no issues requiring board attention at this time.
> > > >
> > > > ## Activity:
> > > >  - ServiceComb PMC did the first around graduate release this month.
> > > >  - We began to hold the online community meeting[1] to discuss about
> > > > the roadmap of the project.
> > > >  - ServiceComb saga will be rename to pack[2] to provide the TCC and
> > > > Saga supports in the pack architecture
> > > >
> > > >  [1]
> https://cwiki.apache.org/confluence/display/SERVICECOMB/Community+Meeting
> > > >  [2]
> https://lists.apache.org/thread.html/b80d907cdc4585cea32c3b0258a1b6338bb3ab95118593a928bcfbd6@%3Cdev.servicecomb.apache.org%3E
> > > >
> > > > ## Health report:
> > > >  - The mails and commits activity are as good as usual.
> > > >
> > > > ## PMC changes:
> > > >
> > > >  - Currently 16 PMC members.
> > > >  - No new PMC members added in the last 3 months
> > > >
> > > > ## Committer base changes:
> > > >
> > > >  - Currently 18 committers.
> > > >  - New committers:
> > > > - Haishi Yao was added as a committer on Tue Nov 13 2018
> > > > - Jun Zhao was added as a committer on Tue Nov 13 2018
> > > >
> > > > ## Releases:
> > > >
> > > >  - ServiceComb Saga 0.2.1 on Nov 24, 2018
> > > >  - ServiceComb Java-Chassis 1.1.0 on Dec 1, 2018
> > > >  - ServiceComb Service-Center 1.1.0 on Dec 1, 2018
> > > >
> > > > ## Mailing list activity:
> > > >
> > > >  - dev@servicecomb.apache.org:
> > > > - This month, there were 197 emails sent by 25 people, divided
> > > > into 27 topics
> > > > - 130 subscribers (up 19 in the last 3 months):
> > > > - 485 emails sent to list (535 in previous quarter)
> > > >
> > > >  - iss...@servicecomb.apache.org:
> > > > - 8 subscribers (up 0 in the last 3 months):
> > > > - 2145 emails sent to list (2737 in previous quarter)
> > > >
> > > >
> > > > ## JIRA activity:
> > > >
> > > >  - 176 JIRA tickets created in the last 3 months
> > > >  - 179 JIRA tickets closed/resolved in the last 3 months
> > > >
> > > >
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > > >
> > >
> > > --
> > > Jean-Baptiste Onofré
> > > jbono...@apache.org
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> > >
>

Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.1.0

[wjm wjm]

+1 binding

check the source and binary release is OK
run demos  is OK

Sukesh A C  于2018年11月28日周三 下午12:19写道：

> +1 binding.
>
> Checks done:
> - verified signatures and hashes
> - LICENSE is ok
> - run demos
>
> Thanks,
> Sukesh.
>
> -Original Message-
> From: Mohammad Asif Siddiqui [mailto:asifdxtr...@apache.org]
> Sent: 27 November 2018 11:38
> To: dev@servicecomb.apache.org
> Subject: [VOTE] Release Apache ServiceComb Java-Chassis version 1.1.0
>
> Hello All,
>
> This is a call for a Vote to release Apache ServiceComb Java-Chassis
> version 1.1.0
>
> Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12343569
>
>
> Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.1.0/rc-01/
>
>
> Staging Repo :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1352
>
>
> Release Tag :
> https://github.com/apache/servicecomb-java-chassis/releases/tag/1.1.0
>
> Release CommitID : 1fa24999399f5d2f8e7dc7bc0972e3f3458f0374
>
> Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
>
> Voting will start now ( Tuesday, 27th November, 2018) and will remain open
> for at-least 72 hours, Request all PMC members to give their vote.
>
> [ ] +1 Release this package as 1.1.0
> [ ] +0 No Opinion
> [ ] -1 Do not release this package because
>
> On the behalf of ServiceComb Team
> Mohammad Asif Siddiqui
>

Re: [Discuss]Adding Etcd as a config center for Java-Chassis

[wjm wjm]

it's better to make huawei config center opensource
after governance opensource, can work with huawei config center directly

Yang Bo  于2018年11月27日周二 下午2:21写道：

> Etcd in itself is good enough to be used as a config center. I don't see
> the need for an extra layer, it reduces performance and adds complexity.
>
> For example, if we use Etcd directly, the watch mechanism is naturally
> supported by grpc which uses http2, there's no need for using websocket
> which might have problems under some firewall rules.
>
> I checked the CC(CSE) client implementation in java-chassis, it uses vert.x
> and http to talk to the server and use websocket for watching when
> possible.
>
> It have implemented tenant, environment separation and we can achieve this
> by using proper key prefixes in Etcd(v3). I don't see a particular feature
> impossible to implement using Etcd only.
>
> Besides, it takes a lot of time and effort to opensource the Config-Center.
>
> There is one minor issue for Etcd though. The official Etcd client for java
> jetcd is not published to central maven repository yet. They are preparing
> an official 0.3.0 release but does not have a timeline for it.
>
> On Tue, Nov 27, 2018 at 9:50 AM bismy  wrote:
>
> > Do you have any evaluation document by using etcd as config center? Now
> > config-cc supports using Huawei Config Center as the backend. And this
> > implementation is based on ectd with an extra abstraction like service
> > center. I am not quite sure if using etcd itself can fitful for users use
> > cases and if it is a good solution or just a workable solution.
> >
> >
> > Maybe we can make Huawei Config Center opensource and distribute it like
> > service center which is quite simple too.
> >
> >
> > -- 原始邮件 --
> > 发件人: "Yang Bo";
> > 发送时间: 2018年11月26日(星期一) 晚上7:30
> > 收件人: "dev";
> >
> > 主题: [Discuss]Adding Etcd as a config center for Java-Chassis
> >
> >
> >
> > Hi,
> >
> > The ServiceComb project does not have a usable config-center and many
> users
> > have shown concerns about it. (Apollo is too complex to setup and have
> high
> > learning cure  in using/maintaining).
> >
> > I tried to build a config-center around Etcd for Java-Chassis, it's quite
> > simple. Most of the features from the CC(CSE) can be achieved.
> >
> > From my point of view, using Etcd is good for small projects, show cases
> > and in development, because we already have an Etcd instance
> > running(service-center needs it).
> >
> > The code is here(it's just a demonstration, needs improvement):
> > https://github.com/yangbor/servicecomb-java-chassis/tree/cc-etcd
> >
> > Any thoughts?
> >
> > --
> > Best Regards,
> > Yang.
>
>
>
> --
> Best Regards,
> Yang.
>

Re: [VOTE] Release Apache ServiceComb Service-Center version 1.1.0 [RC-02]

[wjm wjm]

+1 binding

Checks I did:
- NOTICE/LICENSE exists
- can make release kit from source

Mohammad Asif Siddiqui  于2018年11月26日周一 下午2:13写道：

> +1 binding
>
> Checks Done :
> - hashes and signatures is good
> - NOTICE/LICENSE exists
> - ran RAT tool
> - can make release kit from source
> - checked for archive matching git tag
> - Source file have ASF headers
> - Ran the java-chassis and go-chassis demo's using the binary.
>
> Regards
> Asif
>
> On 2018/11/23 16:41:12, Mohammad Asif Siddiqui 
> wrote:
> > Hi All,
> >
> > This is a call for a Vote to release Apache ServiceComb Service-Center
> version 1.1.0 [RC-02]
> >
> > Release Notes :
> https://github.com/apache/servicecomb-service-center/blob/master/docs/release/releaseNotes-1.1.0.md
>
> >
> > Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-service-center/1.1.0/rc-02/
>
> >
> > Release Tag :
> https://github.com/apache/servicecomb-service-center/releases/tag/1.1.0
> >
> > Release CommitID : 49428294a99f2a475203a7ceb04ce8d5754feb77
> >
> > Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> >
> > Guide to build the release from source :
> https://github.com/apache/servicecomb-service-center/tree/master/scripts/release
>
> >
> > Voting will start now ( Friday, 23rd November, 2018) and will remain
> open for at-least 72 hours, Request all PMC members to give their vote.
> >
> > [ ] +1 Release this package as 1.1.0
> > [ ] +0 No Opinion
> > [ ] -1 Do not release this package because
> >
> > On the behalf of ServiceComb Team
> > Mohammad Asif Siddiqui
> >
>

Re: [VOTE] Release Apache ServiceComb Saga version 0.2.1

[wjm wjm]

+1 binding


Checks Done:
- release notes
- binaries and maven repos

DeanLee <82529...@qq.com> 于2018年11月24日周六 下午3:43写道：

> +1 non binding
>
>
>
>
> Checks List:
>
> - Signatures and hashes is ok
>
> - Able to run saga-spring-cloud-demo demo with the instruction from README
>
> - NOTICE/LICENSE is present
>
>
>
>
> Regards
>
> Dean Lee
>
> -- 原始邮件 --
> 发件人: "Mohammad Asif Siddiqui";
> 发送时间: 2018年11月24日(星期六) 中午1:06
> 收件人: "dev";
>
> 主题: Re: [VOTE] Release Apache ServiceComb Saga version 0.2.1
>
>
>
> Hi All,
>
> Thanks All for verifying and voting for this release, this vote is closed
> now and we will declare the results soon.
>
> Regards
> Asif
>
> On 2018/11/20 15:35:59, Mohammad Asif Siddiqui 
> wrote:
> > Hi All,
> >
> > This is a call for Vote to release Apache ServiceComb Saga version
> 0.2.1
> >
> > Release Notes :
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12344453
>
> >
> > Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-saga/0.2.1/rc-01/
> >
> > Staging Repository :
> https://repository.apache.org/content/repositories/orgapacheservicecomb-1346/
> >
> > Release Tag :
> https://github.com/apache/servicecomb-saga/releases/tag/0.2.1
> >
> > Release CommitID : 1484592d6fc84a33ffb7510969437ba448277e82
> >
> > Keys to verify the Release Candidate :
> https://dist.apache.org/repos/dist/dev/servicecomb/KEYS
> >
> > Voting will start now ( Tuesday, 20th November, 2018) and will remain
> open for at-least 72 hours, Request all PMC members to give their vote.
> >
> > [ ] +1 Release this package as 0.2.1
> > [ ] +0 No Opinion
> > [ ] -1 Do not release this package because
> >
> > On the behalf of ServiceComb Team
> > Mohammad Asif Siddiqui
> >

Re: Release of ServiceComb 1.1.0

[wjm wjm]

we can start release process between 11.19~11.23 for java chassis

Bin Ma  于2018年11月4日周日 上午12:13写道：

> OK,I will try to check the ServiceComb website first
>
>
> Best Wishes & Regards
> ---
> Mabin
>
>
>
> Willem Jiang  于2018年11月2日周五 上午8:30写道：
>
> > I already submit a JIRA and wait for infra's response.
> > But the document it's OK for us do the modification, please send a PR
> > if you have time to work on it.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Thu, Nov 1, 2018 at 8:24 PM Bin Ma  wrote:
> > >
> > > Hi all,
> > >
> > > Some community users plan to make courses based on ServiceComb in the
> > near
> > > future, like Itcast,University and so on.
> > > So I think it may be speed up the process of renaming the git repo name
> > and
> > > updating the documentation.
> > >
> > >
> > > Best Wishes & Regards
> > > ---
> > > Mabin
> > >
> > >
> > >
> > > Willem Jiang  于2018年10月29日周一 下午12:54写道：
> > >
> > > > FYI， I fill a JIRA[1] for renaming the git repo.
> > > >
> > > > [1]https://issues.apache.org/jira/browse/INFRA-17185
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > > > On Sat, Oct 27, 2018 at 10:09 PM Willem Jiang <
> willem.ji...@gmail.com>
> > > > wrote:
> > > > >
> > > > > Oh,  I just forgot the github name issue which we faced when moving
> > > > > the servicecomb to apache incubator.
> > > > > I will fill a JIRA this weekend, it may take few days to do the
> > > > > transfer. Once we changed the github name, we could consider the
> > > > > release of ServiceCenter.
> > > > >
> > > > > Willem Jiang
> > > > >
> > > > > Twitter: willemjiang
> > > > > Weibo: 姜宁willem
> > > > >
> > > > > On Sat, Oct 27, 2018 at 2:25 PM Mohammad Asif Siddiqui
> > > > >  wrote:
> > > > > >
> > > > > > Hi Willem,
> > > > > >
> > > > > > In my opinion since ServiceComb has already graduated so we can
> > change
> > > > the repository names first and migrate the SVN for the releases and
> > then
> > > > plan for the ServiceComb 1.1.0 release. In Service-Center after the
> > change
> > > > in the repository name we need to change the import statements of
> each
> > file
> > > > and also we need to update the Travis settings for each project and
> > make
> > > > new encryption keys for automatic snapshot deployment, for all these
> > > > activities it might take 2-3 days so we can plan this first in coming
> > week
> > > > and then we can go ahead with the Service-Center 1.1.0 release.
> > > > > >
> > > > > > Just my 2 cents..
> > > > > >
> > > > > > Regards
> > > > > > Asif
> > > > > >
> > > > > > On 2018/10/22 03:39:02, Willem Jiang 
> > wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > The last ServiceComb java-chassis，service-center 1.0.0 release
> is
> > > > > > > three month ago. It's time to discuss the release of
> ServiceComb
> > > > > > > 1.1.0.
> > > > > > >
> > > > > > > As we add the TCC implementation in the Saga 0.3.0, we may need
> > to
> > > > > > > create a separate git repo to support the Saga and TCC at the
> > same
> > > > > > > time.  It may take sometime to do these change. We may do the
> > Saga
> > > > > > > release after the release of java-chassis and service-center.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Willem Jiang
> > > > > > >
> > > > > > > Twitter: willemjiang
> > > > > > > Weibo: 姜宁willem
> > > > > > >
> > > >
> >
>

Re: [ANN] New ServiceComb committer: Yao Haishi (姚海石)

[wjm wjm]

Congratulation

Mohammad Asif Siddiqui  于2018年11月13日周二 下午4:19写道：

> Congratulations Yao Haishi
>
> Regards
> Asif
>
> On 2018/11/13 02:46:53, Willem Jiang  wrote:
> > Please join me and the rest of the ServiceComb PPMC members in welcoming
> our
> > new ServiceComb committer: Yao Haishi (姚海石).
> >
> > Yao Haishi contribute the ServiceComb more than a year, he is active
> > contributor on java-chassis, doc and the mailing list, and we look
> > forward to many more
> > contributions in the future.
> >
> > Congratulations to Yao Haishi ! Welcome!
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
>

Re: [Heads Up ]Git repository names are changed

[wjm wjm]

Great, thanks~

Zheng Feng  于2018年11月9日周五 上午10:43写道：

> Nice work ! I just open the PR to fix in the saga [1]
>
> [1] https://github.com/apache/servicecomb-saga/pull/332
>
> Willem Jiang  于2018年11月9日周五 上午10:02写道：
>
> > I did some clean up on java-chassis, saga, service-center README file
> > and removed the DISCLAIM file.
> > I also updated some documents of saga reference in the doc site.
> > There may still have some place need to updated.
> > Please check out the documents and feel free to submit fix for that.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Fri, Nov 9, 2018 at 8:59 AM Willem Jiang 
> > wrote:
> > >
> > > Hi Team,
> > >
> > > As part of way to the Apache TLP, we need to rename the github repo
> name.
> > > Now it's done.  Please let me know if something is broken.
> > > I just checked travis CI, it's OK. I'll update the status bage link
> > shortly.
> > >
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> >
>

Re: [DISCUSS]Discovery API support filter instances by properties

[wjm wjm]

infact, we already reduced query response size by 304 NOT MODIFIED
only intstances changed, then will send all instances for the query
microservice

for big cluster scenes, we can compress response body, i feel that's simple
and enough.

Zheng Feng  于2018年11月9日周五 上午10:50写道：

> So the question is how the server knows the differences with the client
> request from the last time ? there are snapshots in the SC with every
> instance status changes ?
>
> Yang Bo  于2018年11月9日周五 上午9:39写道：
>
> > How about add some patching mechanisms. The server only send information
> of
> > changed instances in the query response.
> >  This will drastically reduce the response size when only a few instances
> > changes in a huge cluster.
> >
> > On Fri, Nov 9, 2018 at 9:15 AM bismy  wrote:
> >
> > > I think we need take more considerations on how users use this API.
> > > According to what we have done, server side need to cache all query
> > > results. We can't just say 'We just let the client to find out what
> they
> > > want to know' and leave all things to users, because the most important
> > > part of instance management is how to keep data consistence both on
> > server
> > > side and client side.
> > >
> > >
> > > For this problem, I intend to agree with @zzzwjm. We didn't see any
> > > critical problem for the current solution to query all possible
> > instances.
> > > Maybe current solution will have problem with two conditions met: 1.
> > > instances is huge; 2. instances up/down very frequently. At this
> > > conditions, the provided solution seems not work very good too.
> > >
> > >
> > > -- 原始邮件 --
> > > 发件人: "willem.jiang";
> > > 发送时间: 2018年11月9日(星期五) 上午8:50
> > > 收件人: "dev";
> > >
> > > 主题: Re: [DISCUSS]Discovery API support filter instances by properties
> > >
> > >
> > >
> > > I think Sure is just want SC provide some filtering query on the
> > > server side, we don't need to let the server cached all the query
> > > result.
> > > We just let the client to find out what they want to know, server
> > > don't need to send all the data to the client unless the client wants
> > > them.
> > >
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Fri, Nov 9, 2018 at 5:47 AM wjm wjm  wrote:
> > > >
> > > > that will cause SC cache results by different query parameters, is it
> > too
> > > > heavy?
> > > >
> > > > even has 2k  instances  , but client query by data version, if not
> > > changed,
> > > > only response 304 NOT MODIFIED
> > > > if instances changed, and response size is big, then can response
> with
> > > > compress
> > > > so there is no problem?
> > > >
> > > > Sure  于2018年11月7日周三 下午11:36写道：
> > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-servicecomb-service-center/issues/482
> > > > >
> > > > > Hi guys,
> > > > >
> > > > > Our system has 20+ services, and each service has 2k instances at
> > most.
> > > > > All the instances are grouped by some labels(in Properties).
> > > > >
> > > > > We are now querying all the instances from SC, and then filtering
> > > them by
> > > > > labels on the client side. This wastes a lot of bandwidth and  has
> > poor
> > > > > performance. Can SC's API provide the filtering function?
> > > > >
> > > > > Thx.
> >
> >
> >
> > --
> > Best Regards,
> > Yang.
> >
>

Re: [DISCUSS]Discovery API support filter instances by properties

[wjm wjm]

@Sure
only send changed instances for each query, seems too difficult for SC,
right?

Yang Bo  于2018年11月9日周五 上午9:39写道：

> How about add some patching mechanisms. The server only send information of
> changed instances in the query response.
>  This will drastically reduce the response size when only a few instances
> changes in a huge cluster.
>
> On Fri, Nov 9, 2018 at 9:15 AM bismy  wrote:
>
> > I think we need take more considerations on how users use this API.
> > According to what we have done, server side need to cache all query
> > results. We can't just say 'We just let the client to find out what they
> > want to know' and leave all things to users, because the most important
> > part of instance management is how to keep data consistence both on
> server
> > side and client side.
> >
> >
> > For this problem, I intend to agree with @zzzwjm. We didn't see any
> > critical problem for the current solution to query all possible
> instances.
> > Maybe current solution will have problem with two conditions met: 1.
> > instances is huge; 2. instances up/down very frequently. At this
> > conditions, the provided solution seems not work very good too.
> >
> >
> > -- 原始邮件 --
> > 发件人: "willem.jiang";
> > 发送时间: 2018年11月9日(星期五) 上午8:50
> > 收件人: "dev";
> >
> > 主题: Re: [DISCUSS]Discovery API support filter instances by properties
> >
> >
> >
> > I think Sure is just want SC provide some filtering query on the
> > server side, we don't need to let the server cached all the query
> > result.
> > We just let the client to find out what they want to know, server
> > don't need to send all the data to the client unless the client wants
> > them.
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Fri, Nov 9, 2018 at 5:47 AM wjm wjm  wrote:
> > >
> > > that will cause SC cache results by different query parameters, is it
> too
> > > heavy?
> > >
> > > even has 2k  instances  , but client query by data version, if not
> > changed,
> > > only response 304 NOT MODIFIED
> > > if instances changed, and response size is big, then can response with
> > > compress
> > > so there is no problem?
> > >
> > > Sure  于2018年11月7日周三 下午11:36写道：
> > >
> > > >
> >
> https://github.com/apache/incubator-servicecomb-service-center/issues/482
> > > >
> > > > Hi guys,
> > > >
> > > > Our system has 20+ services, and each service has 2k instances at
> most.
> > > > All the instances are grouped by some labels(in Properties).
> > > >
> > > > We are now querying all the instances from SC, and then filtering
> > them by
> > > > labels on the client side. This wastes a lot of bandwidth and  has
> poor
> > > > performance. Can SC's API provide the filtering function?
> > > >
> > > > Thx.
>
>
>
> --
> Best Regards,
> Yang.
>

Re: [DISCUSS]Discovery API support filter instances by properties

[wjm wjm]

that will cause SC cache results by different query parameters, is it too
heavy?

even has 2k  instances  , but client query by data version, if not changed,
only response 304 NOT MODIFIED
if instances changed, and response size is big, then can response with
compress
so there is no problem?

Sure  于2018年11月7日周三 下午11:36写道：

> https://github.com/apache/incubator-servicecomb-service-center/issues/482
>
> Hi guys,
>
> Our system has 20+ services, and each service has 2k instances at most.
> All the instances are grouped by some labels(in Properties).
>
> We are now querying all the instances from SC, and then filtering  them by
> labels on the client side. This wastes a lot of bandwidth and  has poor
> performance. Can SC's API provide the filtering function?
>
> Thx.