You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicecomb.apache.org by wjm wjm <zz...@gmail.com> on 2019/02/13 17:27:08 UTC
Re: [discuss][java-chassis] change core mechanism from strong
typetoweak type
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"<zz...@gmail.com>;
> 发送时间: 2019年2月11日(星期一) 下午4:48
> 收件人: "dev"<de...@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"<zz...@gmail.com>;
> > 发送时间: 2019年2月1日(星期五) 中午11:34
> > 收件人: "dev"<de...@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 <wi...@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 <zz...@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?
> > >
Re: [discuss][java-chassis] change core mechanism from strong
typetoweak type
Posted by Willem Jiang <wi...@gmail.com>.
+1 to create a branch to try it.
BTW, we could get some feedback from community if we could write some
user guide for it.
If there is some changes need user to do some migration works, we need
to specify those changes in the document.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Thu, Feb 14, 2019 at 10:49 AM wjm wjm <zz...@gmail.com> wrote:
>
> conclusion:
> before finish all feature of weak type, all related PR will be merged to
> new branch: weak-type
>
> wjm wjm <zz...@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"<zz...@gmail.com>;
> >> 发送时间: 2019年2月11日(星期一) 下午4:48
> >> 收件人: "dev"<de...@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"<zz...@gmail.com>;
> >> > 发送时间: 2019年2月1日(星期五) 中午11:34
> >> > 收件人: "dev"<de...@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 <wi...@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 <zz...@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?
> >> > >
> >
> >
Re: [discuss][java-chassis] change core mechanism from strong
typetoweak type
Posted by wjm wjm <zz...@gmail.com>.
conclusion:
before finish all feature of weak type, all related PR will be merged to
new branch: weak-type
wjm wjm <zz...@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"<zz...@gmail.com>;
>> 发送时间: 2019年2月11日(星期一) 下午4:48
>> 收件人: "dev"<de...@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"<zz...@gmail.com>;
>> > 发送时间: 2019年2月1日(星期五) 中午11:34
>> > 收件人: "dev"<de...@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 <wi...@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 <zz...@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?
>> > >
>
>