Move AUTHORIZATION_KEY out of GrpcSecurity to avoid ClassNotFoundException#410
Move AUTHORIZATION_KEY out of GrpcSecurity to avoid ClassNotFoundException#410therepanic wants to merge 2 commits into
AUTHORIZATION_KEY out of GrpcSecurity to avoid ClassNotFoundException#410Conversation
…ption The problem is that we don’t include the `spring-security` module in the client's auto-configuration, which causes a `ClassNotFoundException` when we try to use any of its constants. In our case, this is `GrpcSecurity#AUTHORIZATION_KEY`, and since client modules use it, we need to move it out. In our case, I moved it to a separate internal class called `GrpcMetadataKeys`. Closes: spring-projectsgh-409 Signed-off-by: Andrey Litvitski <andrey1010102008@gmail.com>
therepanic
changed the title
AUTHORIZATION_KEY out of GrpcSecurity to avoid ClassNotFoundException
| */ | ||
| public final class GrpcMetadataKeys { | ||
|
|
||
| private GrpcMetadataKeys() { | ||
| } |
There was a problem hiding this comment.
If anyone has any good suggestions for what to call this class, that would be great. Honestly, I haven't come up with anything for the current one either.
There was a problem hiding this comment.
How about GrpcHeaders? It mirrors Spring's own HttpHeaders convention — a well-known precedent for a constants class holding header key names. Since gRPC's Metadata is the equivalent of HTTP headers, the analogy feels natural. It's short, discoverable, and leaves room to add other standard headers later without the name feeling off. GrpcMetadataKeys isn't bad, but "Keys" is slightly redundant since all the fields are keys by definition.
There was a problem hiding this comment.
Overall, it does look good - I was thinking the same thing myself. Thanks. I think it's definitely better than what we have now, though that’s debatable, but I still agree with you.
Signed-off-by: Andrey Litvitski <andrey1010102008@gmail.com>
bkmuraliext
left a comment
bkmuraliext
left a comment
There was a problem hiding this comment.
Thanks for the quick resolution!
2 participants
The problem is that we don’t include the
spring-securitymodule in the client's auto-configuration, which causes aClassNotFoundExceptionwhen we try to use any of its constants. In our case, this isGrpcSecurity#AUTHORIZATION_KEY, and since client modules use it, we need to move it out. In our case, I moved it to a separate internal class calledGrpcMetadataKeys.Closes: gh-409