Re: [VOTE]Release Apache ServiceComb Java Chassis version 2.8.18
+1 binding, I've checked maven build. Replied Message | From | liubao | | Date | 07/02/2024 16:27 | | To | dev@servicecomb.apache.org | | Cc | | | Subject | [VOTE]Release Apache ServiceComb Java Chassis version 2.8.18 | Hello All, This is a call for a Vote to release Apache ServiceComb Java Chassis version 2.8.18. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.18 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.8.18/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1559 Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.18 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( 2 July, 2024) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.8.18 [ ] +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 3.2.0
+1 binding. I've checked maven build. Replied Message | From | liubao | | Date | 07/02/2024 11:40 | | To | dev@servicecomb.apache.org | | Cc | | | Subject | [VOTE]Release Apache ServiceComb Java Chassis version 3.2.0 | Hello All, This is a call for a Vote to release Apache ServiceComb Java Chassis version 3.2.0. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/3.2.0 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/3.2.0/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1558 Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/3.2.0 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( 2 July, 2024) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 3.2.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 3.1.2
+1 binding. I've checked: - git tag seems ok, - mvn test build pass. Replied Message | From | ZhangJian He | | Date | 06/06/2024 09:13 | | To | dev@servicecomb.apache.org | | Cc | | | Subject | Re: [VOTE]Release Apache ServiceComb Java Chassis version 3.1.2 | +1 (binding) Thanks ZhangJian He Twitter: shoothzj Wechat: shoothzj On Thu, Jun 6, 2024 at 9:08 AM liubao wrote: > This my +1. > > > > > At 2024-06-04 15:40:22, "youling1128" wrote: > > >+1 (binding) > > > > > > > > > >At 2024-06-04 10:57:17, "liubao" wrote: > >>Hello All, > >> > >>This is a call for a Vote to release Apache ServiceComb Java Chassis > version 3.1.2. > >> > >>Release Notes : > https://github.com/apache/servicecomb-java-chassis/releases/tag/3.1.2 > >> > >>Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/3.1.2/ > >> > >>Staging Repo : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1556 > >> > >>Release Tag : > https://github.com/apache/servicecomb-java-chassis/releases/tag/3.1.2 > >> > >>Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > >> > >>Voting will start now ( 4 June, 2024) and will remain openfor at-least > 72 hours, Request all PMC members to give their vote. > >> > >>[ ] +1 Release this package as 3.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.8.14
+1, I have checked mvn building and git tag, and all seems OK. Replied Message | From | bismy | | Date | 12/18/2023 12:01 | | To | dev | | Cc | | | Subject | [VOTE] Release Apache ServiceComb Java-Chassis version 2.8.14 | Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.8.14. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.14 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.8.14/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1545/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.14 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Dec, 18 Mon, 2023) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.8.14 [ ] +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.8.13
+1, I have check the build and UT, and all seem OK. Replied Message | From | bismy | | Date | 11/14/2023 21:06 | | To | dev | | Cc | | | Subject | [VOTE] Release Apache ServiceComb Java-Chassis version 2.8.13 | Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.8.13. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.13 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.8.13/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1542/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.13 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Nov, 14 Tue, 2023) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.8.13 [ ] +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.8.12
+1 binding, the maven building and tag seems OK. Replied Message | From | bismy | | Date | 10/10/2023 20:22 | | To | dev | | Cc | | | Subject | [VOTE] Release Apache ServiceComb Java-Chassis version 2.8.12 | Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.8.12. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.12 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.8.12/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1539/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.12 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Oct, 10 Tue, 2023) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.8.12 [ ] +0 No Opinion [ ] -1 Do not release this package because On the behalf of ServiceComb Team Liu Bao
回复：[VOTE] Release Apache ServiceComb Java-Chassis version 2.8.9 (RC2)
+1 binding, I have checked, 1. the maven building is OK, 2. git tag seems OK. 回复的原邮件 | 发件人 | Willem Jiang | | 日期 | 2023年06月23日 19:58 | | 收件人 | dev@servicecomb.apache.org | | 抄送至 | | | 主题 | Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.8.9 (RC2) | +1 (binding) Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Wed, Jun 21, 2023 at 3:40 PM bismy wrote: > > Hello All, > > This is a call for a Vote to release Apache ServiceComb Java-Chassis version > 2.8.9. > > Release Notes : > https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.9 > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.8.9/ > > Staging Repo : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1536/ > > Release Tag : > https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.9 > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now ( Tue, 21 June, 2023) and will remain openfor at-least > 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 2.8.9 > [ ] +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.8.8
+1 binding, I have checked, maven build seems OK, git tag seems OK. Replied Message | From | bismy | | Date | 05/25/2023 17:22 | | To | dev | | Cc | | | Subject | [VOTE] Release Apache ServiceComb Java-Chassis version 2.8.8 | Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.8.8. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.8 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.8.8/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1534/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.8 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Tue, 25 May, 2023) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.8.8 [ ] +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.8.7
+1 I have checked, - maven build is OK, - git tag seems OK Replied Message | From | ZhangJian He | | Date | 05/07/2023 12:56 | | To | dev@servicecomb.apache.org | | Cc | | | Subject | Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.8.7 | +1. I have done check tags, run unit tests on my laptop. Thanks ZhangJian He On Sat, 6 May 2023 at 21:36, bismy wrote: > Hello All, > > This is a call for a Vote to release Apache ServiceComb Java-Chassis > version 2.8.7. > > Release Notes : > https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.7 > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.8.7/ > > Staging Repo : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1532/ > > Release Tag : > https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.7 > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now ( Tue, 6 May, 2023) and will remain openfor at-least > 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 2.8.7 > [ ] +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.8.7
+1 I have checked - maven build is OK, - git tag seems OK Replied Message | From | bismy | | Date | 05/06/2023 21:35 | | To | dev | | Cc | | | Subject | [VOTE] Release Apache ServiceComb Java-Chassis version 2.8.7 | Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.8.7. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.7 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.8.7/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1532/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.7 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Tue, 6 May, 2023) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.8.7 [ ] +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.8.5
+1 binding, I've checked, maven building and tests passed, git tag seems OK. Replied Message | From | ZhangJian He | | Date | 02/02/2023 14:18 | | To | dev@servicecomb.apache.org | | Cc | | | Subject | Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.8.5 | +1 non-binding Thanks ZhangJian He On Thu, 2 Feb 2023 at 12:06, Yihua Cui wrote: > +1 binding > > On 2023/01/30 08:17:15 bismy wrote: > > Hello All, > > > > This is a call for a Vote to release Apache ServiceComb Java-Chassis > version 2.8.5. > > > > Release Notes : > https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.5 > > > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.8.5/ > > > > Staging Repo : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1526/ > > > > Release Tag : > https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.5 > > > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > > > Voting will start now ( Mon, 20 Jan, 2023) and will remain openfor > at-least 72 hours, Request all PMC members to give their vote. > > > > [ ] +1 Release this package as 2.8.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 2.8.4
+1 binding. I have checked, the mvn build and tests are OK, the tag seems OK Replied Message | From | bismy | | Date | 12/28/2022 18:08 | | To | dev | | Cc | | | Subject | [VOTE] Release Apache ServiceComb Java-Chassis version 2.8.4 | Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.8.4. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.4 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.8.4/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1524/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.4 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Wen, 28 Dec, 2022) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.8.4 [ ] +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.8.2
+1 binding, I've checked the git tag, maven building and tests Replied Message | From | bismy | | Date | 11/05/2022 15:31 | | To | dev | | Cc | | | Subject | [VOTE] Release Apache ServiceComb Java-Chassis version 2.8.2 | Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.8.2. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.2 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.8.2/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1522/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.2 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Sat, 5 Nov, 2022) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.8.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 1.3.10
+1 binding, I've checked the git tag, maven building and tests Replied Message | From | bismy | | Date | 11/05/2022 10:44 | | To | dev | | Cc | | | Subject | [VOTE] Release Apache ServiceComb Java-Chassis version 1.3.10 | Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 1.3.10. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/1.3.10 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.3.10/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1521/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/1.3.10 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Sat, 5 Nov, 2022) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 1.3.10 [ ] +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.8.1
+1 binding, I have checked, the maven build and tests have passed, and the git tag seems OK. Replied Message | From | bismy | | Date | 10/23/2022 12:22 | | To | dev | | Cc | | | Subject | [VOTE] Release Apache ServiceComb Java-Chassis version 2.8.1 | Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.8.1. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.1 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.8.1/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1520/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.1 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Oct, 23 Apr, 2022) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.8.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 1.3.9
+1 binding, I've checked, maven build and tests have passed, the git tag seems OK. Replied Message | From | bismy | | Date | 09/29/2022 21:03 | | To | dev | | Cc | | | Subject | [VOTE] Release Apache ServiceComb Java-Chassis version 1.3.9 | Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 1.3.9. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/1.3.9 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.3.9/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1519/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/1.3.9 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Sep, 29 Apr, 2022) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 1.3.9 [ ] +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.8.0
+1 binding, I've checked, maven build and tests have passed, git tag seems OK. Replied Message | From | bismy | | Date | 09/29/2022 20:14 | | To | dev | | Cc | | | Subject | [VOTE] Release Apache ServiceComb Java-Chassis version 2.8.0 | Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.8.0. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.0 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.8.0/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1518/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.8.0 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Sep, 29 Apr, 2022) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.8.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.7.10
+1 binding, I have checked, maven build and tests have passed, tag and commitId seems OK Replied Message | From | bismy | | Date | 09/13/2022 17:51 | | To | dev | | Cc | | | Subject | [VOTE] Release Apache ServiceComb Java-Chassis version 2.7.10 | Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.7.10. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.7.10 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.7.10/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1516/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.7.10 Keys to verify the Release Candidate :https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Sep, 13 Apr, 2022) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.7.10 [ ] +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.8
+1 binding， I have checked, maven build and test pass, commit and tag seems OK Replied Message | From | bismy | | Date | 08/30/2022 16:53 | | To | dev | | Cc | | | Subject | [VOTE] Release Apache ServiceComb Java-Chassis version 1.3.8 | Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 1.3.8. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/1.3.8 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.3.8/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1514/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/1.3.8 Keys to verify the Release Candidate :https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Aug, 30 Apr, 2022) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 1.3.8 [ ] +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.7.9
+1 binding, I have checked, 1. maven build and test passed, 2. tag seems OK. Replied Message | From | bismy | | Date | 08/27/2022 23:47 | | To | dev | | Cc | | | Subject | [VOTE] Release Apache ServiceComb Java-Chassis version 2.7.9 | Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.7.9. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.7.9 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.7.9/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1513/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.7.9 Keys to verify the Release Candidate :https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Aug, 27 Apr, 2022) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.7.9 [ ] +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.7.8
+1 binding I have checked: - build is OK and tests passed, - tag and release notes seems OK, - commitId matches. Replied Message | From | bismy | | Date | 08/11/2022 23:36 | | To | dev | | Cc | | | Subject | Re:[VOTE] Release Apache ServiceComb Java-Chassis version 2.7.8 | This is my +1 -- Original -- From: "bismy" ; Date: Wed, Aug 10, 2022 11:30 PM To: "dev"; Subject: [VOTE] Release Apache ServiceComb Java-Chassis version 2.7.8 Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.7.8. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.7.8 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.7.8/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1510/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.7.8 Keys to verify the Release Candidate :https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Aug, 10 Apr, 2022) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.7.8 [ ] +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.7.4
+1 binding tag and release notes seems OK, commitId matches. Replied Message | From | Jimin Wu | | Date | 06/10/2022 09:40 | | To | dev@servicecomb.apache.org | | Cc | | | Subject | Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.7.4 | +1 binding
Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.7.1
+1 bind I've checked maven build and integration tests. | ?? | bismy | | | 2022??04??16?? 14:57 | | ?? | dev | | ?? | | | | ?? [VOTE] Release Apache ServiceComb Java-Chassis version 2.7.1 | This is my +1. -- -- ??: "dev" ; : 2022??4??16??(??) 11:39 ??: "dev"; : Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.7.1 +1 ??binding?? I checked the source and git tag. The staging repo looks good to me. Willem Jiang Twitter: willemjiang Weibo: willem On Wed, Apr 13, 2022 at 12:09 PM bismy wrote: Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.7.1. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.7.1 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.7.1/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1484/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.7.1 Keys to verify the Release Candidate :https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Wed, 13 Apr, 2022) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.7.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.7.0
+1 binding I have checked maven build and integration test, and it seems Okay. 回复的原邮件 | 发件人 | bismy | | 日期 | 2022年04月02日 18:27 | | 收件人 | dev | | 抄送至 | | | 主题 | [VOTE] Release Apache ServiceComb Java-Chassis version 2.7.0 | Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.7.0. Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.7.0 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.7.0/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1483/ Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.7.0 Keys to verify the Release Candidate :https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Sat, 2 Apr, 2022) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.7.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.6.3
+1 binding I have checked, 1, git tag and commit id match 2, mvn clean install -Pit is OK 回复的原邮件 | 发件人 | Willem Jiang | | 日期 | 2022年03月16日 14:50 | | 收件人 | dev | | 抄送至 | | | 主题 | Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.6.3 | +1 （binding） Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Mon, Mar 14, 2022 at 9:52 PM bismy wrote: > > Add: > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.6.3/ > > -- 原始邮件 -- > 发件人: "dev" ; > 发送时间: 2022年3月14日(星期一) 中午11:28 > 收件人: "dev"; > 主题: Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.6.3 > > Hi Liu Bao, > > We need to put the source kit[1] into the apache release repo for the vote. > > [1]https://repository.apache.org/content/repositories/orgapacheservicecomb-1480/org/apache/servicecomb/apache-servicecomb-java-chassis-distribution/2.6.3/apache-servicecomb-java-chassis-distribution-2.6.3-src.zip > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Fri, Mar 11, 2022 at 2:18 PM bismy wrote: > > Hello All, > > This is a call for a Vote to release Apache ServiceComb Java-Chassis > version 2.6.3. > > This is a patch version for 2.6.0, and release notes will be updated in > 2.7.0. > > Release Notes : > https://github.com/apache/servicecomb-java-chassis/releases/tag/2.6.3 > > Release Candidate : Deploy to Maven only > > Staging Repo : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1480 > > Release Tag : > https://github.com/apache/servicecomb-java-chassis/releases/tag/2.6.3 > > Keys to verify the Release Candidate > :https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now ( Fri, 11 May, 2022) and will remain openfor > at-least 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 2.6.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.7
+1 binding I've checked, 1. mvn clean install -Pit is OK 2. tag matches commit id 回复的原邮件 | 发件人 | Willem Jiang | | 日期 | 2022年03月16日 14:51 | | 收件人 | dev | | 抄送至 | | | 主题 | Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.3.7 | +1 （binding） Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Mon, Mar 14, 2022 at 9:52 PM bismy wrote: > > add Release Candidate : > > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/1.3.7/ > > -- 原始邮件 -- > 发件人: "dev" ; > 发送时间: 2022年3月14日(星期一) 中午11:32 > 收件人: "dev"; > 主题: Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.3.7 > > In the ASF release, we are mainly voting for the source kit, and we > need to put the source into the ASF release download system. > Git tag is not an official release. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Mon, Mar 14, 2022 at 11:28 AM bismy wrote: > > Source can be got from tag: > https://github.com/apache/servicecomb-java-chassis/releases/tag/1.3.7 > > -- 原始邮件 -- > 发件人: "dev" ; > 发送时间: 2022年3月14日(星期一) 中午11:25 > 收件人: "dev"; > 主题: Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.3.7 > > We need to release the source kit to ServiceComb download for the user > to build the source from kit. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Fri, Mar 11, 2022 at 5:22 PM bismy wrote: > > Hello All, > > This is a call for a Vote to release Apache ServiceComb > Java-Chassis version 1.3.7. > > This is a patch version for 1.3.6. > > Release Notes : > https://github.com/apache/servicecomb-java-chassis/releases/tag/1.3.7 > > Release Candidate : Deploy to Maven only > > Staging Repo : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1481 > > Release Tag : > https://github.com/apache/servicecomb-java-chassis/releases/tag/1.3.7 > > Keys to verify the Release Candidate > :https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now ( Fri, 11 May, 2022) and will remain openfor > at-least 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 1.3.7 > [ ] +0 No Opinion > [ ] -1 Do not release this package because > > On the behalf of ServiceComb Team > > Liu > Bao
Re: new committer: Yasheng Tang
Welcome aboard! Congratulations! | | yhs0092 | | 邮箱：yhs0...@163.com | 签名由 网易邮箱大师 定制 On 02/15/2022 18:57, Sure wrote: The Project Management Committee (PMC) for Apache ServiceComb has invited Yasheng Tang[1] to become a committer and we are pleased to announce that he has accepted. [1] https://github.com/aseTo2016 Being a committer enables easier contribution to the project since there is no need to go via the patch submission process. This should enable better productivity. A PMC member helps manage and guide the direction of the project.
Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.6.0
+1 binding I have checked, 1. local build is OK 2. sha512sum and gpg signature is OK 3. src package contents comparing to github repo is OK | | yhs0092 | | 邮箱：yhs0...@163.com | 签名由 网易邮箱大师 定制 On 11/25/2021 14:46, bismy wrote: Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.6.0. Release Notes : https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12350513 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.6.0/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1477 Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.6.0 Keys to verify the Release Candidate :https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Sat, 18 Sep, 2021) and will remain openfor at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 2.6.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.5.0
+1 binding I have checked, local build is OK, tag and commitId is OK. Yours sincerely Yao Haishi yhs0...@163.com On 08/17/2021 20:48, bismy wrote: Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.5.0 Release Notes : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.5.0 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.5.0/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1471 Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.5.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.5.0 [ ] +0 No Opinion [ ] -1 Do not release this package because On the behalf of ServiceComb Team Liu Bao | | yhs0092 | | 邮箱：yhs0...@163.com | 签名由 网易邮箱大师 定制
Re:[VOTE] Release Apache ServiceComb Kie version 0.2.0
+1 I've checked, 1. the release candidate's sha512 checksum 2. commit id and tag 3. release notes it seems fine for me Yours sincerely Yao Haishi yhs0...@163.com At 2021-02-18 16:46:59, "Xiaoliang Tian" wrote: >Hi All, > > This is a call for Vote to release Apache ServiceComb Kie version 0.2.0 > >Release Candidate : >https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-kie/0.2.0/rc-01/ > > > >Release Tag : >https://github.com/apache/servicecomb-kie/releases/tag/v0.2.0 > >Release CommitID: 9e411a8e25e0c1bcf14ae2eb6980afe06065e926 > >Release Notes : >https://github.com/apache/servicecomb-kie/releases/tag/v0.2.0 > > Keys to verify the Release Candidate : >https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > >Voting will start now ( 18nd Feb, 2021) and will remain open > for at-least 72 hours, Request all PMC members to give their vote. > >[ ] +1 Release this package as 0.2.0 >[ ] +0 No Opinion >[ ] -1 Do not release this package because > > On the behalf of ServiceComb Team > > >Best Wishes & Regards
Re:[VOTE] Release Apache ServiceComb Java-Chassis version 2.1.3
+1 binding I have checked, local build is OK, tag and commitId is OK. Yours sincerely Yao Haishi yhs0...@163.com At 2020-11-27 17:10:16, "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 2.1.1
+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:Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.1.0
+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: [VOTE] Release Apache ServiceComb Java-Chassis version 2.0.2
+1 binding I have checked, 1. Release commit id and Tag are good. 2. mvn clean install -Pit build is good. Yours sincerely Yao Haishi yhs0...@163.com On 5/11/2020 07:49，Willem Jiang wrote： +1. （Binding) Here are my checked, 1. Signature and Hashed are good. 2. Release commit and Tag are good. 3. LICENSE and NOTICE file are good for me. 4. I can build the binary from Source release kit. We may need more people check if the demos are OK. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Fri, May 8, 2020 at 5:55 PM bismy wrote: Hello All, This is a call for a Vote to release Apache ServiceComb Java-Chassis version 2.0.2 Release Notes : https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12347818 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.0.2/rc-1/ Staging Repo : https://repository.apache.org/content/repositories/orgapacheservicecomb-1439 Release Tag : https://github.com/apache/servicecomb-java-chassis/releases/tag/2.0.2 Release CommitID : 8c0c3322f13cff6ec185ad981f8732bc83e6e53e 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: [Announce] New committer of ServiceComb
Congratulations! Welcome! Yours sincerely Yao Haishi yhs0...@163.com On 5/11/2020 17:28，victor chan wrote： Congratulations！ Wishes & Regards --- Chenzhu Xiaoliang Tian 于2020年5月11日周一 下午4:42写道： welcome Daniel Qian 于 2020年5月10日周日 10:24写道： Congrats and welcome! Willem Jiang 于2020年5月9日周六 下午6:39写道： Hi, I want to introduce humingcheng (Github ID: humingcheng[1]) as a new committer of ServiceComb. He is one of the main author of servicecomb-mesher and has been around the ServiceComb almost a year by contributing patches for servicecomb-service-center, servicecomb-mesher and servicecomb-kie. Welcome humingcheng :) [1]http://github.com/humingcheng Willem Jiang Twitter: willemjiang Weibo: 姜宁willem -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.0.0
+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
Re: [VOTE] Release Apache ServiceComb Toolkit version 0.2.0 [RC2]
+1 binding I checked, + git tag and the commit id are matched + release candidates and the checksum files are OK + building from the source files is OK Yours sincerely Yao Haishi yhs0...@163.com On 12/31/2019 18:18，sen sun wrote： Hi All, This is a call for Vote to release Apache ServiceComb Toolkit version 0.2.0 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-toolkit/0.2.0/rc-02/ Staging Repository : https://repository.apache.org/content/repositories/orgapacheservicecomb-1411 Release Tag : https://github.com/apache/servicecomb-toolkit/releases/tag/0.2.0 Release CommitID : da3b3b6333e1c776d4e39513e39e328596d9b40f Release Notes : https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12346158 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Tuesday, 31nd Dec, 2019) and will remain open for at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 0.2.0 [ ] +0 No Opinion [ ] -1 Do not release this package because On the behalf of ServiceComb Team Best Wishes & Regards
回复：[ANN] New ServiceComb committer:Sun Lisen(孙丽森)
Congratulations! Welcome! Yours sincerely Yao Haishi yhs0...@163.com 在2019年12月23日 14:32，Bin Ma 写道： Please join me and the rest of the ServiceComb PMC members in welcoming our new ServiceComb committer: Sun Lisen(孙丽森). Sun Lisen has been around the ServiceComb almost a year by contributing patches for servicecomb-toolkit, servicecomb-java-chassis,servicecomb-website and discussion techniques issue in the mailing list. Recently he contributed key features such as OAIV3 and SpringCloud to servicecomb-toolkit and commit on it frequently. Congratulations to Sun Lisen! Welcome! The Apache ServiceComb PMC.
Re: [DISCUSS][JavaChassis] Specify a way to generate java.time.Clock
Hi, maybe use Clock.systemDefaultZone() is okay? Users will specify the JVM timezone if necessary. Yours sincerely Yao Haishi yhs0...@163.com On 12/12/2019 16:50??Ang Li wrote?? Hi Team, I am currently solving issue [SBC-1559](https://issues.apache.org/jira/browse/SCB-1559). The core idea of this issue is using java.time.Clock instead ofjava.lang.System#currentTimeMillis to get time for mocking purpose. java.time.Clock provides many different ways to generate a clock. I am wondering which one should we use and do we need to specify a zone? Thanks a lot if someone can help. -- Ang Li
Re: [VOTE] Release Apache ServiceComb Toolkit version 0.2.0
Hello, I find that the `mvn clean install` build is not OK in my development environment. I use a Windows computer to run it. Here is the error log: ``` [INFO] Running org.apache.servicecomb.toolkit.cli.CliTest [ERROR] Tests run: 6, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 2.884 s <<< FAILURE! - in org.apache.servicecomb.toolkit.cli.CliTest [ERROR] testGenerateServiceCombCodeFromSingleContract(org.apache.servicecomb.toolkit.cli.CliTest) Time elapsed: 0.834 s <<< FAILURE! java.lang.AssertionError at org.apache.servicecomb.toolkit.cli.CliTest.lambda$testGenerateServiceCombCodeFromSingleContract$0(CliTest.java:54) at org.apache.servicecomb.toolkit.cli.CliTest.testGenerateServiceCombCodeFromSingleContract(CliTest.java:36) [ERROR] testGenerateCodeFromMultiContract(org.apache.servicecomb.toolkit.cli.CliTest) Time elapsed: 0.602 s <<< FAILURE! java.lang.AssertionError at org.apache.servicecomb.toolkit.cli.CliTest.testGenerateCodeFromMultiContract(CliTest.java:89) [INFO] [INFO] Results: [INFO] [ERROR] Failures: [ERROR] CliTest.testGenerateCodeFromMultiContract:89 [ERROR] CliTest.testGenerateServiceCombCodeFromSingleContract:36->lambda$testGenerateServiceCombCodeFromSingleContract$0:54 [INFO] [ERROR] Tests run: 6, Failures: 2, Errors: 0, Skipped: 0 ``` Yours sincerely Yao Haishi yhs0...@163.com On 12/6/2019 09:09，Bin Ma wrote： Hi All, This is a call for Vote to release Apache ServiceComb Toolkit version 0.2.0 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-toolkit/0.2.0/rc-01/ Staging Repository : https://repository.apache.org/content/repositories/orgapacheservicecomb-1409 Release Tag : https://github.com/apache/servicecomb-toolkit/releases/tag/0.2.0 Release CommitID : e95ba3c7b27673ee4e360d64cc1ccce43f70f18e Release Notes : https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12346158 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Friday, 6nd Dec, 2019) and will remain open for at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 0.2.0 [ ] +0 No Opinion [ ] -1 Do not release this package because On the behalf of ServiceComb Team Wishes & Regards --- Mabin
Fw: [DISCUSSION] Rsocket
This is the content of the mail "[DISCUSSION] Rsocket is hot now" from gylgeek . There seems some problem with his mailbox : ) Yours sincerely Yao Haishi yhs0...@163.com - Forwarded Message - From： gylg...@gmail.com Date： 12/4/2019 17:50 To： Subject： [DISCUSSION] Rsocket RSocket is a binary protocol for use on byte stream transports such as TCP, WebSockets, and Aeron. It enables the following symmetric interaction models via async message passing over a single connection: request/response (stream of 1) request/stream (finite stream of many) fire-and-forget (no response) event subscription (infinite stream of many) Learn more at: http://rsocket.io https://github.com/rsocket/rsocket-java Dubbo and SpringCloud already support Rsocket, and take Rsocketas a future development trend. In spring 5, spring marks asynchronous interfaces such as asyncRestTemplate as @Deprecated , instead to recommend webflux(based on Rsocket). Dubbo 3.0.0-snapshot also supports responsive programming based on Rsocket. Reactive should consist of two parts: asynchronous functional programming and streaming programming. But service-comb don't have streaming programming. Rsocket can also be used in service mesh. Learn more at: https://www.netifi.com/solutions-servicemesh Best regards, Guo YongLiang.
??????????: [DISCUSSION]remove spring 4 & spring boot 1 support for servicecomb-java-chassis 2.0
+1 for removing spring 4 and springboot 1 from java-chassis 2.0. And I think they should still be kept in java-chassis 1. By the way, when do we checkout the java-chassis 1.x branch? As Liubao mentioned the 1.x branch is the maintenance branch for java-chassis 1, but I cannot find this one in the branch list of the code repo[1] [1] https://github.com/apache/servicecomb-java-chassis Yours sincerely Yao Haishi yhs0...@163.com ??2019??11??27?? 09:54??Ang Li ?? It's a good idea to use one DM in java chassis, which will make the dependency tree much clearer. But I still have another question. Besides modules provided for spring 4 and springboot 1, java chassis also uses spring 4 directly. In spring 5, many classes, interfaces and methods in spring-web package which used by java chassis is deprecated. Spring webflux is suggested instead. Do we have any plan to upgrade spring 4 to spring 5 in java chassis? If so, how to deal with the deprecated usages? Ang Li --Original-- From:"Liubao (A)"mailto:willem.ji...@gmail.com] : 2019??11??26?? 17:48 ??: dev https://spring.io/blog/2019/08/06/it-is-time-goodbye-spring-boot-1-x), start from servicecomb-java-chassis 2.0, we are going to remove all modules provided for spring 4 spring boot 1. Some details information: 1. remove all dependencies management: remove java-chassis-dependencies-spring4, java-chassis-dependencies-spring4, java-chassis-dependencies-spring-boot1, java-chassis-dependencies-boot2, and all of them are combined into one java-chassis-dependencies. 2. remove all starters for spring boot 1, includes spring-boot-starter-discovery, spring-boot-starter-registry, spring-boot-starter-provider, spring-boot-starter-transports, spring-boot-starter-zuul, spring-boot-starter-zuul-zipkin, etc. In the future, we only provide spring-boot2 starters. Generally, we only keep spring-boot2-starter-standalone, spring-boot2-starter-servlet, and these two modules will renamed according to spring-boot conventions. Other starters will become [spring cloud huawei](https://github.com/huaweicloud/spring-cloud-huawei). Servicecomb-java-chassis will focus on it's main features. Any suggestions?
回复：[ANN] New ServiceComb committer: Daniel Qian (钱嘉）
Congratulations! Welcome! Yours sincerely Yao Haishi yhs0...@163.com 在2019年11月8日 08:02，Willem Jiang 写道： Please join me and the rest of the ServiceComb PMC members in welcoming our new ServiceComb committer: Daniel Qian (钱嘉） Daniel Qian has been around the ServiceComb for more than one years by contributing patches to servicecomb-pack and discussion techniques issue in the mailing list. Recently he just contributed the osa-validator tool to ServiceComb. Congratulations to Daniel Qian! Welcome! The Apache ServiceComb PMC.
Re: [DISCUSSION] Optimize code implementations in ServiceComb-Java-Chassis
That's great! Thank you for your contribution. Yours sincerely Yao Haishi yhs0...@163.com On 10/17/2019 15:22，Ang Li wrote： Hi Team: I found some code implementations need to be optimized in servicecomb-java-chassis and created a jira issue to track: https://issues.apache.org/jira/projects/SCB/issues/SCB-1528 All the optimizations are some small points about efficiency, readability, reliability and maintainability. Just to make code implementations more graceful. Comments are welcome to be added to the jira issue [SCB-1528] and I will do the optimization work.
Re: [VOTE] Accept oas-validator to ServiceComb
+1 Great work! Yours sincerely Yao Haishi yhs0...@163.com On 10/15/2019 16:59??Ang Li wrote?? +1 Sounds Great! --Original-- From:"Willem Jiang"https://lists.apache.org/thread.html/3fc8dae6faa2055dd59d600c9da8508360766ec361d81ec0ceefa8db@%3Cdev.servicecomb.apache.org%3E Willem Jiang Twitter: willemjiang Weibo: willem
Re: [VOTE] Release Apache ServiceComb Mesher version 1.6.3
+1 On 09/06/2019 18:23, Willem Jiang wrote: +1 (binding) Checked the signed key and sh512. License and NOTICE files look good to me. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Fri, Sep 6, 2019 at 2:46 PM Xiaoliang Tian wrote: > > Hi All, > > This is a call for Vote to release Apache ServiceComb Mesher version 1.6.3 > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-mesher/1.6.3/rc-02/ > > > > Release Tag : > https://github.com/apache/servicecomb-mesher/tree/v1.6.3 > > Release CommitID: c6a5e8af27470842a138da276c20223b31ab19bc > > Release Notes : > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12346107 > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now ( Friday, 6nd September, 2019) and will remain open > for at-least 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 1.6.3 > [ ] +0 No Opinion > [ ] -1 Do not release this package because > > On the behalf of ServiceComb Team > > > Best Wishes & Regards > Xiaoliang Tian | | yhs0092 | | 邮箱：yhs0...@163.com | 签名由 网易邮箱大师 定制
Re: [VOTE] Release Apache ServiceComb Mesher version 1.6.3
+1 Yours sincerely Yao Haishi yhs0...@163.com On 9/5/2019 01:33，victor chan wrote： +1 Liubao (A) 于 2019年9月4日周三 下午11:49写道： +1 -邮件原件- 发件人: Xiaoliang Tian [mailto:xiaoliang.t...@gmail.com] 发送时间: 2019年9月3日 19:27 收件人: dev 主题: [VOTE] Release Apache ServiceComb Mesher version 1.6.3 Hi All, This is a call for Vote to release Apache ServiceComb Mesher version 1.6.3 Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-mesher/1.6.3/rc-01/ Release Tag : https://github.com/apache/servicecomb-mesher/tree/v1.6.3 Release CommitID : 683ad1ee9a6d7e739146278d4173615913a7e81e Release Notes : https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12346107 Keys to verify the Release Candidate : https://dist.apache.org/repos/dist/dev/servicecomb/KEYS Voting will start now ( Tuesday, 27nd August, 2019) and will remain open for at-least 72 hours, Request all PMC members to give their vote. [ ] +1 Release this package as 0.1.0 [ ] +0 No Opinion [ ] -1 Do not release this package because On the behalf of ServiceComb Team Best Wishes & Regards
Re: [DISSCUSSIOIN] Adding 'Issues' module for servicecomb-fence and other
+1. Agree to enable the issue feature. Yours sincerely Yao Haishi yhs0...@163.com On 8/5/2019 21:08，Willem Jiang wrote： I agree it could easy for the user to repo the bug or ask questions through issue. I think we can enable the issue feature of fence, toolkit, mesher, toolkit, by default. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Mon, Aug 5, 2019 at 6:44 PM Liubao (A) wrote: Hi Team, Recently, some servicecomb-fence users found not possible to ask questions in project "Issues" module. Although we recommend users to ask questions through JIRA, but it is not convenient and sometimes JIRA is very slow and can't be accessed. I suggest open "Issues" module for every servicecomb projects. Any suggestions? Servicecomb-fence : no servicecomb-java-chassis: yes servicecomb-service-center: yes servicecomb-pack: yes servicecomb-website: no servicecomb-mesher: yes servicecomb-docs: no servicecomb-samples: no servicecomb-toolkit: no servicecomb-kie : no
回复： [ANN] New ServiceComb committer:Ma Bin(马彬)
Congratulations! : ) Yours sincerely Yao Haishi yhs0...@163.com 在2019年8月3日 18:50，Bin Ma 写道： Thanks, very glad to be an Apache ServiceComb committer and grow with the ServiceComb community together Best Wishes & Regards --- Mabin victor chan 于2019年8月2日周五 下午4:01写道： Congratulations！ victor chan 邮箱：victorchan...@gmail.com 签名由 网易邮箱大师 定制 在2019年08月02日 15:54，Zen Lin 写道： Please join me and the rest of the ServiceComb PMC members in welcoming our new ServiceComb committer: Ma Bin(马彬). Ma Bin has been doing contribution in the ServiceComb community for more than two years, include three parts, a. Contributed ServiceComb code, include code in java-chassis, saga and website, Recently donate his servicecomb-toolkit[2] to servicecomb and commit on it frequently. b. Introduced ServiceComb to our first batch of users and support them to use it. c. Did Speeches to promote the ServiceComb more than 30 times in many different places. Congratulations to Tian Xiaoliang! Welcome! The Apache ServiceComb PMC.
Re: [DISCUSSION] About the static check for the source code of ServiceComb-Java-Chassis
Yes, it's not so urgent. I'll wait until the weak-type branch get merged. Yours sincerely Yao Haishi yhs0...@163.com On 7/7/2019 20:37，wjm wjm wrote： 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
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
[DISCUSSION] About the static check for the source code of ServiceComb-Java-Chassis
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
+1 Yours sincerely Yao Haishi yhs0...@163.com On 6/21/2019 21:54，Willem Jiang wrote： +1. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Fri, Jun 21, 2019 at 4:41 PM Xiaoliang Tian wrote: 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: [PROPOSAL]a new project mesher for servicecomb
+1 Great work. This will make ServiceComb a cross-language microservice solution. Yours sincerely Yao Haishi yhs0...@163.com On 6/11/2019 10:31，Bin Ma wrote： +1 I'm glad to hear this. I think that the Mesher can be used as a multi-language sub-project or component, and provide a unified user interface for service registration and discovery, governance, configuration to users.So that ServiceComb can form a more diversified solution, bringing multi-optional microservice solution to users with different scenarios and requirement. Best Wishes & Regards --- Mabin Mohammad Asif Siddiqui 于2019年6月11日周二 上午9:49写道： +1 I strongly suggest to add Mesher as a part of ServiceComb as it will make ServiceComb a fully fledged microservice framework with support to all languages by either java-chassis or by mesher. Regards Asif On 2019/06/10 06:11:01, Xiaoliang Tian wrote: Hi All, Service mesh is a solution for microservice, mesher is a service mesh implementation. if servicecomb introduce mesher, it will get some benifits. 1. user of servicecomb can choose any language and leverage same service center and govenance policy. 2. user can gain better performance by using java chassis and mesher, than user use service mesh solution only. the first one is most important reason why service mesh is important to service comb The mesher feature has been finished [1] there is the list of features: 1. service discovery, load balancing, circuit breaker, rate limiting, most of features that java chassis has 2. An admin API to expose runtime imformation of mesher 3. support grpc and http1 and http2 4. support transparent TLS communication 5. run as a sidecar proxy for a service 6. a sidecar injector to automattically inject mesher into k8s pod [1] https://github.com/go-mesh/mesher Regards
Re: [VOTE]Have a booth and Holding an Apache ServiceComb Meetup as a Co-located Event, in KubeCon & CloudNativeCon Summit China 2019
+1 Yours sincerely Yao Haishi yhs0...@163.com On 6/11/2019 09:52，Zen Lin wrote： Hi All, This is a call for Vote to have a Apache ServiceComb booth and hold an Apache ServiceComb Meetup as a Co-located Event , in KubeCon & CloudNativeCon Summit China 2019, as discussed in the proposal [1]. Voting will start now (Tuesday, 11th June, 2019) and will remain open for at-least 72 hours, Request PMC members and contributors to give their vote. [ ] +1 Accept [ ] +0 No Opinion [ ] -1 Reject because... [1] http://mail-archives.apache.org/mod_mbox/servicecomb-dev/201906.mbox/%3CCAH9eK8QEtrgPF9jqwZO%2BKRk9gEMd_U2DYMe2wAgBC30gD-Sc%2Bg%40mail.gmail.com%3E Best Regards, --- Zen Lin zenlintechnofr...@gmail.com Focused on Micro Service and Apache ServiceComb
Re: Proposal for Holding an Apache ServiceComb Meetup as a Co-located Event in KubeCon & CloudNativeCon Summit China 2019
+1 Yours sincerely Yao Haishi yhs0...@163.com On 6/10/2019 16:02，Zheng Feng wrote： +1 for holding this meetup ! Zen Lin 于2019年6月10日周一 上午10:08写道： 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: [VOTE] Toolkit donation proposal
+1(binding) Good work! Yours sincerely Yao Haishi yhs0...@163.com On 6/10/2019 10:23，wjm wjm wrote： +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
回复： [apache/servicecomb-java-chassis] ServerRestArgsFilter可能提前返回响应，导致后面的Filter无效 (#1201)
Sure. Here is the JIRA issue[1]
[1] https://issues.apache.org/jira/browse/SCB-1288
Yours sincerely
Yao Haishi
yhs0...@163.com
在2019年5月18日 18:57，Willem Jiang 写道：
Hi HaiShi,
Could you create a JIRA to track this issue?
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Sat, May 18, 2019 at 5:24 PM yhs0092 wrote:
Hi guys. I've checked the situation described in this issue and the problem
indeed exists.
Maybe we can move the action of actual sending file body into
org.apache.servicecomb.common.rest.AbstractRestInvocation#onExecuteHttpServerFiltersFinish,
and in
org.apache.servicecomb.common.rest.filter.inner.ServerRestArgsFilter#beforeSendResponseAsync
the file body is only added into responseEx?
Yours sincerely
Yao Haishi
yhs0...@163.com
- 转发邮件信息 -
发件人： zhaoyan
发送日期： 2019年5月8日 10:51
发送至： apache/servicecomb-java-chassis
抄送人： Subscribed
主题： [apache/servicecomb-java-chassis]
ServerRestArgsFilter可能提前返回响应，导致后面的Filter无效 (#1201)
问题描述：
org.apache.servicecomb.common.rest.filter.inner.ServerRestArgsFilter#beforeSendResponseAsync
当Object body = response.getResult();是Part类型的时候，导致响应提前返回，
从而后面的Filter滞后执行，而导致可能的错误。（比如增加Header的逻辑，就没有用了）
if (Part.class.isInstance(body)) {
return responseEx.sendPart((Part)body);
}
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
转发：[apache/servicecomb-java-chassis] ServerRestArgsFilter可能提前返回响应，导致后面的Filter无效 (#1201)
Hi guys. I've checked the situation described in this issue and the problem
indeed exists.
Maybe we can move the action of actual sending file body into
org.apache.servicecomb.common.rest.AbstractRestInvocation#onExecuteHttpServerFiltersFinish,
and in
org.apache.servicecomb.common.rest.filter.inner.ServerRestArgsFilter#beforeSendResponseAsync
the file body is only added into responseEx?
Yours sincerely
Yao Haishi
yhs0...@163.com
- 转发邮件信息 -
发件人： zhaoyan
发送日期： 2019年5月8日 10:51
发送至： apache/servicecomb-java-chassis
抄送人： Subscribed
主题： [apache/servicecomb-java-chassis]
ServerRestArgsFilter可能提前返回响应，导致后面的Filter无效 (#1201)
问题描述：
org.apache.servicecomb.common.rest.filter.inner.ServerRestArgsFilter#beforeSendResponseAsync
当Object body = response.getResult();是Part类型的时候，导致响应提前返回，
从而后面的Filter滞后执行，而导致可能的错误。（比如增加Header的逻辑，就没有用了）
if (Part.class.isInstance(body)) {
return responseEx.sendPart((Part)body);
}
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.2.1 (RC-02)
+1 (binding) Checked basic function of ServiceComb-Java-Chassis Yours sincerely Yao Haishi yhs0...@163.com On 5/13/2019 18: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
Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.2.1
-1 binding There is a problem. The generic parameter type like List> is supported before, but 1.2.1 version of ServiceComb-Java-Chassis does not support such kind of usage. An exception is thrown while service booting up. I'm trying to fix it. Later a PR will be committed. Yours sincerely Yao Haishi yhs0...@163.com On 5/7/2019 21:40，yhs0092 wrote： +1 (binding) Checked the basic function of ServiceComb-Java-Chassis Yours sincerely Yao Haishi yhs0...@163.com On 5/7/2019 13:58，Mohammad Asif Siddiqui wrote： +1 (binding) Checks Done : - Hashes and Signature is correct - No unexpected binaries in the release - Archive matching git tag - Can make release from source Regards Asif On 2019/05/06 06:21:11, 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
Re: [VOTE] Release Apache ServiceComb Java-Chassis version 1.2.1
+1 (binding) Checked the basic function of ServiceComb-Java-Chassis Yours sincerely Yao Haishi yhs0...@163.com On 5/7/2019 13:58，Mohammad Asif Siddiqui wrote： +1 (binding) Checks Done : - Hashes and Signature is correct - No unexpected binaries in the release - Archive matching git tag - Can make release from source Regards Asif On 2019/05/06 06:21:11, 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
Re: [DISCUSS] Limit the memory consumption of ServiceComb-Java-Chassis integration tests
Hi, in my new PR[1], the max heap size can be overridden by system property. Please review it. [1]: https://github.com/apache/servicecomb-java-chassis/pull/1179 Yours sincerely Yao Haishi yhs0...@163.com On 4/13/2019 09:14，Willem Jiang wrote： Hi， I just saw the patch, it's better we put the setting in one place which could be overridden by using the system property. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Fri, Apr 12, 2019 at 11:09 AM yhs0092 wrote: 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
[DISCUSS] Limit the memory consumption of ServiceComb-Java-Chassis integration tests
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)
+1 binding Checked code compiling Checked basic function Yours sincerely Yao Haishi yhs0...@163.com On 4/9/2019 18:07，Mohammad Asif Siddiqui wrote： +1 (binding) Checks Done : - hashes and signature is good. - can compile code from source. - git matching archive tag. - source files have ASF headers Regards Asif On Tue, Apr 9, 2019 at 3:12 PM Willem Jiang wrote: +1 binding. Verified the signed key and sha512. Checked the tag and commits Checked the staged repo by running application with java-chassis. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Mon, Apr 8, 2019 at 6:29 PM Mohammad Asif Siddiqui wrote: 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
回复： [ANN] New ServiceComb committer: Zhang Lei (张磊）
Congratulations! Yours sincerely Yao Haishi yhs0...@163.com 在2019年4月2日 15:20，Zen Lin 写道： Congratulations! Best Regards, --- Zen Lin zenlintechnofr...@gmail.com Focused on Micro Service and Apache ServiceComb zhaojun 于2019年4月2日周二 下午12:53写道： Congratulations~ -- Zhao Jun Apache Sharding-Sphere & ServiceComb On Apr 2, 2019, at 11:11 AM, wjm wjm wrote: 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: [discuss][java-chassis] new feature for inspect internal status of a microservice instance
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
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] enhance boot log
+1 It's necessary to inform users of their outdated usage. Yours sincerely Yao Haishi yhs0...@163.com On 1/26/2019 09:26，Willem Jiang wrote： +1, we can add the option for the user to keep the system booting, just like the spring-boot's new option of "spring.main.allow-bean-definition-overriding: true" In this way, we can let user know the configuration changes and the user has the right to decide to change the configuration or not to. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Sat, Jan 26, 2019 at 9:21 AM bismy wrote: I have an another suggestion to handle changes(generally suggestions to handle API changes for SDK): we check the deprecated usage and print error and exit the boot up process, log the suggestions to the user. For example, we change servicecomb.foo to servicecomb.bar, if users configure servicecomb.foo, we quit the bootup process, and suggest users to use servicebomb.bar. This suggestion can make users integration is always the recommended way and both SDK providers and users will benefit from the cooperation. However sometimes users will get quite angry about changes when they integrated new versions in a hurry and no integrations test for them to check the correctness. How about this suggestion? -- 原始邮件 -- 发件人: "Yang Bo"; 发送时间: 2019年1月25日(星期五) 下午5:35 收件人: "dev"; 主题: Re: [discuss] enhance boot log +1 for collecting the important logs(warnings/errors) into a separate place. Perhaps we can also write this collected information both to the console and to a designated log file. The boot logs are so long that's almost impossible for someone to get the meaningful information from them. On Fri, Jan 25, 2019 at 5:02 PM Willem Jiang wrote: Maybe we can add some lines in the release note to let the user know these warning messages are quit important when upgrading the java-chassis version. It's always good to write some upgrade documents to fill the information gap. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Fri, Jan 25, 2019 at 4:57 PM wjm wjm wrote: 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... -- Best Regards, Yang.
Re: [Discuss] Should we support inner class param type defined in REST 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
[Discuss] Should we support inner class param type defined in REST service class?
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
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 value of verticle instance count
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: [DISCUSSION] create a new project servicecomb-samples
+1 This is a good idea. Currently the samples of ServiceComb-Java-Chassis is mixed in our project code, and the maven dependency management is kind of complex. For the new comers, it's a little bit hard to understand and hard to run them. Yours sincerely Yao Haishi yhs0...@163.com On 1/21/2019 16:58，Willem Jiang wrote： I think it's a good idea to use the sample to demonstrate the usage across the subprojects of ServiceComb. Current we have an example[1] in servicecomb-pack for using the java-chasis with pack. Maybe we can put it as the first example of servicecomb-samples. [1]https://github.com/apache/servicecomb-pack/tree/master/demo/saga-servicecomb-demo Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Mon, Jan 21, 2019 at 3:34 PM bismy wrote: 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: Board Report of ServiceComb
+1 It seems good. Yours sincerely Yao Haishi yhs0...@163.com On 12/4/2018 14:04，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
回复： [ANN] New ServiceComb committer: Yao Haishi (姚海石)
It's my honor to be the committer of ServiceComb. Thank you! Yours sincerely Yao Haishi yhs0...@163.com 在2018年11月13日 11:24，赵俊 写道： Congratulation! On Nov 13, 2018, at 10:46 AM, 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
回复： [ANN] New ServiceComb committer: Zhao Jun (赵俊)
Congratulations! Yours sincerely Yao Haishi yhs0...@163.com 在2018年11月13日 12:12，cherrylzhao 写道： I’m very happy to become the committer of ServiceComb! I’d like to try my best to make saga more better! Thanks On Nov 13, 2018, at 11:45 AM, Willem Jiang wrote: Please join me and the rest of the ServiceComb PPMC members in welcoming our new ServiceComb committer: Zhao Jun (赵俊). Yao Haishi contribute the ServiceComb this summer, he is active contributor on saga project and the mailing list, and we look forward to many more contributions in the future. Congratulations to Zhao Jun ! Welcome! Willem Jiang Twitter: willemjiang Weibo: 姜宁willem
Re: [Heads Up ]Git repository names are changed
Thank Willem! I'm submitting a commit in my next pull request to fix the site link in Java-Chassis. Yours sincerely Yao Haishi yhs0...@163.com On 11/9/2018 10:55，wjm wjm wrote： 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][JavaChassis] about customization ofvertxorg.apache.servicecomb.transport.rest.vertx.RestBodyHandler
Yes, I've raised an issue[1] to ask about this feature. Since we expect to remove org.apache.servicecomb.transport.rest.vertx.RestBodyHandler and use io.vertx.ext.web.handler.impl.BodyHandlerImpl directly, we need to ensure the behavior between these two handlers is consistent. After determining which HTTP status code to be returned in the case that uploads dir is null, I will continue to work on this task. [1] https://github.com/vert-x3/vertx-web/issues/1051 Yours sincerely Yao Haishi yhs0...@163.com On 11/6/2018 10:28??bismy wrote?? Yes you are right. My understanding is that "the request method XXX is not allowed in upload", so that it can be used. We are thinking about PR to vert.x, maybe we can create a PR for them to review. -- -- ??: "yhs0092"; : 2018??11??5??(??) 10:21 ??: "dev@servicecomb.apache.org"; : Re: [Discuss][JavaChassis] about customization ofvertxorg.apache.servicecomb.transport.rest.vertx.RestBodyHandler Hi @bi...@qq.com , I've searched for the descriptions about HTTP status 405, but the description[1] seems to indicate that this status is for those cases that request method is wrong, e.g. the request method is GET but the server only accept POST. So is it proper to use 405 in this scenario? If there is no proper HTTP status, maybe we can use 500? And I've create a task[2] to track this issue. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405 [2] https://issues.apache.org/jira/browse/SCB-1010 Yours sincerely Yao Haishi yhs0...@163.com On 11/5/2018 20:24??bismy wrote?? Maybe we can send a 405 Method Not Allowed message. -- ???? -- ??: "yhs0092"; : 2018??11??1??(??) 8:56 ??: "dev@servicecomb.apache.org"; : Re: [Discuss][JavaChassis] about customization of vertxorg.apache.servicecomb.transport.rest.vertx.RestBodyHandler Hi, I've tried to remove ServiceComb exceptions from RestBodyHandler today. Technically, it is feasible. In my test, I replace the ServiceComb exceptions with IllegalArgumentException in the case that upload directory is not specified and replace with 413 status code in the case that uploaded file is too large. In GlobalRestFailureHandler I recognize the exception and status code and then return corresponding response. This solution seems working well, but there are still some details need to be discussed. The first one is whether it's proper to use IllegalArgumentException in this situation. I use it because I cannot find other Exception more accurately express the meaning "upload directory is not specified". The other one is that the logic to convert the exceptions into error response is set in GlobalRestFailureHandler. It seems not elegant, but I still don't find any better solution. Yours sincerely Yao Haishi yhs0...@163.com On 10/31/2018 17:54??yhs0092 wrote?? Hi, one of the JavaChassis exception wrapped in RestBodyHandler is added by me. I will try to remove the JavaChassis exceptions in RestBodyHandler and see whether it can works well. Yours sincerely Yao Haishi yhs0...@163.com On 10/31/2018 09:00??wjm wjm wrote?? currently we customized org.apache.servicecomb.transport.rest.vertx.RestBodyHandler 1.disable upload feature when uploadDir is null, this is a general requirement 2.wrap some exceptions to JavaChassis exception?? this is not a general requirement if there is only customization 1, maybe we can try to raise a PR to vertx otherwise we always forget to merge latest vertx logic to our code. maybe we can confirm if customization 2 is necessary.
Re: [Discuss][JavaChassis] about customization of vertxorg.apache.servicecomb.transport.rest.vertx.RestBodyHandler
Hi @bi...@qq.com , I've searched for the descriptions about HTTP status 405, but the description[1] seems to indicate that this status is for those cases that request method is wrong, e.g. the request method is GET but the server only accept POST. So is it proper to use 405 in this scenario? If there is no proper HTTP status, maybe we can use 500? And I've create a task[2] to track this issue. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405 [2] https://issues.apache.org/jira/browse/SCB-1010 Yours sincerely Yao Haishi yhs0...@163.com On 11/5/2018 20:24??bismy wrote?? Maybe we can send a 405 Method Not Allowed message. -- -- ??: "yhs0092"; : 2018??11??1??(??) 8:56 ??: "dev@servicecomb.apache.org"; : Re: [Discuss][JavaChassis] about customization of vertxorg.apache.servicecomb.transport.rest.vertx.RestBodyHandler Hi, I've tried to remove ServiceComb exceptions from RestBodyHandler today. Technically, it is feasible. In my test, I replace the ServiceComb exceptions with IllegalArgumentException in the case that upload directory is not specified and replace with 413 status code in the case that uploaded file is too large. In GlobalRestFailureHandler I recognize the exception and status code and then return corresponding response. This solution seems working well, but there are still some details need to be discussed. The first one is whether it's proper to use IllegalArgumentException in this situation. I use it because I cannot find other Exception more accurately express the meaning "upload directory is not specified". The other one is that the logic to convert the exceptions into error response is set in GlobalRestFailureHandler. It seems not elegant, but I still don't find any better solution. Yours sincerely Yao Haishi yhs0...@163.com On 10/31/2018 17:54??yhs0092 wrote?? Hi, one of the JavaChassis exception wrapped in RestBodyHandler is added by me. I will try to remove the JavaChassis exceptions in RestBodyHandler and see whether it can works well. Yours sincerely Yao Haishi yhs0...@163.com On 10/31/2018 09:00??wjm wjm wrote?? currently we customized org.apache.servicecomb.transport.rest.vertx.RestBodyHandler 1.disable upload feature when uploadDir is null, this is a general requirement 2.wrap some exceptions to JavaChassis exception?? this is not a general requirement if there is only customization 1, maybe we can try to raise a PR to vertx otherwise we always forget to merge latest vertx logic to our code. maybe we can confirm if customization 2 is necessary.
Re: [Discuss][JavaChassis] about customization of vertx org.apache.servicecomb.transport.rest.vertx.RestBodyHandler
Hi, I've tried to remove ServiceComb exceptions from RestBodyHandler today. Technically, it is feasible. In my test, I replace the ServiceComb exceptions with IllegalArgumentException in the case that upload directory is not specified and replace with 413 status code in the case that uploaded file is too large. In GlobalRestFailureHandler I recognize the exception and status code and then return corresponding response. This solution seems working well, but there are still some details need to be discussed. The first one is whether it's proper to use IllegalArgumentException in this situation. I use it because I cannot find other Exception more accurately express the meaning "upload directory is not specified". The other one is that the logic to convert the exceptions into error response is set in GlobalRestFailureHandler. It seems not elegant, but I still don't find any better solution. Yours sincerely Yao Haishi yhs0...@163.com On 10/31/2018 17:54，yhs0092 wrote： Hi, one of the JavaChassis exception wrapped in RestBodyHandler is added by me. I will try to remove the JavaChassis exceptions in RestBodyHandler and see whether it can works well. Yours sincerely Yao Haishi yhs0...@163.com On 10/31/2018 09:00，wjm wjm wrote： currently we customized org.apache.servicecomb.transport.rest.vertx.RestBodyHandler 1.disable upload feature when uploadDir is null, this is a general requirement 2.wrap some exceptions to JavaChassis exception， this is not a general requirement if there is only customization 1, maybe we can try to raise a PR to vertx otherwise we always forget to merge latest vertx logic to our code. maybe we can confirm if customization 2 is necessary.
Re: [Discuss][JavaChassis] about customization of vertx org.apache.servicecomb.transport.rest.vertx.RestBodyHandler
Hi, one of the JavaChassis exception wrapped in RestBodyHandler is added by me. I will try to remove the JavaChassis exceptions in RestBodyHandler and see whether it can works well. Yours sincerely Yao Haishi yhs0...@163.com On 10/31/2018 09:00，wjm wjm wrote： currently we customized org.apache.servicecomb.transport.rest.vertx.RestBodyHandler 1.disable upload feature when uploadDir is null, this is a general requirement 2.wrap some exceptions to JavaChassis exception， this is not a general requirement if there is only customization 1, maybe we can try to raise a PR to vertx otherwise we always forget to merge latest vertx logic to our code. maybe we can confirm if customization 2 is necessary.
Re: [DISCUSSION java-chassis]scan RestController to to make springmvc controller publish as ServiceComb Rest easier
This is a great idea! And I think we should explicitly tell users about the
priority of @RequestMapping, @RestSchema, and @RestController, no matter on the
release note or the gitbook. Since I've seen some users transform their
SpringBoot/SpringCloud project into ServiceComb and leave all of these three
annotations on their rest interface classes, it's necessary to declare this
overwriting behavior.
Yours sincerely
Yao Haishi
yhs0...@163.com
On 10/27/2018 17:01，wjm wjm wrote：
ok
bismy 于2018年10月27日周六 下午3:14写道：
I am going to make it default to true. And add some release notes about
this change.
Our compatible rule is making things better by default, and users can
change to old feature when integration. Or we can not implement new
features due to users bad practices.
-- 原始邮件 --
发件人: "zzzwjm";
发送时间: 2018年10月27日(星期六) 中午11:05
收件人: "dev";
主题: Re: [DISCUSSION java-chassis]scan RestController to to make springmvc
controller publish as ServiceComb Rest easier
+1
but, what's default value of servicecomb.rest.service.scanRestController
if to be true, then can make spring mvc controller publish as ServiceComb
Rest easier, but maybe not compatible
but if to be false, then this feature is not so useful?
bismy 于2018年10月27日周六 上午10:57写道：
Hi all,
I am going to implement a feature that scan beans with @RestController
annotation, and taken it same as:
1. @RestSchema(schemaId = class.getName())
2. @RequestMapping("/")
Consider some users want to make use of both spring mvc controller and
ServiceComb REST, we add a configuration
servicecomb.rest.service.scanRestController
to turn off this feature.
Any suggestions?
Re: [Discuss] Do we need to add some reminder logs on SwaggerGeneratorContext selection?
OK, JIRA issue has been created, https://issues.apache.org/jira/browse/SCB-979 As for pojo mode, I think maybe we can check the annotations on the REST interface class. If the PojoSwaggerGeneratorContext is selected and @RequestMapping or @Path is found, we can print some extra reminder log. The log level is INFO, so we don't mean that it must be a problem. Yours sincerely Yao Haishi yhs0...@163.com On 10/24/2018 21:46，wjm wjm wrote： log the selected mode is necessary but pojo mode not know what's other mode.. Willem Jiang 于2018年10月24日周三 下午8:30写道： Hi Haishi It's important to let the user know about if there is some fallback mechanism is used. In this way we could save user lot of time for the trouble shooting. We also need to inform the user from log if there are some important configuration information is loaded. BTW, Please fill a JIRA to track this issue. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Wed, Oct 24, 2018 at 4:14 PM yhs0092 wrote: Hi guys. Yesterday, a user asked me about a 404 error. He packed his JavaChassis project into a jar file and ran it on his laptop. But when he invoked the rest interface by Postman, a 404 error was returned, while if he ran the project in Eclipse, this problem did not occur. Finally we found out there was something wrong with maven. On his laptop, if maven packaging command was run in Windows CMD, the output jar file lacked swagger-generator-springmvc dependency jar. As the implementations of SwaggerGeneratorContext are loaded by SPI mechanism, there is no error when some classes are abscent. When the expected SpringmvcSwaggerGeneratorContext is abscent, the PojoSwaggerGeneratorContext will be used as default. As a result, the @RequestMapping tagged on REST interface class is ignored, and the name of the class is used as basePath instead of the value specified in @RequestMapping. After cleaning local maven repo, the problem disappeared. But in this case, there is almost no log for helping locate the problem cause. So do we need to add some log to indicate the potential problem? Currently I think we can add log to show which SwaggerGeneratorContext is selected to generate swagger schema. And if PojoSwaggerGeneratorContext is selected, we can add some extra logic to check whether there is @Path or @RequestMapping and remind developer to be aware of the dependency jar files. Any ideas? Yours sincerely Yao Haishi yhs0...@163.com
Re: [VOTE] Graduate Apache ServiceComb (incubating)
+1 non-binding Yours sincerely Yao Haishi yhs0...@163.com On 9/17/2018 10:47??DeanLee<82529...@qq.com> wrote?? +1 Dean Lee ---Original--- From: "Lance Ju" Date: Mon, Sep 17, 2018 10:19 AM To: "zhouzhongyuan666";"dev"; Subject: Re: [VOTE] Graduate Apache ServiceComb (incubating) +1 zhongyuan zhou ??2018??9??17?? 10:02?? +1 cherrylzhao ??2018??9??16?? 8:54?? +1 On 15 Sep 2018, at 10:10 AM, Eric Lee wrote: +1 On Sat, Sep 15, 2018, 09:32 Zheng Feng wrote: +1 (binding) Willem Jiang ?? 2018??9??14?? 15:58?? Please vote on the proposal for ServiceComb graduation to TLP to submit to the Incubator PMC. Vote: [ ] +1 - Recommend Graduation of Apache ServiceComb as a TLP [ ] -1 - Do not recommend graduation of Apache ServiceComb because ??. This vote will stay open for at least 72 hours. Establish the Apache ServiceComb Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to a microservice framework that provides a set of tools and components to make development and deployment of cloud applications easier. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache ServiceComb Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache ServiceComb Project be and hereby is responsible for the creation and maintenance of software related to a microservice framework that provides a set of tools and components to make development and deployment of cloud applications easier; and be it further RESOLVED, that the office of "Vice President, Apache ServiceComb" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache ServiceComb Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache ServiceComb Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache ServiceComb Project: * Aray Chenchu Sukesh * Bao Liu * Eric Lee * Jean-Baptiste Onofr?? * Jimin Wu * Linzhinan * Mohammad Asif Siddiqui * Qi Zhang * Roman Shaposhnik * Timothy Chen * Willem Ning Jiang * Yang Bo * Yihua Cui * Yin Xiang * Zheng Feng * zhengyangyong NOW, THEREFORE, BE IT FURTHER RESOLVED, that Willem Ning Jiang be appointed to the office of Vice President, Apache ServiceComb, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache ServiceComb Project be and hereby is tasked with the migration and rationalization of the Apache Incubator ServiceComb podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator ServiceComb podling encumbered upon the Apache Incubator PMC are hereafter discharged. Regards, Willem Jiang Twitter: willemjiang Weibo: willem
回复：答复: [Discuss]Java Chassis Support Spring Boot 2.0
Hi, Yangyong. I've tried your pull request in my Spring Boot 2 demo and it
works well, great job!
I have a little question, can we put spring-boot2-starter-servlet into the
dependencyManagement of java-chassis-dependencies-springboot2 so that users
only need to introduce one dependency in their project dependencyManagement?
Currently it seems a little bit redundant. See the pom of integration test:
https://github.com/apache/incubator-servicecomb-java-chassis/blob/ae3c92e902b6459bfb76db13c90fe6b5d1044abe/integration-tests/springmvc-tests/springmvc-tests-general-with-springboot2-servlet/pom.xml
Yours sincerely
Yao Haishi
yhs0...@163.com
在2018年9月13日 10:13，YangYongZheng<342906...@qq.com> 写道：
Right~, that's better way, but need more works
Best Regards!
YangYongZheng
-邮件原件-
发件人: Yang Bo [mailto:oaky...@gmail.com]
发送时间: 2018年9月13日 10:02
收件人: dev@servicecomb.apache.org
主题: Re: [Discuss]Java Chassis Support Spring Boot 2.0
Hi,
It seems to me that just changing the spring/springboot version is not enough.
There might be inconsistent implementation details which will require code
change between spring 4.x and spring 5.x.
It's better that we remove spring dependency from those none spring related
modules, and then using profile or a separate dependency pom for managing the
spring version.
Modules depends on spring:
ybo@yangbo:~/repos/incubator-servicecomb-java-chassis$ find . -type f -name
"pom.xml" -exec grep -l spring {} \; | grep -v demo | grep -v samples | grep -v
spring-boot | grep -v tests
./transports/transport-rest/transport-rest-servlet/pom.xml
./archetypes/business-service-jaxrs/target/classes/archetype-resources/pom.xml
./archetypes/business-service-jaxrs/src/main/resources/archetype-resources/pom.xml
./archetypes/business-service-springmvc/target/classes/archetype-resources/pom.xml
./archetypes/business-service-springmvc/src/main/resources/archetype-resources/pom.xml
./archetypes/business-service-springmvc/pom.xml
./archetypes/pom.xml
./java-chassis-distribution/pom.xml
./dynamic-config/config-apollo/pom.xml
./parent/pom.xml
./tracing/tracing-zipkin/pom.xml
./tracing/pom.xml
./java-chassis-dependencies/pom.xml
./pom.xml
./handlers/handler-tracing-zipkin/pom.xml
./providers/pom.xml
./providers/provider-springmvc/pom.xml
./coverage-reports/pom.xml
./swagger/swagger-generator/pom.xml
./swagger/swagger-generator/generator-springmvc/pom.xml
./swagger/swagger-invocation/invocation-springmvc/pom.xml
./swagger/swagger-invocation/invocation-core/pom.xml
./swagger/swagger-invocation/pom.xml
./foundations/foundation-config/pom.xml
./foundations/foundation-test-scaffolding/pom.xml
./foundations/foundation-common/pom.xml
On Thu, Sep 13, 2018 at 9:42 AM 郑扬勇 wrote:
Hi all:
Spring boot 2.0 had released for a long time ,so I think we need
support it as soon as possible.
Here is our current dependency relationship :
java-chassis [pom]
↑
java-chassis-dependencies(import springboot 1.5.x and spring4.3.x
etc) [pom] ↑ java-chassis-parent (docker & jacoco plugin etc) [pom]
↑ core,edge,handler etc [jar]
So I think we can do like this for support spring boot 2.0:
java-chassis [pom]
↑
* java-chassis-dependencies-springboot2 (FIRST import springboot
2.0.x and spring5.0.x ,THEN import java-chassis-dependencies) [pom] ↑
spring-boot2-starter-servlet(for support Embedded tomcat) etc [jar]
Any thoughts?
Best Regards & Thanks!
Yangyong Zheng
--
Best Regards,
Yang.
Re: [DRAFT] Graduation resolution proposal
+1 Great job! Yours sincerely Yao Haishi yhs0...@163.com On 9/13/2018 11:08，Lance Ju wrote： +1 Great job! DeanLee <82529...@qq.com> 于2018年9月13日周四 上午10:57写道： +1 ---Original--- From: "Willem Jiang" Date: Wed, Sep 12, 2018 21:52 PM To: "dev"; Subject: [DRAFT] Graduation resolution proposal As ServiceComb community discussed for the graduation for a while[1] and all the committer are OK to be the member of PMC[2]. Now we have the developer team[3] from Huawei, Talend, Stealth, Hyperpilot, RedHat, JingDong,Tencent, Syswin, PICC, Changhong, Cainiao. 3300+ commits on development of three subproject. 1350+ PRs on the Github 171 contributors 800+ issues created 700+ issues resolved dev has 113 subscribers 208 emails sent by 28 people, divided into 30 topics in last month Please check out Apache Maturity Model Assessment for ServiceComb[4] for more information. I just draft our graduation resolution proposal here. Please comment it. NOTE * I'm proposing myself as initial PMC chair -- Please comment if community is onboard with this or propose other persons as well [1] https://lists.apache.org/thread.html/8e59fef1a9eae9ee90808114b3abbdfdf8c6f24442d7575ee04f5100@%3Cdev.servicecomb.apache.org%3E [2] https://lists.apache.org/thread.html/2d1e7f17f15fc8ec0d4d293798991e93127534be9cc13334336d228f@%3Cdev.servicecomb.apache.org%3E [3]https://servicecomb.incubator.apache.org/developers/team/ [4] https://cwiki.apache.org/confluence/display/SERVICECOMB/Apache+Maturity+Model+Assessment+for+ServiceComb Establish the Apache ServiceComb Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to a microservice framework that provides a set of tools and components to make development and deployment of cloud applications easier. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache ServiceComb Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache ServiceComb Project be and hereby is responsible for the creation and maintenance of software related to a microservice framework that provides a set of tools and components to make development and deployment of cloud applications easier; and be it further RESOLVED, that the office of "Vice President, Apache ServiceComb" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache ServiceComb Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache ServiceComb Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache ServiceComb Project: * Aray Chenchu Sukesh * Bao Liu * Eric Lee * Jean-Baptiste Onofré * Jimin Wu * Linzhinan * Mohammad Asif Siddiqui * Qi Zhang * Roman Shaposhnik * Timothy Chen * Willem Ning Jiang * Yang Bo * Yihua Cui * Yin Xiang * Zheng Feng * zhengyangyong NOW, THEREFORE, BE IT FURTHER RESOLVED, that Willem Ning Jiang be appointed to the office of Vice President, Apache ServiceComb, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache ServiceComb Project be and hereby is tasked with the migration and rationalization of the Apache Incubator ServiceComb podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator ServiceComb podling encumbered upon the Apache Incubator PMC are hereafter discharged. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem
Re: [DISCUSS] Q & A of website issue
OK, I will send a PR later. Yours sincerely Yao Haishi yhs0...@163.com On 9/9/2018 16:38，Willem Jiang wrote： Hi Haishi, Please feel free to send a PR to keep the FAQ updated. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Fri, Sep 7, 2018 at 2:25 PM yhs0092 wrote: Hi, maybe some questions in our website https://docs.servicecomb.io/java-chassis/en_US/question-and-answer/question_answer.html should be updated. For example, there is a question Q: 框架中引入了vertx会有什么好处？ A: 启用vertx的标准工作模式更强大，不过对业务人员要求就有些高了，目前还没开放业务接口出来。vertx标准的reactive工作模式，要求业务代码中不能有任何的block wait,sleep，大循环，总之不能有阻塞，做到这一点，就可以用更少的CPU，提供更多的服务。 I guess this answer is talking about reactive mode, and we have provided this feature. And there is an answer says that JavaChassis does not support generic param, Q: ServiceComb不支持泛型 A: 明确不支持，需要修改接口，接口修改后需要修改版本号，以免consumer还是使用旧的版本。 but we have supported generic param and response type. See https://docs.servicecomb.io/java-chassis/en_US/build-provider/interface-constraints.html Yours sincerely Yao Haishi yhs0...@163.com On 9/5/2018 17:24，Zen Lin wrote： To my opinion, if we have faqs, we should make sure there is a search entry that can search questions directly by keyword. Usually, opensource projects use google search embeded into the website, but I am not sure if the google search can search out them. If we can not reach that, I suggest we just list them within the user guide, thus when users use user guide, they can also get the corresponding faqs. Best Regards, --- Zen Lin zenlintechnofr...@gmail.com Focused on Micro Service and Apache ServiceComb DeanLee <82529...@qq.com> 于2018年9月5日周三 下午4:21写道： Hi all, I want to translate Q & A of the website for English as blew, but here is a problem. http://servicecomb.incubator.apache.org/cn/faqs/ For now, we have two pages of Q(another one in UserGuide). Should we merge it together or keep it split as before https://docs.servicecomb.io/java-chassis/en_US/question-and-answer/question_answer.html Best Regards, Dean
Re: [DISCUSS] Q & A of website issue
Hi, maybe some questions in our website https://docs.servicecomb.io/java-chassis/en_US/question-and-answer/question_answer.html should be updated. For example, there is a question Q: 框架中引入了vertx会有什么好处？ A: 启用vertx的标准工作模式更强大，不过对业务人员要求就有些高了，目前还没开放业务接口出来。vertx标准的reactive工作模式，要求业务代码中不能有任何的block wait,sleep，大循环，总之不能有阻塞，做到这一点，就可以用更少的CPU，提供更多的服务。 I guess this answer is talking about reactive mode, and we have provided this feature. And there is an answer says that JavaChassis does not support generic param, Q: ServiceComb不支持泛型 A: 明确不支持，需要修改接口，接口修改后需要修改版本号，以免consumer还是使用旧的版本。 but we have supported generic param and response type. See https://docs.servicecomb.io/java-chassis/en_US/build-provider/interface-constraints.html Yours sincerely Yao Haishi yhs0...@163.com On 9/5/2018 17:24，Zen Lin wrote： To my opinion, if we have faqs, we should make sure there is a search entry that can search questions directly by keyword. Usually, opensource projects use google search embeded into the website, but I am not sure if the google search can search out them. If we can not reach that, I suggest we just list them within the user guide, thus when users use user guide, they can also get the corresponding faqs. Best Regards, --- Zen Lin zenlintechnofr...@gmail.com Focused on Micro Service and Apache ServiceComb DeanLee <82529...@qq.com> 于2018年9月5日周三 下午4:21写道： Hi all, I want to translate Q & A of the website for English as blew, but here is a problem. http://servicecomb.incubator.apache.org/cn/faqs/ For now, we have two pages of Q(another one in UserGuide). Should we merge it together or keep it split as before https://docs.servicecomb.io/java-chassis/en_US/question-and-answer/question_answer.html Best Regards, Dean
Re: About introduce Lombok to service comb
Agree to Yang Bo, too. ServiceComb is not a common business project, it's a framework. So there are not so many Java bean classes defined in it, which means we will not take so much advantage of Lombok. While using Lombok requires plug-in installed in IDE, the threshold of developing and contributing to ServiceComb-Java-Chassis seems to be raised more or less. Yours sincerely YaoHaishi yhs0...@163.com On 8/27/2018 14:16，wjm wjm wrote： agree to Yang BO. 2018-08-27 11:14 GMT+08:00 Yang Bo : I don't think using lombok in Java-Chassis is a good idea. It provides little to no value but introduces a lot of headaches for all developers. It's much clearer for the code to be explicit other than embedded in annotations even if that means we need to write a bit more code. And it pretty easy to use IDE to generate those kind of code anyway. On Mon, Aug 27, 2018 at 8:31 AM Willem Jiang wrote: Lombok generate the codes during the compile time, we don't need use it in the runtime. The only shortcoming of Lombok is we need to install the plugin in the IDE to make sure the get|set codes are generated rightly, otherwise he will get lot of compile complains. That is why I suggest we need to update the development environment document if we decide to use it. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Sat, Aug 25, 2018 at 6:55 PM 赵俊 wrote: Hi，bismy in factor we can import Lombok and make the scope is provided. Then users dependency service Lombok will not see the Lombok jar. We(sharding-sphere) use Lombok like this. org.projectlombok lombok 1.16.4 provided On 25 Aug 2018, at 9:27 AM, bismy wrote: @赵俊 Glad to hear that. I am not meaning all projects not using lombok. Just providing a framework, we have different concerns. In short: 1. Use as less 3rdparties dependencies as possible. 2. Make users use different 3rdparties easier. So you can see from java-chassis, we do not depend some very good frameworks like spring, spring boot components and use old fashioned SPI mechanism. But users can use these framework easily in their projects. Although java-chassis do not use lombok, if you find something we did make integrate lombok not possible, please feel free to point out. -- 原始邮件 -- 发件人: "赵俊"; 发送时间: 2018年8月23日(星期四) 上午10:39 收件人: "dev@servicecomb.apache.org"; 主题: Re: About introduce Lombok to service comb Hi we often use following lombok annotations, it makes our code clean especially existing too many fields. Lombok seems to be very stable for us so far. 1.@Getter, @Setter 2. @RequiredAgsConstructor 3. @NoArgsConstructor(access = AccessLevel.PRIVATE) 4. @Slf4j 5. @EqualsAndHashCode 6. @ToString On 23 Aug 2018, at 10:03 AM, bismy wrote: In my opinion, I'd prefer not include Lombok in our project. Here my reasons: 1. It's a convenient tool to write getters and setters, users can include it very easily to their projects. 2. For framework, I'd prefer our class do not use Lombok annotations. Because write getters/setters is very potable to very runtime,and quite easy with an IDE. We can avoid many troubles related to 3rdparty dependencies, licenses and maybe conflicts. 3. Some of our customers using Lombok before, there are some know issues regarding to java bean specification or work together with Json libraries. (Sorry I do not have the details) -- 原始邮件 -- 发件人: "willem.jiang"; 发送时间: 2018年8月22日(星期三) 下午3:40 收件人: "dev"; 主题: Re: About introduce Lombok to service comb We could specify it in the environment setup document. @Cherry Could you share the experience of Lombok usage in sharding sphere? Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Wed, Aug 22, 2018 at 2:13 PM, wjm wjm wrote: everyone clone our code, if need to load by IDE, must install the IDE plugin, i don't think it's a good idear. 2018-08-22 12:33 GMT+08:00 Zheng Feng : It looks good to me and the lombok supports the JDK 9 ? 2018-08-22 12:21 GMT+08:00 赵俊 : Hi, Willem Lombok would not package into our service-comb jar, so there is no license issue. We can set the maven scope is “provide”, it just enhance the java code byte in compile step. On 21 Aug 2018, at 10:57 PM, wjm wjm wrote: in fact, getter / setter and so on can be generated by IDE(IntelliJ / Eclipse) simply 2018-08-21 22:34 GMT+08:00 Willem Jiang https://projectlombok.org < https://projectlombok.org/ any thought? -- Best Regards, Yang.
Re:Re: [DISCUSS]Shall we upgrade Java-chassis to support Spring Boot2
I tried to upgrade Java-Chassis to support SpringBoot2 before, but failed. There are two problems. The first one is in our bean.xml file， the xsd file is imported like below: ``` classpath:org/springframework/beans/factory/xml/spring-beans-3.0.xsd ``` but 3.0 version xsd file does not exist anymore. This is still resolvable, but for the second problem, I still haven't found a way to resolve it. When my service demo is started, an error occurs: ``` 2018-03-13 22:57:18.396 WARN 6 --- [ main] ConfigServletWebServerApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanDefinitionStoreException: Failed to parse configuration class [org.apache.servicecomb.springboot.starter.transport.RestServletInitializer]; nested exception is java.io.FileNotFoundException: class path resource [org/springframework/boot/context/embedded/AbstractConfigurableEmbeddedServletContainer.class] cannot be opened because it does not exist ``` Because AbstractConfigurableEmbeddedServletContainer is removed in SpringBoot2, and our RestServletInitializer is extended from this class, maybe we cannot upgrade to SpringBoot2 by simply change the maven dependency. And once we refactor our RestServletInitializer, the java-chassis may not be compatible with SpringBoot1. 在 2018-07-20 08:57:05，"wjm wjm" 写道： >not enough, must exclude old spring also > >2018-07-20 6:44 GMT+08:00 Willem Jiang : > >> How about let user override the version of Spring Boot in their application >> and give it a try. >> Just like what we do with JDK9 here[1] >> If there is any issue comes out, we can keep digging it. >> >> [1]https://github.com/apache/incubator-servicecomb-saga/issues/76 >> >> >> Willem Jiang >> >> Twitter: willemjiang >> Weibo: 姜宁willem >> >> On Thu, Jul 19, 2018 at 8:26 PM, Bin Ma wrote: >> >> > Hi, >> > Java-chassis currently supports Spirng Boot 1.5.12 version. >> > >> > In fact, some enterprise users develop their coursewares based on >> Spring >> > Boot2, so hopefully Java-chassis can support Spring Boot2, such as >> Chuanzhi >> > Boke. >> > >> > I think it's neccessary to discuss the plan about upgrading >> > Java-Chasssis to support Spring Boot2 to satisfy users' scenario. >> > >> > Any thoughts and any troubles to upgrading, please feel free to discuss >> > here. >> > >>
