Skip to content

Support to UnMarshall Blob type payload data in XMlProtocol #2240

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
Jan 19, 2021
Merged

Support to UnMarshall Blob type payload data in XMlProtocol #2240

merged 2 commits into from
Jan 19, 2021

Conversation

joviegas
Copy link
Contributor

@joviegas joviegas commented Jan 15, 2021

Description

  • Adding suppoert to parse Blob type Payloads in XML protocol.

Motivation and Context

  • Blob type data in XML payload.

Testing

  • Added Junits.
  • Integration Test

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


if (!CollectionUtils.isNullOrEmpty(element)) {
Object unmarshalled = unmarshaller.unmarshall(context, element, (SdkField<Object>) field);
field.set(sdkPojo, unmarshalled);
if (payloadMemberAsBlobType.isPresent() && payloadMemberAsBlobType.get().equals(field)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is similar to JsonProtocolUnmarshaller

@codecov-io
Copy link

codecov-io commented Jan 15, 2021

Codecov Report

Merging #2240 (26e26b5) into master (43d3e87) will decrease coverage by 0.00%.
The diff coverage is 83.33%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master    #2240      +/-   ##
============================================
- Coverage     77.64%   77.63%   -0.01%     
  Complexity      335      335              
============================================
  Files          1231     1231              
  Lines         38724    38733       +9     
  Branches       3047     3051       +4     
============================================
+ Hits          30066    30072       +6     
- Misses         7199     7202       +3     
  Partials       1459     1459              
Flag Coverage Δ Complexity Δ
unittests 77.63% <83.33%> (-0.01%) 0.00 <0.00> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ Complexity Δ
...awssdk/protocols/json/internal/MarshallerUtil.java 100.00% <ø> (ø) 0.00 <0.00> (?)
...ml/internal/unmarshall/XmlResponseParserUtils.java 62.50% <80.00%> (+12.50%) 0.00 <0.00> (ø)
...l/internal/unmarshall/XmlProtocolUnmarshaller.java 94.02% <85.71%> (-1.14%) 0.00 <0.00> (ø)
...ty/internal/IdleConnectionCountingChannelPool.java 86.58% <0.00%> (-1.22%) 0.00% <0.00%> (ø%)
...ssdk/core/internal/async/FileAsyncRequestBody.java 83.80% <0.00%> (-0.96%) 0.00% <0.00%> (ø%)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 43d3e87...1880f40. Read the comment docs.

if ((!response.isSuccessful() || hasPayloadMembers(sdkPojo)) && responseContent.isPresent() &&
!contentLengthZero(response)) {
!contentLengthZero(response) && !getBlobTypePayloadMemberToUnmarshal(sdkPojo).isPresent()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This is long with a lot of nesting. Can we extract it and apply some names to the intermediate values?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

removed context.response().content().isPresent check as we already do in LineNumber 83.
Replaced with local variable

public static Optional<SdkField<?>> getBlobTypePayloadMemberToUnmarshal(SdkPojo sdkPojo) {
return sdkPojo.sdkFields().stream()
.filter(f -> f.location() == MarshallLocation.PAYLOAD
|| MarshallerUtil.locationInUri(f.location()))
Copy link
Contributor

Choose a reason for hiding this comment

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

Why would a payload member be in the URI?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Settings that don't make sense for the given input/output direction should default to body. E.g. URI fields in a response should go into the payload.
#1996

Copy link
Contributor

Choose a reason for hiding this comment

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

Would it still be an explicit payload member in this case? (Line 79, or would that filter it out?)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

From Original #1996_Snippet which added this for Json ,it looks like it would still be explicit payload member.

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 a protocol test for this?

Copy link
Contributor Author

@joviegas joviegas Jan 19, 2021

Choose a reason for hiding this comment

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

Thanks Matt , Whi;e I was trying to come up with protocol test cases for the above cases I realized that the MarshallerUtil.locationInUri(f.location()) is not necessary in this case. It is a dead code since it will be filtered at next stage where it checks for f.containsTrait(PayloadTrait.class);

I had taken wrong reference for parsing SDK_Bytes actually it should have been JsonProtocolUnmarshaller.java#L207-L209
Sorry for the confusion , removed these extra checks.

@sonarqubecloud
Copy link

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