-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add MapperFeature.REQUIRE_TYPE_ID_FOR_SUBTYPES
to enable/disable strict subtype Type Id handling
#3853
Comments
The reason here is that you are not using target type of I would be open to having a |
Resolves FasterXML#3853 by adding support for strict handling of type information when deserializing into a registered subtype.
Resolves FasterXML#3853 by adding support for strict handling of type information when deserializing into a registered subtype.
I've created #3854 to add some support for it if there's still time ? |
Thank you @stevestorey -- yes, I think there is. I'll have to think about the question of default settings: in principle, I agree that changes should ideally be Opt-In. The only caveat here is that this is a highly-voted improvement and in some ways it's... one possibility would be to introduce it in 2.15, defaulting to old behavior; then consider change in 2.16; this to have new Thank you for submitting #3854: I will try to find time to work with it, and will make sure to tackle it before 2.15.0-rc3 gets released. |
MapperFeature.REQUIRE_TYPE_ID_FOR_SUBTYPES
to enable/disable strict subtype Type Id handling
Also realizing that maybe for 2.16 there should be added property for Created #3877 for possible follow-up work as per my comment. /cc @JooHyukKim |
Thank you again @stevestorey -- this is merged and will make it in 2.15.0-rc3 that I hope to release RSN. |
@cowtowncoder is the fix for #2968 released in 2.15.0-rc3? As even after upgrading the version, we are getting the prev errors. |
@Yash-Kudesia By looking at the release note (refer to below), yes this issue should have been fixed by 2.15.0-rc3 🥲.
|
Correct: while the fix is in, it will only work when that |
Describe the bug
In 2.14, if you setup
@JsonTypeInfo(use = Id.NAME)
then all JSON passed toreadValue
must include the@type
information, but that's no longer true in 2.15, which will now unmarshall JSON with missing type information (as long as no other constraints fail). Although I guess it's possibly something to consider as an improvement, but personally I would like to ensure that clients must pass the type information, not least so that one cannot accidentally send the wrong JSON, but have it pass because it's close enough to the intended type.Version information
2.15.0-rc2
To Reproduce
Unit test:
Expected behavior
The unit test passes, as an
InvalidTypeIdException
is thrown when no type information is present in the incoming JSON, as was the case in 2.14The text was updated successfully, but these errors were encountered: