conclusion: before finish all feature of weak type, all related PR will be merged to new branch: weak-type
wjm wjm <zzz...@gmail.com> 于2019年2月14日周四 上午1:27写道： > > > 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? >> > > > >
