You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@dubbo.apache.org by RQ <lr...@gmail.com> on 2018/11/01 08:34:15 UTC
Advice to the package name refactor of version 2.7.0
Hi Community,
I saw that it is the biggest version since into Apache Community with great
changes which include the package names renamed to *org.apache.dubbo.*
For this part of changes, the compatibility upward is what we care mostly.
Here are two types of scenses we should keep it as legacy interfaces.
1) the interfaces or classes that Dubbo's users use in the application.
Currently, it is ok.
2) the tranfer classes that is serializable in remoting layer. such as
RpcInvocation. We should keep the old package for communication between
vesion 2.7 and version older than 2.7. I saw that this part of refactor
should be think twice in version 2.7.
Please correct my views if I misunderstood.
Regards
Thanks.
Re: Advice to the package name refactor of version 2.7.0
Posted by Jerrick Zhu <je...@apache.org>.
@RQ, your concern is necessary. Other compatible test works need to do, the
more, the better.
On Thu, Nov 1, 2018 at 7:23 PM RQ <lr...@gmail.com> wrote:
> Correct. I just was worried that Dubbo may transfer those object on
> remoting layer because of some mistaked memory .
>
> However, now the worries seems unnecessary after do some testings between
> 2.7.0 and 2.6.3. I just dive into the code of Dubbo, espically the
> classes DubboCodec,
> I found that dubbo remoting protocol don't put RpcInvocation directly as
> byte streams, insteadly only the business object is serialized and others
> metada info is processes as String bytes. So please ingore this
> discussion.
>
> BTW I remembered Dubbo of version 1.x which is only used inside Alibaba put
> DubboRequest/DubboResponse directly and Dubbo2.x is apperantly not this
> problem.
>
> Thanks
> Jeff
>
>
>
>
> Ian Luo <ia...@gmail.com> 于2018年11月1日周四 下午5:51写道：
>
> > So basically you are concerning on inter-op compatibility among the
> > different Dubbo instances?
> >
> > Thanks,
> > -Ian.
> >
> > On Thu, Nov 1, 2018 at 4:34 PM RQ <lr...@gmail.com> wrote:
> >
> >> Hi Community,
> >>
> >> I saw that it is the biggest version since into Apache Community with
> >> great
> >> changes which include the package names renamed to *org.apache.dubbo.*
> >>
> >> For this part of changes, the compatibility upward is what we care
> mostly.
> >> Here are two types of scenses we should keep it as legacy interfaces.
> >> 1) the interfaces or classes that Dubbo's users use in the application.
> >> Currently, it is ok.
> >> 2) the tranfer classes that is serializable in remoting layer. such as
> >> RpcInvocation. We should keep the old package for communication between
> >> vesion 2.7 and version older than 2.7. I saw that this part of refactor
> >> should be think twice in version 2.7.
> >>
> >> Please correct my views if I misunderstood.
> >>
> >> Regards
> >> Thanks.
> >>
> >
>
Re: Advice to the package name refactor of version 2.7.0
Posted by Ian Luo <ia...@gmail.com>.
So have we come up with one conclusion? Is there any further action item we
should follow up with regard to backward compatibility?
Thanks,
-Ian.
On Fri, Nov 2, 2018 at 11:37 AM jun liu <ke...@gmail.com> wrote:
> However, now the worries seems unnecessary after do some testings between
> 2.7.0 and 2.6.3. I just dive into the code of Dubbo, espically the
> classes DubboCodec,
> I found that dubbo remoting protocol don't put RpcInvocation directly as
> byte streams, insteadly only the business object is serialized and others
> metada info is processes as String bytes. So please ingore this
> discussion.
>
>
> That’s correct!
>
> 1) the interfaces or classes that Dubbo's users use in the application.
> Currently, it is ok.
>
>
> Both the API and SPI need to be compatible after repackage. The API part
> is relatively easy since there’re only few APIs exposed to end users, and
> the API interface relies on little internal classes. But when comes to SPI
> it’s a little tricky, most SPI interface’s method signature relies on
> internal classes and this forces us to consider the compatibility of those
> internal classes at the same time.
>
> Best regards,
> Jun
>
> On Nov 1, 2018, at 7:23 PM, RQ <lr...@gmail.com> wrote:
>
> Correct. I just was worried that Dubbo may transfer those object on
> remoting layer because of some mistaked memory .
>
> However, now the worries seems unnecessary after do some testings between
> 2.7.0 and 2.6.3. I just dive into the code of Dubbo, espically the
> classes DubboCodec,
> I found that dubbo remoting protocol don't put RpcInvocation directly as
> byte streams, insteadly only the business object is serialized and others
> metada info is processes as String bytes. So please ingore this
> discussion.
>
> BTW I remembered Dubbo of version 1.x which is only used inside Alibaba put
> DubboRequest/DubboResponse directly and Dubbo2.x is apperantly not this
> problem.
>
> Thanks
> Jeff
>
>
>
>
> Ian Luo <ia...@gmail.com> 于2018年11月1日周四 下午5:51写道：
>
> So basically you are concerning on inter-op compatibility among the
> different Dubbo instances?
>
> Thanks,
> -Ian.
>
> On Thu, Nov 1, 2018 at 4:34 PM RQ <lr...@gmail.com> wrote:
>
> Hi Community,
>
> I saw that it is the biggest version since into Apache Community with
> great
> changes which include the package names renamed to *org.apache.dubbo.*
>
> For this part of changes, the compatibility upward is what we care mostly.
> Here are two types of scenses we should keep it as legacy interfaces.
> 1) the interfaces or classes that Dubbo's users use in the application.
> Currently, it is ok.
> 2) the tranfer classes that is serializable in remoting layer. such as
> RpcInvocation. We should keep the old package for communication between
> vesion 2.7 and version older than 2.7. I saw that this part of refactor
> should be think twice in version 2.7.
>
> Please correct my views if I misunderstood.
>
> Regards
> Thanks.
>
>
>
>
Re: Advice to the package name refactor of version 2.7.0
Posted by jun liu <ke...@gmail.com>.
> However, now the worries seems unnecessary after do some testings between
> 2.7.0 and 2.6.3. I just dive into the code of Dubbo, espically the
> classes DubboCodec,
> I found that dubbo remoting protocol don't put RpcInvocation directly as
> byte streams, insteadly only the business object is serialized and others
> metada info is processes as String bytes. So please ingore this discussion.
That’s correct!
> 1) the interfaces or classes that Dubbo's users use in the application.
> Currently, it is ok.
Both the API and SPI need to be compatible after repackage. The API part is relatively easy since there’re only few APIs exposed to end users, and the API interface relies on little internal classes. But when comes to SPI it’s a little tricky, most SPI interface’s method signature relies on internal classes and this forces us to consider the compatibility of those internal classes at the same time.
Best regards,
Jun
> On Nov 1, 2018, at 7:23 PM, RQ <lr...@gmail.com> wrote:
>
> Correct. I just was worried that Dubbo may transfer those object on
> remoting layer because of some mistaked memory .
>
> However, now the worries seems unnecessary after do some testings between
> 2.7.0 and 2.6.3. I just dive into the code of Dubbo, espically the
> classes DubboCodec,
> I found that dubbo remoting protocol don't put RpcInvocation directly as
> byte streams, insteadly only the business object is serialized and others
> metada info is processes as String bytes. So please ingore this discussion.
>
> BTW I remembered Dubbo of version 1.x which is only used inside Alibaba put
> DubboRequest/DubboResponse directly and Dubbo2.x is apperantly not this
> problem.
>
> Thanks
> Jeff
>
>
>
>
> Ian Luo <ia...@gmail.com> 于2018年11月1日周四 下午5:51写道：
>
>> So basically you are concerning on inter-op compatibility among the
>> different Dubbo instances?
>>
>> Thanks,
>> -Ian.
>>
>> On Thu, Nov 1, 2018 at 4:34 PM RQ <lr...@gmail.com> wrote:
>>
>>> Hi Community,
>>>
>>> I saw that it is the biggest version since into Apache Community with
>>> great
>>> changes which include the package names renamed to *org.apache.dubbo.*
>>>
>>> For this part of changes, the compatibility upward is what we care mostly.
>>> Here are two types of scenses we should keep it as legacy interfaces.
>>> 1) the interfaces or classes that Dubbo's users use in the application.
>>> Currently, it is ok.
>>> 2) the tranfer classes that is serializable in remoting layer. such as
>>> RpcInvocation. We should keep the old package for communication between
>>> vesion 2.7 and version older than 2.7. I saw that this part of refactor
>>> should be think twice in version 2.7.
>>>
>>> Please correct my views if I misunderstood.
>>>
>>> Regards
>>> Thanks.
>>>
>>
Re: Advice to the package name refactor of version 2.7.0
Posted by RQ <lr...@gmail.com>.
Correct. I just was worried that Dubbo may transfer those object on
remoting layer because of some mistaked memory .
However, now the worries seems unnecessary after do some testings between
2.7.0 and 2.6.3. I just dive into the code of Dubbo, espically the
classes DubboCodec,
I found that dubbo remoting protocol don't put RpcInvocation directly as
byte streams, insteadly only the business object is serialized and others
metada info is processes as String bytes. So please ingore this discussion.
BTW I remembered Dubbo of version 1.x which is only used inside Alibaba put
DubboRequest/DubboResponse directly and Dubbo2.x is apperantly not this
problem.
Thanks
Jeff
Ian Luo <ia...@gmail.com> 于2018年11月1日周四 下午5:51写道：
> So basically you are concerning on inter-op compatibility among the
> different Dubbo instances?
>
> Thanks,
> -Ian.
>
> On Thu, Nov 1, 2018 at 4:34 PM RQ <lr...@gmail.com> wrote:
>
>> Hi Community,
>>
>> I saw that it is the biggest version since into Apache Community with
>> great
>> changes which include the package names renamed to *org.apache.dubbo.*
>>
>> For this part of changes, the compatibility upward is what we care mostly.
>> Here are two types of scenses we should keep it as legacy interfaces.
>> 1) the interfaces or classes that Dubbo's users use in the application.
>> Currently, it is ok.
>> 2) the tranfer classes that is serializable in remoting layer. such as
>> RpcInvocation. We should keep the old package for communication between
>> vesion 2.7 and version older than 2.7. I saw that this part of refactor
>> should be think twice in version 2.7.
>>
>> Please correct my views if I misunderstood.
>>
>> Regards
>> Thanks.
>>
>
Re: Advice to the package name refactor of version 2.7.0
Posted by Ian Luo <ia...@gmail.com>.
So basically you are concerning on inter-op compatibility among the
different Dubbo instances?
Thanks,
-Ian.
On Thu, Nov 1, 2018 at 4:34 PM RQ <lr...@gmail.com> wrote:
> Hi Community,
>
> I saw that it is the biggest version since into Apache Community with great
> changes which include the package names renamed to *org.apache.dubbo.*
>
> For this part of changes, the compatibility upward is what we care mostly.
> Here are two types of scenses we should keep it as legacy interfaces.
> 1) the interfaces or classes that Dubbo's users use in the application.
> Currently, it is ok.
> 2) the tranfer classes that is serializable in remoting layer. such as
> RpcInvocation. We should keep the old package for communication between
> vesion 2.7 and version older than 2.7. I saw that this part of refactor
> should be think twice in version 2.7.
>
> Please correct my views if I misunderstood.
>
> Regards
> Thanks.
>