servicecomb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From wjm wjm <zzz...@gmail.com>
Subject Re: [discuss][java-chassis] change core mechanism from strong typetoweak type
Date Wed, 13 Feb 2019 17:27:08 GMT
bismy <bismy@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"<zzzwjm@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 <bismy@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"<zzzwjm@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.jiang@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 <zzzwjm@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?
> > >

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message