Adding interceptors to TransportChannelProvider about sdk-platform-java HOT 3 OPEN

Hi @nwbirnie,
This looks doable, since TransportChannelProvider is @InternalExtensionOnly and GrpcInterceptorProvider and LocalChannelProvider are @BetaApi (so we can add extensions without formally breaking backward compatibility).

At the same time, this will also require "shading" io.grpc.ClientInterceptor (wrapping it in some other class, so TransportChannelProvider can stay unaware of grpc), which is going to look sloppy. Or, making some empty TransportInterceptorProvider (without methods) and do explicit casting inside implementations, which is also bad oop design. There are must be other options as well but I can't think of any better ones right now.

So if there is a strong reason to do it we definitely can do it, but otherwise I think it would be better to not do it as it somewhat worsens gax's surface.

from sdk-platform-java.

So the motivation here is testing. I'm using MockServiceHelper and LocalChannelProvider to test headers being sent in RPCs. I'd like to expand the test scope to include interceptors. Is there another way to test that interceptors are being invoked in unit tests?

In terms of the shading approach, I don't think this is so bad - we're effectively doing the same thing for headers/endpoints etc. except those happen to be native types. Increasing decoupling and adding features to GAX seems like a good option in general.

from sdk-platform-java.

@vam-google Do you have any updated thoughts on this?

from sdk-platform-java.