[Bug] Application-level service discovery fails when IDL `package` and `java_package` differ

[lqscript]

Pre-check

• I am sure that all the content I provide is in English.

Search before asking

• I had searched in the issues and found no similar issues.

Apache Dubbo Component

Java SDK (apache/dubbo)

Dubbo Version

Dubbo Java 3.3.1
JDK 17
Nacos 2.5.1

Steps to reproduce this issue

Application-level service discovery fails when IDL package and java_package differ

org.apache.dubbo.rpc.RpcException: No provider available from registry RegistryDirectory(registry: 127.0.0.1:8848)-Directory(invokers: 0[], validInvokers: 0[], invokersToReconnect: 0[]) for service org.apache.dubbo.springboot.demo.idl.Greeter on consumer 10.94.201.88 use dubbo version 3.3.1, please check status of providers(disabled, not registered or in blocklist).
at org.apache.dubbo.registry.integration.DynamicDirectory.doList(DynamicDirectory.java:204) ~[dubbo-3.3.1.jar:3.3.1]
at org.apache.dubbo.rpc.cluster.directory.AbstractDirectory.list(AbstractDirectory.java:232) ~[dubbo-3.3.1.jar:3.3.1]
at org.apache.dubbo.rpc.cluster.support.AbstractClusterInvoker.list(AbstractClusterInvoker.java:452) ~[dubbo-3.3.1.jar:3.3.1]
at org.apache.dubbo.rpc.cluster.support.AbstractClusterInvoker.invoke(AbstractClusterInvoker.java:355) ~[dubbo-3.3.1.jar:3.3.1]
at org.apache.dubbo.rpc.cluster.router.RouterSnapshotFilter.invoke(RouterSnapshotFilter.java:46) ~[dubbo-3.3.1.jar:3.3.1]
at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) ~[dubbo-3.3.1.jar:3.3.1]
at org.apache.dubbo.monitor.support.MonitorFilter.invoke(MonitorFilter.java:109) ~[dubbo-3.3.1.jar:3.3.1]
at org.apache.dubbo.rpc.cluster.filter.FilterChainBuilder$CopyOfFilterChainNode.invoke(FilterChainBuilder.java:349) ~[dubbo-3.3.1.jar:3.3.1]

What you expected to happen

The consumer should successfully discover and connect to the service provider, as the java_package option is intended to control the Java package for generated code, and Dubbo's service discovery should correctly use SERVICE_NAME instead of JAVA_SERVICE_NAME

Anything else

No response

Are you willing to submit a pull request to fix on your own?

• Yes I am willing to submit a pull request on my own!

Code of Conduct

• I agree to follow this project's Code of Conduct

[heliang666s]

Thanks for the feedback!@lqscript

When the IDL package and the java_package are different, the service name actually used by the provider and the consumer is inconsistent, leading to service discovery failure.

In short, the problem is that the service is registered with one name, while service discovery uses another name. I will fix this.

[lqscript]

In short, the problem is that the service is registered with one name, while service discovery uses another name. I will fix this.

Thank you for confirming the fix!

Could you please provide an estimated timeline for when this fix might be available?
Specifically, is it targeted for the upcoming 3.3.5 release? If so, do you have an approximate release date for version 3.3.5?

Thanks for your help!

[wcy666103]

Can you provide a sample to github link, I did not succeed to reproduce the problem you said. @lqscript

[lqscript]

Steps to reproduce this issue

Application-level service discovery fails when IDL package and java_package differ

@wcy666103