You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is your use-case and why do you need this feature?
We are building a platform that implements OCPI (a protocol that is used in the EV industry). Even though OCPI is a "standard", companies tend to add extra information to messages.
Because of this we have ignoreUnknownKeys set to true. We would still like to know which keys had been ignored so we can consider whether we should add these in the future as well. We used Jackson before and in Jackson there was a DeserializationProblemHandler that you could register as module.
The solution we have in place as of right now is extending the StringFormat and have a custom try-catch clause around decodeFromString and the ignoreUnknownKeys set to false.
Describe the solution you'd like
Provide a way to configure some sort of problem handler, this could already be in the form of a lambda function you pass to the Json builder.
My Xml format supports this, but I found that using custom types for handling this does not scale well. Instead it has a policy parameter where (various) behavioural functions are provided. In the case of Json the functions that come to mind are handling unknown keys. Handling "invalid" values (e.g. strings instead of Int). The algorithm that determines the key name (for example converting camel case to snake case).
The xml use case for the policy function is mainly to support error correction (including the various "almost xml" variants out there that real world code has no choice but to deal with). The ability to log the key is a side effect. I don't think that json really has such a big problem with key mismatch (no namespaces to get wrong, etc.)
What is your use-case and why do you need this feature?
We are building a platform that implements OCPI (a protocol that is used in the EV industry). Even though OCPI is a "standard", companies tend to add extra information to messages.
Because of this we have
ignoreUnknownKeys
set totrue
. We would still like to know which keys had been ignored so we can consider whether we should add these in the future as well. We used Jackson before and in Jackson there was aDeserializationProblemHandler
that you could register as module.The solution we have in place as of right now is extending the
StringFormat
and have a custom try-catch clause arounddecodeFromString
and theignoreUnknownKeys
set tofalse
.Describe the solution you'd like
Provide a way to configure some sort of problem handler, this could already be in the form of a lambda function you pass to the Json builder.
Someting as follows maybe?
The text was updated successfully, but these errors were encountered: