Allow @GRpcService on @Bean factory methods

[hleibenko-attentive]

I wonder if it's high effort to implement such feature

For example we use a mix of dependency-injection approaches/recommendations, as the result, we already have a factory that produces GrpcServices. Would be nice if we could reuse everywhere and make sure that our tests use the same code/config as prod code

@GRpcService
@Bean 
public MyGrpcService myGrpcService(ApplicationFactory factory) {
    factory.getMyGrpcService()
}

[jvmlet]

I need to check this, meanwhile can you please try with standard ObjectProvider/ObjectFactory interface?

[hleibenko-attentive]

hi jvmlet, thanks for the quick reply, I'm not sure if ObjectProvider applicable in our case, let me give you more details , maybe you can help me to understand this

For prod we use everything-spring, but for our tests (an integration-like suite) we use an alternative IoC approach, we have a bunch of code that wires all the dependencies together (similar to Dagger). It's nice but I feel that we are missing out on the opportunity to reuse the same code for testing and for prod. If there were an approach that allowed us to avoid reliance on the @GRpcService annotation on top of the class and we could register grpc instances "programmatically" it would've resolved the issue. For example we could rely on our internal non spring factories to produce instances of grpc services and use only a few spring configuration classes to actually expose them as part of our grpc server. Unfortunately, the other way around (making the internal factories aware of / dependent on spring types such of ObjectProvides) is not an option because the point of the the internal factories is to avoid spring and make everything fast for testing

[jvmlet]

As I understand, you want to implement manual discovery/registration of grpc services, it's being done by GRpcServicesRegistry, if I make this bean as ConditionalOnMissingBean(GRpcServicesRegistry.class), will it help you ?

[hleibenko-attentive]

we actually like autoregistation , would updating GRpcService to be @Target({ElementType.TYPE,ElementType.METHOD }) instead of @Target(ElementType.TYPE) be an option?

[hleibenko-attentive]

this way we would be able to use it just as you are using @GRpcGlobalInterceptor here

[jvmlet]

With SB 2.5.x this should work OOTB. Will try to confirm tomorrow

[bitbrain]

@jvmlet within this code https://github.com/LogNet/grpc-spring-boot-starter/blob/19fc75177a40d5b7b64cf6dcde81dfd4bb9a5eb9/grpc-spring-boot-starter/src/main/java/org/lognet/springboot/grpc/autoconfigure/OnMissingErrorHandlerCondition.java#L29 we are using getBeanClassName which does not work on @Bean factory methods. I will raise a pull request to fix this now.

[MCLonips]

Any updates on this thread? We have the problem that we want to share implementations of a grpc-Controller in a spring-boot-app and inside a quarkus app. But declaring @GRpcService at the controller implementation leads to unnecessary dependencies in the quarkus app.

Providing @GRpcService at class level woul really help us :-)