grpc
Expose Server.SERVER_CONTEXT_KEY so that users can implement a Server
It seems like a valid goal to want to implement (extend) a Server - there are only a few implementations in grpc-java and I can imagine quite a few alternatives that I wouldn't expect the grpc-java community to want to support. But if you try it you find that the reflection service doesn't work (and therefore I assume potentially other services) because it accesses the current Server via the Server.SERVER_CONTEXT_KEY. If you don't have access to that key you can't set up the context for the reflection service. There is an escape hatch via InternalServer.SERVER_CONTEXT_KEY but that is clearly documented as "not for use outside grpc-java" and annotated with @Internal.
I can imagine quite a few alternatives that I wouldn't expect the grpc-java community to want to support
Instead of being hypothetical, it sounds like you are implementing your own Server. Is that correct? Would you mind telling us some about it?
https://github.com/grpc/grpc-java/issues/7138 is tracking this already, for use with Armeria, which has its own server implementation.
My specific concern was https://github.com/spring-projects/spring-grpc/issues/19, but I do genuinely think it is more widely applicable than that (as the Armeria example shows nicely). Anything that solves #7138 might solve my problem as well, so I guess I'm keen to see some movement there - there's nothing in 5 years, so not much sign that anyone really cares. However, I'm not convinced that the discussion there was leading in a direction that would solve my problem (the ability to install a stock reflection service in a custom server).
Wouldn't it be easier just to make SERVER_CONTEXT visible? In #7138 the implication is that by design only the reflection service would ever need the SERVER_CONTEXT, so I can see why you might not want to make it public, but that's clearly the easiest way to do it.
Another perspective. If reflection service is really ever the only user of SERVER_CONTEXT then there is no need for a Server abstraction at all in a custom server. My implementation really does nothing but expose the other services to the reflection service. Maybe there's a better way to tell the reflection service which other services are present?
Hi @dsyer, we've discussed this internally and considered several options, including introducing a new, more limited context key, or adopting patterns from other gRPC language implementations like C++ or Go.
We've concluded that the most direct and effective solution is to change the visibility of Server.SERVER_CONTEXT_KEY to protected.
Please let us know if you have any feedback or concerns with this approach for your usecase or any other.
Sounds fine to me. I might somewhat prefer an actual API, e.g. porting an idiom from Go (for instance), but this works for me and it makes sense in Java.