-
Notifications
You must be signed in to change notification settings - Fork 58
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
feat: Full Endpoint Resolution from EndpointContext #2313
Conversation
} else if (!Strings.isNullOrEmpty(endpoint)) { | ||
audienceString = endpoint; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confirm this behavior is correct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The GDC-H audienceString's endpoint should match with endpoint set inside the TransportChannelProvider.
The logic is that for a GDC-H flow, the resolved endpoint will be either the clientsettings endpoint or transportchannel endpoint if set. This matches the behavior below as either the clientSettings or transportchannel's endpoint.
ClientSettings will only be set to the Transportchannel if it doesn't have an endpoint already set by the user. EndpointContext's resolvedEndpoint already takes this into consideration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The else block is kept as the custom endpoint could be set as "" (empty string). URI.create("")
does not throw an exception, so it is caught in this else block.
3bc8392
to
bdbaab1
Compare
throw new IllegalArgumentException("The universe domain value cannot be empty."); | ||
} | ||
// Universe Domain defaults to the GDU if it's not provided by the user. | ||
resolvedUniverseDomain = universeDomain() != null ? universeDomain() : GOOGLE_DEFAULT_UNIVERSE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we default the universe domain to GDU instead of introducing a new field resolvedUniverseDomain
? In addition, can we move the universe domain resolution logic to build()
? The validation above can be done there as well. I know this method is already being called from build()
, but determining universe domain feels like a separate step that should be done before determining endpoint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, will do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we default the universe domain to GDU instead of introducing a new field resolvedUniverseDomain?
Do we still need resolvedUniverseDomain
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I planned to remove it and use GDU by default, but I think there is a small edge case. Found it when running the IT GDCH tests, specifically regarding:
sdk-platform-java/showcase/gapic-showcase/src/test/java/com/google/showcase/v1beta1/it/ITGdch.java
Lines 189 to 192 in 3d885ba
settings = settings.toBuilder().setGdchApiAudience(testAudience).build(); | |
context = ClientContext.create(settings); | |
stubSettings = EchoStubSettings.newBuilder(context).build(); | |
client = EchoClient.create(stubSettings.createStub()); |
L190's ClientContext.create(...) creates an EndpointContext. Nothing is passed in via the universeDomain getter as it's a GDC-H flow, but the universe domain would be set to GDU by default.
L192's createStub() will create the Stub and it takes the params from the ClientContext (which has the GDU as the universe domain) and it will fail the GDC-H logic block.
I'm not sure the way that the IT GDC-H tests are set is makes sense (or if I'm missing something), specifically regarding explicitly creating the ClientSettings -> ClientContext -> StubSettings steps. But I think it shows that doing this is possible by the user.
I learned towards keeping the resolvedUniverseDomain so that the user can differentiate between what the user configuration and what the resolved universe domain is (null, GDU, user configured). This would possibly be done in a future enhancement as a getter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I learned towards keeping the resolvedUniverseDomain so that the user can differentiate between what the user configuration and what the resolved universe domain is (null, GDU, user configured)
Makes sense. Please see my new comments regarding resolvedUniverseDomain
, I think it's better to make it not nullable, but maybe there is a edge case preventing us from doing so.
@@ -104,6 +104,9 @@ public abstract class ClientContext { | |||
@Nullable | |||
abstract String getServiceName(); | |||
|
|||
@Nullable | |||
public abstract String getUniverseDomain(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to expose a getter for universe domain? I guess it is for StubSettings
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is for the for logic that connects ClientContext <-> StubSettings. I believe it was added a while back for reasons and this getter is (ideally) only for StubSettings usage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, for every new ClientSettings
, it seems that we have to duplicate it in StubSettings
as well.
gax-java/gax/src/main/java/com/google/api/gax/rpc/EndpointContext.java
Outdated
Show resolved
Hide resolved
gax-java/gax/src/main/java/com/google/api/gax/rpc/EndpointContext.java
Outdated
Show resolved
Hide resolved
gax-java/gax/src/main/java/com/google/api/gax/rpc/EndpointContext.java
Outdated
Show resolved
Hide resolved
private String determineUniverseDomain() { | ||
// Do not set the universe domain for GDC-H | ||
if (usingGDCH()) { | ||
return null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we return GDU here instead of null? And make resolvedUniverseDomain
not nullable? I see that resolvedUniverseDomain
is used multiple places later, it is probably good now but may easily introduce null pointer exceptions later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The resolvedUniverseDomain is what is stored in the ClientContext and StubSettings (not the user configured universe domain). Following the GDC-H case above, it's possible to manually construct the StubSettings and ClientContext and each would construct the EndpointContext. If we set the resolvedUniverseDomain to the GDU by default, then it would fail every case as the Universe Domain can never be set for GDC-H (must be null).
--
Edit: I updated the logic so that it is non-null
throw new IllegalArgumentException( | ||
"Universe domain configuration is incompatible with GDC-H"); | ||
} else if (customEndpoint == null) { | ||
return buildEndpointTemplate(serviceName(), GOOGLE_DEFAULT_UNIVERSE); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use resolvedUniverseDomain
if we default it to GDU?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated. Thanks!
throw new IllegalArgumentException("The universe domain value cannot be empty."); | ||
} | ||
// Universe Domain defaults to the GDU if it's not provided by the user. | ||
resolvedUniverseDomain = universeDomain() != null ? universeDomain() : GOOGLE_DEFAULT_UNIVERSE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I learned towards keeping the resolvedUniverseDomain so that the user can differentiate between what the user configuration and what the resolved universe domain is (null, GDU, user configured)
Makes sense. Please see my new comments regarding resolvedUniverseDomain
, I think it's better to make it not nullable, but maybe there is a edge case preventing us from doing so.
@@ -104,6 +104,9 @@ public abstract class ClientContext { | |||
@Nullable | |||
abstract String getServiceName(); | |||
|
|||
@Nullable | |||
public abstract String getUniverseDomain(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, for every new ClientSettings
, it seems that we have to duplicate it in StubSettings
as well.
return new AutoValue_EndpointContext.Builder().setSwitchToMtlsEndpointAllowed(false); | ||
} | ||
@Nullable | ||
public abstract String resolvedUniverseDomain(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we expect resolvedUniverseDomain
to be used by anything outside of this class? If not, I think we can make the this method and the setter in the builder package private (I don't think we can make it completed private though due to AutoValue limitations).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually on second thought, I think you're right. I've made it package private. I originally used it as the value I set in the ClientContext, but I can just follow what we are doing with endpoint and pass the user set values for that. This way the resolvedUniverseDomain can be non-null (default to GDU).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Please add Javadocs before merging.
@@ -48,6 +51,9 @@ public abstract class EndpointContext { | |||
@Nullable | |||
public abstract String serviceName(); | |||
|
|||
@Nullable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add some Javadocs to the getter here and setter below
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. Thanks
|
|
Features: