-
Notifications
You must be signed in to change notification settings - Fork 837
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stub creation has no fallback #410
Comments
Thanks for reporting this issue. |
Thank you for looking into this. I'll have to create a sample project, since I discovered the issue in a work project that I can't share for obvious reasons. But I'd think if you had/wrote any tests for the Let me know if you still want me to create a sample project, or if the tests I suggested would be sufficient enough to proceed. |
As a workaround, you could add a |
I've downgraded to |
We are sorry, that this update broke things for you. I talked to the developers of grpc-java and I was told, that the private constructors are considered internal api and will probably be removed in a future release (for grpc-java that is). That's the reason, why we didn't include the fallback code in the new version of our code. The issue is not that we don't have tests for the new code (we actually have them), the issue is that we didn't have tests that actually used the fallback code. It has been pure chance that it actually worked for grpc-kotlin before. I guess it's time that we add official support for it.
We use the example projects as a way to identify regressions, so having a kotlin project would definitely help with that. The next release will contain a fallback that will first try your suggested search for a matching |
I'm happy to provide a sample project, and help you as I can, I just don't know how you'd integrate a separate Gradle project in your automated tests. That's why I'm little apprehensive in creating a throwaway project. As for the constructor issue, I think there's a misunderstanding here. For the generated Java classes, the constructor is So the issue isn't really with using Kotlin, it's the absence of |
Which actually brings me to my first question: Does the grpc-kotlin generator require or generate the grpc-java stub methods/classes? |
Yes, they do, |
It won't run as part of the core build. It will be run using |
OK, I'll create a Kotlin client project this evening. |
I created https://github.com/yidongnan/grpc-spring-boot-starter/pull/412 that is a standalone project using Kotlin and grpc-kotlin. If you change the grpc-spring-boot-starter version from 2.10.0.RELEASE to 2.9.0.RELEASE, the test passes. I hope this helps. |
i have same problem with version 2.10.0. RELEASE, i used Java library.
i downgraded to 2.9.0.RELEASE and nothing problem. |
@osaka911 The root cause of this issue has been found, and documented above. What is the base class for your |
I believe this to be a blocking regression issue.
The context
Use grpc-kotlin library to make gRPC calls.
The bug
In
grpc-spring-boot-starter:v2.9.0.RELEASE
,GrpcClientBeanPostProcessor
tries to figure out (reflectively) the appropriatestatic
method to create a stub. If it fails, it falls back to using the constructor (which is assumed asprivate
, but may not be, as in the case ofgrpc-kotlin
). Ingrpc-spring-boot-starter:v2.10.0.RELEASE
, the fallback is not present, and thus, the stub injection blows up with an errorjava.lang.IllegalArgumentException: Unsupported stub type
. See the class hierarchy below:The problem, that already existed in
grpc-spring-boot-starter:v2.9.0.RELEASE
but was hidden by the fallback, is that there's no code inGrpcClientBeanPostProcessor
to check forAbstractStub
subclasses. I think the fallback to using the constructor directly is ok, as seen in the example code, and should not be removed. However, the constructor can be assumedpublic
and there's no need to try to change its visibility.Note that this too, will fail, if grpc-kotlin makes the constructor
private
and adds a static method (I created grpc/grpc-kotlin#163). The futureproof way to fix this is not to check for the stub type, but to check for the existence of static methods namednew*Stub
, and then comparing the return types with the declared stub type.Stacktrace and logs
Steps to Reproduce
N/A
The application's environment
Which versions do you use?
Additional context
The text was updated successfully, but these errors were encountered: