is there a plan to change alibaba-dubbo dependency to apache-dubbo?

[geercode]

• Question
  since all projects have been transfered to apache incubator,is there any paln to support dubbo 2.7+ ?
  I have tried using dubbo-spring-boot-starter 2.7,the dependency of alibaba LoggerFactory is nologger supported.

[codefromthecrypt]

in general we dont have plans unless users ask for something. are you able to help migrate this to apache dubbo? is it possible to make it work with both libraries (we dont want to break people who haven't moved yet)

…

On Wed, Feb 20, 2019, 7:26 PM jerryniu ***@***.*** wrote: - Question since all projects have been transfered to apache incubator,is there any paln to support dubbo 2.7+ ? I have tried using dubbo-spring-boot-starter 2.7,the dependency of alibaba LoggerFactory is nologger supported. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#867>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD612uQruAsqEmcybPx9Gdsd3hXv9mOks5vPTDrgaJpZM4bFAIf> .

[geercode]

I think dubbo will be at a unsatble circumstance for a very long time.Between 2.6 and 2.7,it's very much like just some packages' name changing of the same content.I suppose using osgi to make them work together is a better way.At the same time,dubbo is just under maintainance.The rest protocol which 2.6 is already supported is a key module.Before dubbo 3.0,there would not be too many developers would use it.

[codefromthecrypt]

feel free to chat with me here I am ready to have a look at brave stuff soon https://gitter.im/openzipkin/zipkin

[codefromthecrypt]

this is a problem as the code is very different.. 2.6.5 and 2.7.0 removed classes.. that can be ok but now we have to figure out what to do.

[codefromthecrypt]

It appears the dubbo team are deciding whether to stop working with us based on the fact that will still support their old clients. I am very disappointed at this behavior. I hope they change https://lists.apache.org/thread.html/4ab3582245cb7daa79becaa7f644089f93da08b3a8ae0c3c90e89a1c@%3Cdev.dubbo.apache.org%3E

[codefromthecrypt]

we can't break compat of the old dubbo users because we are nice. to figure out what to do can be easy or hard depending on bytecode compat. For example, grpc we were able to make a wide version range work because the core classes are still compatible from version 1.3.

However, I don't think this is the case with dubbo. version 2.7 seems not compatible with 2.6 unless you revert to reflection. this likely means we need a separate artifact.

For example, we can start brave-instrumentation-apache-dubbo or a different scheme like brave-instrumentation-dubbo-2.7 as the dubbo team also plan to break compatibility again in version 3.

The challenge here is thinking and planning only.. which route do we take? If so, which naming convention do we use? we will be stuck with it, so it is worthwhile having the thinking exercise.

[ralf0131]

Hi,

this is a problem as the code is very different.. 2.6.5 and 2.7.0 removed classes..

2.7.0 renames the package name to org.apache, but the goal is not to break the compatibility. Instead, the Dubbo community would like to maintain the compatibility as much as possible, but it is known that it is not 100% compatible. Yes, the community has received several reports of incompatibility. If there is an issue, please file it so the community would take a look and hopefully to fix it.

It appears the dubbo team are deciding whether to stop working with us based on the fact that will still support their old clients. I am very disappointed at this behavior. I hope they change https://lists.apache.org/thread.html/4ab3582245cb7daa79becaa7f644089f93da08b3a8ae0c3c90e89a1c@%3Cdev.dubbo.apache.org%3E

Not sure what you are talking about, Dubbo community never decide to stop working with some other community. Supporting open tracing does not mean stop working with zipkin.

For example, we can start brave-instrumentation-apache-dubbo or a different scheme like brave-instrumentation-dubbo-2.7 as the dubbo team also plan to break compatibility again in version 3.

The Dubbo community never plan to break compatibility again in Dubbo 3.x. Instead, compatibility should be always focused. So please stop speculating and feel free to discuss with the community via Email or Github issue.

[beiwei30]

@geercode your particular issue may caused by dubbo-spring-boot-starter 2.7 itself instead of dubbo 2.7.0. Like @ralf0131 says, we always keep backward compatibility in mind. We will fully examine how dubbo 2.7 works well with Zipkin with no doubt. Stay tuned.

[codefromthecrypt]

literally the opentracing thread includes rationale that "async call not work in zipkin plugin." this is what I mean. there was no issue raised here or support of any kind. Now, because I call it out some people now participate. I'm glad you are now, but it is strange to me that not only did you not see that there was a relationship between that thread and perceived problems with zipkin integration, but also find my mentioning anything about it out of line.

…

On Mon, Mar 25, 2019 at 4:30 PM Huxing Zhang ***@***.***> wrote: Hi, this is a problem as the code is very different.. 2.6.5 and 2.7.0 removed classes.. 2.7.0 renames the package name to org.apache, but the goal is not to break the compatibility. Instead, the Dubbo community would like to maintain the compatibility as much as possible, but it is known that it is not 100% compatible. Yes, the community has received several reports of incompatibility. If there is an issue, please file it so the community would take a look and hopefully to fix it. It appears the dubbo team are deciding whether to stop working with us based on the fact that will still support their old clients. I am very disappointed at this behavior. I hope they change https://lists.apache.org/thread.html/4ab3582245cb7daa79becaa7f644089f93da08b3a8ae0c3c90e89a1c@%3Cdev.dubbo.apache.org%3E Not sure what you are talking about, Dubbo community never decide to stop working with some other community. Supporting open tracing does not mean stop working with zipkin. For example, we can start brave-instrumentation-apache-dubbo or a different scheme like brave-instrumentation-dubbo-2.7 as the dubbo team also plan to break compatibility again in version 3. The Dubbo community never plan to break compatibility again in Dubbo 3.x. Instead, compatibility should be always focused. So please stop speculating and feel free to discuss with the community via Email or Github issue. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#867 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD619tPWCsSuJSuR3HB1YgcnkveDU3Vks5vaIkSgaJpZM4bFAIf> .

[codefromthecrypt]

Also, I am glad that 3.0 will be binary compatible with 2.7. I mistakenly took "Before dubbo 3.0,there would not be too many developers would use it." that this wouldn't be the case

[codefromthecrypt]

@ralf0131 ps are you hinting that we should be able to serve both alibaba (2.6.x) and apache (2.7) in the same classpath? I did try this early this month but ran into snags. It is good to know that it is considered a bug if we can't. This means we can consider co-hosting the instrumentation in the same artifact.

[codefromthecrypt]

What I didn't report earlier this month was precisely the dubbo 2.7 and 2.6.6 compatibility problem. I incorrectly assumed it wasn't planned to work together in the same classpath. Right now they cannot co-exist, but I guess it is a bug.

problem 1: incompatible types returned from com.alibaba.dubbo.rpc.RpcContext.getContext()

    RpcContext rpcContext = RpcContext.getContext();

problem 2: incompatible types returned from org.apache.dubbo.common.Node.getUrl()

      isOneway = RpcUtils.isOneway(invoker.getUrl(), invocation);

The easiest way to see this problem is adding the following to instrumentation/dubbo/pom.xml

    <dependency>
      <groupId>org.apache.dubbo</groupId>
      <artifactId>dubbo</artifactId>
      <version>2.7.0</version>
      <optional>true</optional>
    </dependency>

@beiwei30 should this go into your issue then? or is it already solved?

[ralf0131]

Before dubbo 3.0,there would not be too many developers would use it

What @geercode stated here has nothing to do with the Apache Dubbo community and that statement is not true.

[ralf0131]

literally the opentracing thread includes rationale that "async call not work in zipkin plugin." this is what I mean. there was no issue raised here or support of any kind. Now, because I call it out some people now participate. I'm glad you are now, but it is strange to me that not only did you not see that there was a relationship between that thread and perceived problems with zipkin integration, but also find my mentioning anything about it out of line.

I've missed that message, I agree that this kind of issue should be reported to Zipkin community as well, and after some dig I found this issue is still waiting to be fixed. Maybe there should be some refactoring on the Zipkin plugin side in order to make it work.