grpc-spring
grpc-spring copied to clipboard
grpc-ecosystem
GrpcClientBean doesn't work without a dependency from the @Configuration class
I don't know if this is a bug / shortcoming, or it just needs a documentation improvement. :)
We recently tried to convert to using @GrpcClientBean on a @Configuration class and were surprised that the bean was not created.
We realized, akin to https://github.com/yidongnan/grpc-spring-boot-starter/issues/601 that the post-processor only processes the @Configuration if that @Configuration itself requires the stub. So, the documentation's example that returns a Service @Bean works, and 601 was resolved by injecting and returning the stub.
We expected @GrpcClientBean would "just work" and create a bean, which would be much nicer. It seems a bit silly to inject and return the same stub to work around this. We actually found it was cleaner to simply use @GrpcClient in the @Configuration and return the a @Bean.
Thanks!
According to our tests this should work. https://github.com/yidongnan/grpc-spring-boot-starter/pull/580/files#diff-c89076483c92572e80e9003dbbe2b9189e6c1613fa1f9fe70bdaa2e3e4526695R182-R188
Is it possible that the @GrpcClientBean configuration is processed only after the target configuration? If you define the bean again inside the config, then spring is able to automatically determine the dependency and thus adjust load order, but it cannot do so in the annotation.
You can test that by adding a breakpoint there: https://github.com/yidongnan/grpc-spring-boot-starter/pull/580/files#diff-ca44c434b5f6129cb401918a6d6930047a0d37a3583adf4ce68baae2c851c8efR90
Sorry, I should've expanded that it's quite likely it's an ordering problem: I did step through the post processor and confirmed it doesn't get to our @Configuration.
In our case, the @Configuration uses @Import to drag in the @GrpcService, which appears to be created before the post-processor runs on the Configuration class, thus the application fails to start due to the missing stub dependency before post-processing takes place.
Hello! Is there any update on this issue? I've run into the same exact problem and I can't find a workaround for this.
No I don't have a solution for that yet. If you have an idea, please tell me.
I found a probable solution to this. Instead of post processing the bean, we should switch to pre processing it or use a bean definition post processor.