Skip to content
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

fix(java): remove Jackson confusion with certain patterns #987

Merged
merged 2 commits into from
Nov 14, 2019

Conversation

RomainMuller
Copy link
Contributor

Upon deserializing (ObjectMapper#treeToValue), Jackson will first
validate the valueType for whether ti can be deserialized with the
"standard" bean deserializer. This will bail out if there are multiple
ambiguous setters for a given property (they are ambiguous if they have
parameters of non-trivial types, such as List, some class, ...).

In order to remove the problem, this changes the deserialization path so
that instead of asking for deserialization into the needed instance type
directly, JsiiObject will be requested instead when the declared type
is a sub-class of that. Since such types are passed by-reference, the
custom de-serializer modifier will correctly determine the "right" class
to use (the declared type, or a subtype of it), and return this... But
Jackson will not get the chance to be confused or unhappy about that
type's structure.

This was the root cause of aws/aws-cdk#4080


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Upon deserializing (`ObjectMapper#treeToValue`), Jackson will first
validate the `valueType` for whether ti can be deserialized with the
"standard" bean deserializer. This will bail out if there are multiple
ambiguous setters for a given property (they are ambiguous if they have
parameters of non-trivial types, such as `List`, some class, ...).

In order to remove the problem, this changes the deserialization path so
that instead of asking for deserialization into the needed instance type
directly, `JsiiObject` will be requested instead when the declared type
is a sub-class of that. Since such types are passed by-reference, the
custom de-serializer modifier will correctly determine the "right" class
to use (the declared type, or a subtype of it), and return this... But
Jackson will not get the chance to be confused or unhappy about that
type's structure.

This was the root cause of aws/aws-cdk#4080
@RomainMuller RomainMuller requested review from bmaizels and a team as code owners November 14, 2019 10:46
@RomainMuller RomainMuller removed the request for review from bmaizels November 14, 2019 10:46
@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Nov 14, 2019

Thank you for contributing! ❤️ I will now look into making sure the PR is up-to-date, then proceed to try and merge it!

@mergify mergify bot added the pr/ready-to-merge This PR is ready to be merged. label Nov 14, 2019
@mergify mergify bot merged commit a8096b7 into master Nov 14, 2019
@mergify mergify bot deleted the rmuller/fix-jackson-conflict branch November 14, 2019 11:54
@mergify mergify bot removed the pr/ready-to-merge This PR is ready to be merged. label Nov 14, 2019
eladb pushed a commit that referenced this pull request Nov 18, 2019
eladb pushed a commit that referenced this pull request Nov 18, 2019
@rix0rrr
Copy link
Contributor

rix0rrr commented Nov 25, 2019

When is this revert going to be reverted?

rix0rrr pushed a commit that referenced this pull request Nov 26, 2019
(Reintroduce #987).

Upon deserializing (`ObjectMapper#treeToValue`), Jackson will first
validate the `valueType` for whether ti can be deserialized with the
"standard" bean deserializer. This will bail out if there are multiple
ambiguous setters for a given property (they are ambiguous if they have
parameters of non-trivial types, such as `List`, some class, ...).

In order to remove the problem, this changes the deserialization path so
that instead of asking for deserialization into the needed instance type
directly, `JsiiObject` will be requested instead when the declared type
is a sub-class of that. Since such types are passed by-reference, the
custom de-serializer modifier will correctly determine the "right" class
to use (the declared type, or a subtype of it), and return this... But
Jackson will not get the chance to be confused or unhappy about that
type's structure.

This was the root cause of aws/aws-cdk#4080
mergify bot pushed a commit that referenced this pull request Nov 26, 2019
(Reintroduce #987).

Upon deserializing (`ObjectMapper#treeToValue`), Jackson will first
validate the `valueType` for whether ti can be deserialized with the
"standard" bean deserializer. This will bail out if there are multiple
ambiguous setters for a given property (they are ambiguous if they have
parameters of non-trivial types, such as `List`, some class, ...).

In order to remove the problem, this changes the deserialization path so
that instead of asking for deserialization into the needed instance type
directly, `JsiiObject` will be requested instead when the declared type
is a sub-class of that. Since such types are passed by-reference, the
custom de-serializer modifier will correctly determine the "right" class
to use (the declared type, or a subtype of it), and return this... But
Jackson will not get the chance to be confused or unhappy about that
type's structure.

This was the root cause of aws/aws-cdk#4080
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