Skip to content

Include event type in visitor name #2091

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 1 commit into from
Oct 15, 2020

Conversation

dagnir
Copy link
Contributor

@dagnir dagnir commented Oct 14, 2020

Description

This commit fixes event visitor method generation by including the event type
in the visitor name. Note that event type here is actually the member name in
the encompassing eventstream structure, not the Java class of the event.

For example, in the example below, "Foo" is the event type.

"MyEventStream": {
   "type": "structure",
   "eventstream": true,
   "members": {
       "Foo": {
           "shape": "Bar"
       }
   }
}

To ensure that this change is backwards compatible with existing services that
have event streams (Transcribe Streaming and Kinesis), we also include a
customization to supress this behavior keep the method name as "visit".

Note that by sheer luck, the existing consumer method setters, e.g.

Builder onSubscribeToShardEvent(Consumer<SubscribeToShardEvent>);

are unaffected by this change. See an example here.
The previous generation scheme for these methods is "on{Generation Java class
name for event shape}"; now it's "on{event type}". However, both Transcribe and
Kinesis use the shape name as the member name (or vise versa?) in their current
iteration of their event streams.

For example, in Kinesis, SubscribeToShard's output stream is defined as

"SubscribeToShardEventStream":{
  "type":"structure",
  "required":["SubscribeToShardEvent"],
  "members":{
    "SubscribeToShardEvent":{"shape":"SubscribeToShardEvent"},

    ...
    },
  "eventstream":true
}

Motivation and Context

Testing

Screenshots (if appropriate)

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Checklist

  • I have read the CONTRIBUTING document
  • Local run of mvn install succeeds
  • My code follows the code style of this project
  • My change requires a change to the Javadoc documentation
  • I have updated the Javadoc documentation accordingly
  • I have read the README document
  • I have added tests to cover my changes
  • All new and existing tests passed
  • A short description of the change has been added to the CHANGELOG
  • My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

  • I confirm that this pull request can be released under the Apache 2 license

This commit fixes event visitor method generation by including the *event type*
in the visitor name. Note that event type here is actually the member name in
the encompassing eventstream structure, *not* the Java class of the event.

For example, in the example below, "Foo" is the event type.

"MyEventStream": {
   "type": "structure",
   "eventstream": true,
   "members": {
       "Foo": {
           "shape": "Bar"
       }
   }
}

To ensure that this change is backwards compatible with existing services that
have event streams (Transcribe Streaming and Kinesis), we also include a
customization to supress this behavior keep the method name as "visit".

Note that by sheer luck, the existing consumer method setters, e.g.

Builder onSubscribeToShardEvent(Consumer<SubscribeToShardEvent>);

are unaffected by this change. The previous generation scheme for these methods
is "on{Generation Java class name for event shape}"; now it's "on{event type}".
However, both Transcribe and Kinesis use the shape name as the member name (or
vise versa?) in their current iteration of their event streams.

For example, in Kinesis, SubscribeToShard's output stream is defined as

"SubscribeToShardEventStream":{
  "type":"structure",
  "required":["SubscribeToShardEvent"],
  "members":{
    "SubscribeToShardEvent":{"shape":"SubscribeToShardEvent"},

    ...
    },
  "eventstream":true
}
@dagnir
Copy link
Contributor Author

dagnir commented Oct 14, 2020

Note: anything that doesn't use the customization at the moment will fail to compile, e.g. the protocol-tests module since the model classes don't know how to call the new visitor methods yet (will be done in following PR). Right now they're hardcoded to call visitor.visit(this) basically.

@dagnir dagnir merged commit ad6544c into aws:dongie/eventstream-visitors-fix Oct 15, 2020
aws-sdk-java-automation added a commit that referenced this pull request Jul 13, 2022
…8f7c78b39

Pull request: release <- staging/61318f78-85b4-425c-882c-c038f7c78b39
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.

2 participants