-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for custom attributes in NameResolver.Helper #5562
Milestone
Comments
ST-DDT
changed the title
Add support for custom attributes in NameResolver.Factory
Add support for custom attributes in NameResolver.Helper
Apr 8, 2019
We want to have a NameResolverRegistry to mirror LoadBalancerRegistry. Notably, it would have a Would that work even better than trying to plumb Attributes through the NameResolver? |
Yes, that would work perfectly fine. |
ejona86
added a commit
to ejona86/grpc-java
that referenced
this issue
Apr 12, 2019
NameResolverRegistry takes on all the logic previously in NameResolverProvider. But it also allows manual registration of NameResolvers, which is useful when the providers have complex construction or need objects injected into them. This also avoids a circular dependency during class loading since previously loading any Provider searched for all Providers via ClassLoader since ClassLoader handling was static within the parent class. Fixes grpc#5562
ejona86
added a commit
to ejona86/grpc-java
that referenced
this issue
Apr 19, 2019
NameResolverRegistry takes on all the logic previously in NameResolverProvider. But it also allows manual registration of NameResolvers, which is useful when the providers have complex construction or need objects injected into them. This also avoids a circular dependency during class loading since previously loading any Provider searched for all Providers via ClassLoader since ClassLoader handling was static within the parent class. Fixes grpc#5562
ejona86
added a commit
that referenced
this issue
Apr 22, 2019
NameResolverRegistry takes on all the logic previously in NameResolverProvider. But it also allows manual registration of NameResolvers, which is useful when the providers have complex construction or need objects injected into them. This also avoids a circular dependency during class loading since previously loading any Provider searched for all Providers via ClassLoader since ClassLoader handling was static within the parent class. Fixes #5562
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of gRPC are you using?
1.19
Related
Feature-Request
The java service loader API has the drawback that it creates instances without context.
In my case it creates
NameResolverProvider
s without spring's dependency injection.With the Attributes API that present up to and including 1.18, I was able to pipe the potentially required beans/config to the actual implementations. Now this path is blocked.
Lets assume we have a config which contains the "service discovery server URL".
Somehow we need to push this tiny piece of runtime only information into the ServiceDiscoveryNameResolver(Factory).
We now (1.19 or later) have basically three options:
This will soon become a nightmare for every maintainer as more and more properties needs to be encoded for the potential case that one provider needs them. This option cannot pass more complex instances such as a
RestTemplate
orHttpRequestOptions
.Well you can pass anything through static variables, but using them to transfer something stateful sounds like a bad idea and fails as soon as the load order is slightly of or multiple distinct instances of gprc-services run in the same JVM (to save some memory).
Prior to 1.19 we also had a forth option:
In yidongnan/grpc-spring-boot-starter I use the third variant, but also considered using the forth variant because it would free my code from conditional wrappers and would allow adding other contextual name resolvers more easily.
ConfigMappedNameResolverFactory (springNameResolver)
I currently don't use the extra attributes, but I considered it for future simplifications.
The
DiscoveryClientResolverFactory
is currently my only contextual name resolver. In this example I could request theDiscoveryClient
bean from theapplicationContext
instead of passing it in the constructor.IMO it would be best to revert the helper back to the unspecific attributes or add an optional, mutable and unspecific attributes to the helper because:
getCustomAttributes() : Object
would fail as soon as another layer of context is added on top.The text was updated successfully, but these errors were encountered: