-
Notifications
You must be signed in to change notification settings - Fork 915
Add support for generating waiter acceptors. #2036
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
Conversation
.add(")"); | ||
break; | ||
case "pathAny": | ||
result.add("OnResponseAcceptor(") |
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 this be move out of the switch? Looks like we always add except for status
which doesn't use the result
that's being built
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.
+1
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, the error path is different, so I can't do this.
codegen/src/main/java/software/amazon/awssdk/codegen/poet/waiters/BaseWaiterClassSpec.java
Outdated
Show resolved
Hide resolved
codegen/src/main/java/software/amazon/awssdk/codegen/poet/waiters/BaseWaiterClassSpec.java
Show resolved
Hide resolved
codegen/src/main/java/software/amazon/awssdk/codegen/poet/waiters/JmesPathInterpreter.java
Outdated
Show resolved
Hide resolved
codegen/src/test/java/software/amazon/awssdk/codegen/poet/waiters/JmesPathInterpreterTest.java
Outdated
Show resolved
Hide resolved
* Contains classes used at runtime by the code generator classes for waiter acceptors generated from JMESPath expressions. | ||
*/ | ||
@SdkProtectedApi | ||
public final class WaitersRuntime { |
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 add tests for the runtime?
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.
That's a good idea, but I'm wondering how that will jive when we move the runtime to being copied into each of the service clients. I was hoping testing it in the context it's used (i.e. testing the generated waiters and making sure they worked, which indirectly tests the runtime) would be sufficient to side-step this problem. Do you have any ideas on how to make that work?
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 you have any ideas on how to make that work?
I think if we just accessed a WaitersRuntime
class from within codegen-generated-classes-test
that could work.
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.
That makes sense 👍
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.
Looks like JMESPath has a suite of acceptance tests. Can we integrate them into our implementation somehow?
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.
For the JMESPath acceptance tests, there's two issues:
- We don't support all of JMESPath, so we'd have to pick out the tests that we do support and use those, or expand to support all of JMESPath.
- Those tests are written to work against JSON, and our implementation works against generated SdkPojos. To bridge the gap, we'd have to build a test harness to map the two, as well as parse and execute the acceptance tests against the SdkPojo -> JSON mapping.
I think that would add another week or more to the task. While I don't mind us doing it, it might be a bit much to do as part of this code review.
0041c0b
to
16b7fb7
Compare
Yep I think doing that as a separate task is fine; I imagine the middle layer would look something like our protocol test harness. We should integrate any tests that we can to give us extra confidence :). |
16b7fb7
to
89a1952
Compare
This required the following changes: 1. Added a JMES Path interpreter based on the JMES Path parser from a previous commit. This interpreter is in the code generator and creates the Java instructions for executing the acceptor logic. 2. Added the code generator logic for specifying the acceptors. 3. Added a Waiters runtime that is currently shared between all service clients, used by the acceptors of all services. 4. Added a "MemberName" field to the SDK field metadata, so that it can be referenced by the waiter code (waiters refer to the member names from the C2J). 5. Added tests for the two most complex waiter classes: AutoScaling and ECS 6. Added support for acceptors matching supertypes of the response type. Waiters should mostly be working now, but there are a few remaining tasks: 1. There's a WaitersRuntime component in sdk-core that should be copied to each of the service to remove them as a protected API. 2. Waiters currently only support the JMESPath syntax currently used by services. We should add support for some of the other 'easier' JMESPath syntax so that we're future-compatible with more waiters.
89a1952
to
5c607cb
Compare
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 remember to add a task in the backlog if we don't have one for integrating the JMESPath suite
SonarCloud Quality Gate failed.
|
…1fc79e8e0 Pull request: release <- staging/f37977e1-bd56-4fd8-bea9-c411fc79e8e0
This required the following changes:
Waiters should mostly be working now, but there are a few remaining tasks: