bismy <bi...@qq.com> 于2019年2月12日周二 下午3:19写道: > - javaTypes > in org.apache.servicecomb.swagger.invocation.response.ResponseMeta not > always avaiable, maybe will affect filters and handlers > ---- This is rarely used, I think. > yes, but app market already used it.
> - > org.apache.servicecomb.swagger.invocation.SwaggerInvocation#swaggerArguments > not always avaiable, or will be deleted , maybe will > affect > filters and handlers > ---- If we can provide a method to get the arguments if users > need them in some common scenarios? Such as primitive parameters. > yes, will provide getByParameterName, but it's belongs to interface changed > - highway will upgrade to highway2, because highway codec is not > compatible to standard protobuf, this will cause > consumer and producer must upgrade together when they use highway. > ---- If user still use highway, not highway2(That is we keep the > old implementation), is it possible? > almost impossible, because too expensive. we should remain dynamic create class or rewrite protoStuff codec based on weak type > > > ------------------ 原始邮件 ------------------ > 发件人: "zzzwjm"<zzz...@gmail.com>; > 发送时间: 2019年2月11日(星期一) 下午4:48 > 收件人: "dev"<dev@servicecomb.apache.org>; > > 主题: Re: [discuss][java-chassis] change core mechanism from strong > typetoweak type > > > > after change to weak type, not compatible include following at least: > > - javaTypes > in org.apache.servicecomb.swagger.invocation.response.ResponseMeta not > always avaiable, maybe will affect filters and handlers > - > org.apache.servicecomb.swagger.invocation.SwaggerInvocation#swaggerArguments > not always avaiable, or will be deleted , maybe will > affect > filters and handlers > - highway will upgrade to highway2, because highway codec is not > compatible to standard protobuf, this will cause > consumer and producer must upgrade together when they use highway. > > > maybe other not comptible functions..... > > bismy <bi...@qq.com> 于2019年2月11日周一 上午9:50写道: > > > Can you list notable changes that users need to know when upgrade to the > > new version? This can help us to make the decision. > > > > > > In my opinion, if users upgrade to new version, and they can make some > > code change without lose any function, we can go forward this PR. Plus > for > > running applications, one microservice upgrade does not cause others > > (providers/consumers) to upgrade is necessary. > > > > > > If the two conditions mentioned above not match, we need to create a new > > branch to merge this PR. > > ------------------ 原始邮件 ------------------ > > 发件人: "zzzwjm"<zzz...@gmail.com>; > > 发送时间: 2019年2月1日(星期五) 中午11:34 > > 收件人: "dev"<dev@servicecomb.apache.org>; > > > > 主题: Re: [discuss][java-chassis] change core mechanism from strong type > > toweak type > > > > > > > > useful for all scenes, i just write edge as a example, because edge has > the > > most serious problem with jvm meta overflow > > edge and normal microservice share the same mechanism > > > > compatible problem include: > > > > - some customer's handler and filter customization maybe need some > > change, because: > > - > > > org.apache.servicecomb.swagger.invocation.SwaggerInvocation#swaggerArguments > > will change name or removed > > - java datatype in operationMeta will not always present > > - abandon highway, change to highway2, because highway codec based on > > ProtoStuff, ProtoStuff depend on strong type and not compatible to > > ProtoBuf > > for some datatye > > - ...... > > > > > > > > Willem Jiang <willem.ji...@gmail.com> 于2019年1月31日周四 下午9:07写道: > > > > > What's the difference between the strong type and weak type? > > > From the mail I can tell the weak type is useful in the edge service, > > > can we just us it in the edge service? > > > > > > BTW, We need to be care if there is a API break change, heading to > > > version 2.0.0 is a good way, is there any other big change we need to > > > make in the java-chassis 2.0.0? > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Wed, Jan 30, 2019 at 8:39 PM wjm wjm <zzz...@gmail.com> wrote: > > > > > > > > currently, core mechanism is strong type > > > > that caused to generate class dynamically in many special > classloader, > > > it's > > > > dangerous: > > > > > > > > - need to generate almost all business classes in edge, maybe > cause > > > jvm > > > > meta overflow > > > > - unable to support advanced features of swagger, such as allOf > > > > - caused some unnecessary data model convert > > > > > > > > > > > > so we need to change core mechanism from strong type to weak type, we > > had > > > > disscussed this before. > > > > > > > > the new problem is, because the two mechanism is not compatible, we > > must > > > > make decisions about: > > > > > > > > - if plan it to be version 2.0.0 > > > > - if we create branch for it > > > > - if not create branch, then same functions will have two > > implements, > > > > how to named the package > > > > - if create branch, then i will replace old implement directly, > > that > > > > cause compile problems > > > > > > > > any suggestion? > > >