Issue #26 - Support for Default Typing #30
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this PR I have added partial support for default typing in NON_FINAL and EVERYTHING modes.
This support is not perfect because the Jackson API is not making it easy for a serializer to discern exactly what the default typing mode, and class identifier property are. Default typing is enabled on the mapper directly and does not set feature flags that can be interrogated, nor was I able to find a means to heuristically determine such information. There wasn't even any obvious way to leverage reflection to dig out this information. This is quite disappointing because it does seem that this is something a serializer needs to take into account to produce legal output. It might be worth discussing this with the Jackson project to see if I've missed something or if there is a good way for them to improve this in future versions. I did a quick look on more recent versions and didn't find anything. I mostly focused on the version of Jackson currently specified by this project (2.10.3), since changing compatibility with versions is an additional burden, and probably should be done in it's own PR.
Nonetheless, by specifying an attribute visible in the mapping context for the writer, I am able to output class information.
What is supported in this PR:
What is no supported:
@classis not expected in some cases and required in others. No exception is thrown if we add .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false) but the output is not correct and some objects become duplicated, so I have aggresively documented against this combination.All unit tests pass, and I added a new test specific to Issue26 to document it and it's limitations README file was updated to provide guidance on how to enable this support.
During this investigation I also had some ideas on how to optimize the deserializer to avoid needless creation of an immediately garbage collectable JsonNode object and simplify the code for this feature slightly too, but that can be a follow on PR.