fix #4109: moving template handling to a custom deserializer #4292
Conversation
|
I need to check, but I think this one would break the feature where we allow deserializing fields with unmatched types to the additionalProperties map. |
Other than changing the package, it does not. You can of course leave the old ones in place, but deprecated if you want. |
I just gave it a quick look and the changes in the Serialization class made me think of this. I'll try to review properly later |
Signed-off-by: Marc Nuri <marc@marcnuri.com>
|
SonarCloud Quality Gate failed. |
Description
This addresses #4109 and is related to #3972. It is also a replacement for #4034 - since the idea of subclassing ObjectMapper is unpalatable, the other way to do this is with a custom deserializer. But to keep the same unmatched logic, we need to move that to model-common, rather than client-api.
If it's acceptable, then I can further add a changelog about moving the unmatched static methods, etc. The unmatched test references thing from the api, so it can't be moved to model-common as is - but it could of course be further refactored to move the tests.
With this change we also don't need to have the parameter handling logic so deeply coupled with the Serialization logic - that is we don't have to do string substitution on the string prior to parsing. That could easily be done as post processing logic in the TemplateOperationsImpl.
Type of change
test, version modification, documentation, etc.)
Checklist