?????? [VOTE]Tracking the Github issue discussions to dev@servicecomb.apache.org
For my personal preferences, we don't need to change anything, and now everything works fine. 1. We discussion problem is dev mailing list. Users can send their questions though mail. 2. Users submit issues or ask questions in issues @github, I subscribe notifications from github and answers questions @github. We can encourage users to discuss problems using mailing list and submit/discuss issues @github. -- -- ??: "Zen Lin"; : 2019??1??15??(??) 12:07 ??: "dev"; : Re: [VOTE]Tracking the Github issue discussions to dev@servicecomb.apache.org If there is no one knows how the Infra team track the github notification to commits list, I am going to ask the Infra team for the details, and will help to research the feasibility of separation. Best Regards, --- Zen Lin zenlintechnofr...@gmail.com Focused on Micro Service and Apache ServiceComb Zen Lin ??2019??1??15?? 11:56?? > Is there anyone knows how Infra group track the github notification to > comm...@servicecomb.apache.org? > If it is using github API, it is work to seperate github issue. > > Best Regards, > --- > Zen Lin > zenlintechnofr...@gmail.com > Focused on Micro Service and Apache ServiceComb > > > Willem Jiang ??2019??1??15?? 11:44?? > >> We cannot just redirect the question to the Infra team without doing >> the research first. >> My suggestion is we need to do some research to figure out how to >> separate the github issue notification from the github notification >> stream. >> Then we can give the Infra team instructions to do the work with their >> admin right. >> If we cannot get there, we could consider to disable the github issue >> function to let user use mail to ask questions directly. >> >> Willem Jiang >> >> Twitter: willemjiang >> Weibo: willem >> >> On Tue, Jan 15, 2019 at 9:54 AM Zen Lin >> wrote: >> > >> > Yeah, >> > If we track the github issue to dev mail, we can watch the issue >> > contents in the dev mailing list. >> > If you want your reply can posted to the github issue, you can >> > reply the mail sent by github, in that way, the reply can be posted >> > on issue and also be sent to the dev mailing list. >> > >> > Anyway, as Willem said, we now have tracked the github >> > notification to comm...@servicecomb.apache.org, we just need >> > to seperate them from the github notification. >> > >> > Hi Willem, >> > As I known, this will be implemented by Apache Infra group. >> > What about to create a vote for this, and then I will create an >> > issue to Apache Infra, >> > or just create a mail to copy to infrastructure-...@apache.org >> > >> > Best Regards, >> > --- >> > Zen Lin >> > zenlintechnofr...@gmail.com >> > Focused on Micro Service and Apache ServiceComb >> > >> > >> > Willem Jiang ??2019??1??15?? 9:27?? >> > >> > > I don't think we can bridge the dev mail to the github issue, but it >> > > makes sense that to send the notification or the github issue to the >> > > dev mailing list. >> > > Now we need to figure out if we can seperate the github notification >> > > by checking if it comes from github issues. >> > > >> > > Willem Jiang >> > > >> > > Twitter: willemjiang >> > > Weibo: willem >> > > >> > > On Mon, Jan 14, 2019 at 10:00 PM Zheng Feng >> wrote: >> > > > >> > > > I wonder if it can only watch the github issues by using the dev >> mailing >> > > > list or we can reply the thread and it could be posted to the github >> > > issue >> > > > automatically ? >> > > > >> > > > Zen Lin ??2019??1??14?? >> > > > 8:38?? >> > > > >> > > > > How about to create a new proposal discussion for split github >> issue >> > > track >> > > > > from commits mailing list to dev mailing list? >> > > > > I think discussion in github issue is quite different from >> commits, >> > > they >> > > > > are similar to the contents in the dev list. >> > > > > >> > > > > Best Regards, >> > > > > --- >> > > > > Zen Lin >> > > > > zenlintechnofr...@gmail.com >> > > > > Focused on Micro Service and Apache ServiceComb >> > > > > >> > > > > >> > > > > Willem Jiang ??2019??1??14?? >> > > > > 8:20?? >> > > > > >> > > > > > Actually we already had the vote[1] of moving the github >> > > notifications >> > > > > > into the commits mailing list to avoiding flooding the dev >> mailing >> > > > > > list . Here is the discussion of it[2]. Now the user questions >> in the >> > > > > > github issue are tracked in the commits mailing list. >> > > > > > >> > > > > > [1] >> > > > > > >> > > > > >> > > >> https://lists.apache.org/thread.html/833356d5dd8901f5d51e94b12d48f9dcb816d29f50b38d46915f8e9e@%3Cdev.servicecomb.apache.org%3E >> > > > > > [2] >> > > > > > >> > > > > >> > > >> https://lists.apache.org/thread.html/95f538f676326bd2cb1a06cf278c4076352b987bfbabad6c6ae247bc@%3Cdev.servicecomb.apache.org%3E >> > > > > > >> > > > > > >> > > > > > Willem Jiang >> > > > > > >> > > > > > Twitter:
[DISCUSSION] create a new project servicecomb-samples
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?
?????? [discuss] change mechanism of java chassis POJO consumerparamters mapping
I do not think your suggestion is a good idea, and I'd prefer not change it and
remain the same.
You problem comes from the semantics of the definition:
void method(QueryWrapper querys, int p2);
For query parameter querys (type of QueryWrapper) do not mean one parameter,
but many parameters based on it's structure, it a special grammar for POJO
queries. So the client code can be:
void method(int x, int y, int p2)
or
void method(int x, int y, int z, int p2)
When you add a new name for QueryWrapper, it equals to you add a parameter for
void method(int x, int y, int p2) to void method(int x, int y, int z, int p2)
and it's a change should be noticed that client should change the invocation
code.
Benefit for your suggestion is that users can add new parameters for an API,
and I think this scenario is a CHANGE, and should change client code, but not
adapt to it.
And if you use parameter name to handle this, their will cause conflicts. For
example, add an x for this method:
void method(QueryWrapper querys, int x, int y);
And We need to consider other problems like name in @RequestParam("name1") is
different with parameter name.
In conclusion, I prefer not to handle this scenario.
-- --
??: "zzzwjm";
: 2019??1??18??(??) 0:17
??: "dev@servicecomb.apache.org";
: Re: [discuss] change mechanism of java chassis POJO consumerparamters
mapping
java8 support present interface method parameter name
need to add compile argument, not debug option
?? 2019??1??17??Willem Jiang ??
> Java compile will remove the parameters name by default. We faced the
> same problem in CXF simple frontend.
> The solution could be enable the debug option in the compiler or add
> annotation to the parameters.
>
> If we decide to setting the option on the compiler, we should not only
> throw exception in the runtime, but also document it.
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: willem
>
> On Thu, Jan 17, 2019 at 5:23 PM wjm wjm wrote:
> >
> > Scenes??
> > 1.producer is springMVC dev mode
> > class QueryWrapper {
> > int x;
> > int y;
> > }
> > void method(QueryWrapper querys, int p2);
> >
> > will produce swagger operation, have 3 parameters: x, y, p2
> >
> > 2.consumer is POJO dev mode, declare a interface:
> > interface TestIntf {
> > void method(int x, int y, int p2);
> > }
> > until now, everything is ok.
> >
> > 3.producer upgrade
> > class QueryWrapper {
> > int x;
> > int y;
> > int z;
> > }
> > will produce swagger operation, have 4 parameters: x,y,z,p2
> >
> > in this time, old POJO consumers will have problems:
> > assign x to x, y to y, p2 to z
> > that's because we map parameters by their index
> >
> > to resolve the problem:
> > we need to map parameters by their name
> > this require customers change their compile argument in pom.xml to
> allow
> > interface present method parameter name
> > if did not add compile argument, SDK can throw exception, and print how
> > to add the compile argument.
> >
> > any idea?
>
