[Bug] dubbo-samples-spring-boot-idl
Pre-check
- [X] I am sure that all the content I provide is in English.
Search before asking
- [X] I had searched in the issues and found no similar issues.
Apache Dubbo Component
Java Samples (apache/dubbo-samples)
Dubbo Version
Dubbo Java: 3.3.0-beta2 Java: 17
I follow the step in dubbo-samples-spring-boot-idl/README.md.
When start provider, curl fail.
curl \
--header "Content-Type: application/json" \
--data '{"name":"Dubbo"}' \
http://localhost:50052/org.apache.dubbo.springboot.demo.idl.Greeter/greet/
{"message":"Invoker not found","status":"404"}
The log in provider is
ERROR [DubboServerHandler-172.16.1.31:50052-thread-5] .tri.h12.AbstractServerTransportListener: -| [DUBBO] server internal error, dubbo version: 3.3.0-beta.2, current host: 172.16.1.31, error code: 99-0. This may be caused by , go to https://dubbo.apache.org/faq/99/0 to find instructions.
org.apache.dubbo.remoting.http12.exception.HttpStatusException: Invoker not found
at org.apache.dubbo.rpc.protocol.tri.h12.AbstractServerTransportListener.doOnMetadata(AbstractServerTransportListener.java:113) ~[dubbo-3.3.0-beta.2.jar:3.3.0-beta.2]
at org.apache.dubbo.rpc.protocol.tri.h12.AbstractServerTransportListener.lambda$onMetadata$0(AbstractServerTransportListener.java:94) ~[dubbo-3.3.0-beta.2.jar:3.3.0-beta.2]
at org.apache.dubbo.common.threadpool.serial.SerializingExecutor.run(SerializingExecutor.java:105) ~[dubbo-3.3.0-beta.2.jar:3.3.0-beta.2]
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at org.apache.dubbo.common.threadlocal.InternalRunnable.run(InternalRunnable.java:39) ~[dubbo-3.3.0-beta.2.jar:3.3.0-beta.2]
at java.base/java.lang.Thread.run(Thread.java:1575) [?:?]
Steps to reproduce this issue
follow the step in README.md.
What you expected to happen
I don't know
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
- [X] I agree to follow this project's Code of Conduct
I'm going to try to fix it.
Your dubbo version is 3.3.0-beta.2, not 3.3.0
Your dubbo version is 3.3.0-beta.2, not 3.3.0
Sorry for the clerical error. I have corrected that I did encounter this problem with 3.0-beta2. However, I also tested 3.3.0 and encountered the same problem.
I tested 3.3.0 and it work fine. 3.0-beta2 version not support slash matching.
Are you also unable to start it in IDEA? Currently, I haven't encountered any issues using version 3.3.0 in IDEA.@11D-Beyonder
Are you also unable to start it in IDEA? Currently, I haven't encountered any issues using version 3.3.0 in IDEA.@11D-Beyonder
I did not find the cause of the problem, but there are some clues to offer.
I came to the conclusion that the values of package and option java_package in the IDL file must be the same.
For example, if the IDL file is like this:
package org.apache.dubbo.springboot.demo.idl;
option java_package = "org.apache.dubbo.springboot.demo.idl";
or the java_package is not specified, the request to http://localhost:50052/org.apache.dubbo.springboot.demo.idl.Greeter/greet/ works fine.
However, if the java_package is specified and don't equal to the value of package, the request will fail. For example, if the IDL file is like this:
package org.apache.dubbo.springboot.demo.idl;
option java_package = "org.apache.dubbo.springboot.demo.api";
The request to both http://localhost:50052/org.apache.dubbo.springboot.demo.idl.Greeter/greet/ and http://localhost:50052/org.apache.dubbo.springboot.demo.api.Greeter/greet/ will fail.
I'm a beginner to Dubbo, and I don't know if this is a Bug or a design consideration. Hope to get some answers, thank you. @heliang666s
This is not a bug; it is intentionally designed this way. Since proto files are used, the protoc compiler from the Dubbo plugin will be invoked during the compilation phase to generate Java files. For the specific implementation, refer to org.apache.dubbo.gen.AbstractGenerator.
In simple terms, you need to ensure that the import paths in both the provider and consumer match the java_package exactly. The reason you encountered errors after modifying the java_package is that the original import paths were not updated accordingly. As a result, the import statements could not find the corresponding files, causing the startup to fail.
@11D-Beyonder