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"<zzz...@gmail.com>;
????????: 2019??1??18??(??????) ????0:17
??????: "dev@servicecomb.apache.org"<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 <willem.ji...@gmail.com> ??????
> 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 <zzz...@gmail.com> 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?
>
