Skip to content

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

Merged
merged 2 commits into from
Sep 15, 2020

Conversation

millems
Copy link
Contributor

@millems millems commented Sep 14, 2020

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.

.add(")");
break;
case "pathAny":
result.add("OnResponseAcceptor(")
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Copy link
Contributor Author

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.

* Contains classes used at runtime by the code generator classes for waiter acceptors generated from JMESPath expressions.
*/
@SdkProtectedApi
public final class WaitersRuntime {
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

@millems millems Sep 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense 👍

Copy link
Contributor

@dagnir dagnir left a 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?

https://github.com/jmespath/jmespath.test

Copy link
Contributor Author

@millems millems left a 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:

  1. 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.
  2. 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.

@millems millems force-pushed the millem/waiter-acceptors branch from 0041c0b to 16b7fb7 Compare September 15, 2020 18:37
@dagnir
Copy link
Contributor

dagnir commented Sep 15, 2020

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.

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 :).

@millems millems force-pushed the millem/waiter-acceptors branch from 16b7fb7 to 89a1952 Compare September 15, 2020 21:58
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.
@millems millems force-pushed the millem/waiter-acceptors branch from 89a1952 to 5c607cb Compare September 15, 2020 22:50
Copy link
Contributor

@dagnir dagnir left a 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

@sonarqubecloud
Copy link

SonarCloud Quality Gate failed.

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities (and Security Hotspot 0 Security Hotspots to review)
Code Smell A 15 Code Smells

76.4% 76.4% Coverage
0.2% 0.2% Duplication

warning The version of Java (1.8.0_252) you have used to run this analysis is deprecated and we will stop accepting it from October 2020. Please update to at least Java 11.
Read more here

@millems millems merged commit e371de4 into waiters-development Sep 15, 2020
@millems millems deleted the millem/waiter-acceptors branch September 15, 2020 23:17
aws-sdk-java-automation added a commit that referenced this pull request May 19, 2022
…1fc79e8e0

Pull request: release <- staging/f37977e1-bd56-4fd8-bea9-c411fc79e8e0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants