Json Parser is too strict

[Lokowandtg]

The parser that handles the responses from the cloud foundry instance is very strict and aborts processing as soon as an unknown property is received or a type does not match. There is no easy way for applications using the cf-java-client to continue processing.
This becomes a problem if the versions of client and server do not match or if test coverage in the integration-tests does not point to the problem during development of a new version.

There should be some central switch to log and ignore problems during message parsing as far as possible. The switch would be helpfull during development, when client and server versions do not match.

There should be a configuration file to ignore only explicitly listed properties that are save to ignore, even in a productive environment.

[Kehrlann]

The main issue is that the CF API adds fields as version progresses, isn't it?

So far, the pattern has been to add @Nullable fields when the CF api is upgraded. It's annoying but it has worked. I am ok turning off "strict parsing" in tests. The tradeoff is that cf-java-client will drift behind the CF API.

However, if we want to turn off strict parsing in tests, let's avoid writing more parsing logic. The default ObjectMapper already ignores properties, but it's added back in the test with a custom ProblemHandler, see FailingDeserializationProblemHandler .

If you remove that bit, new properties are silently ignored.

I think I saw something about an enum - consider just adding the new value, it will help our users if they want to read that type.

[Lokowandtg]

The point is that not every user is able to deploy a patched version whenever a problem shows up. Ignoring all errors is OK in a test environment, but might be too risky in a productive setup.
I tried to address this with a configuration file where some exceptions can be listed while other parsing errors continue to break the processing.
Certainly ignoring new fields is only a temporary workaround. The new properties or enum-values need to be covered in cf-java-client. When that change is released, the application developer building on top of cf-java-client can recompile (and eventually adapt) the application. When that is released, the operator of the client-application can redeploy. Then the execption can be removed again.

So the purpose is to allow the operator of an application building on cf-java-client to react immediately and have a running application until all patches are released.

[Kehrlann]

The "unknown property" issues are only raised in integration tests, no need for special processing. The default prod deserializer already ignores uknown properties.

We're left with enums. We could use some Jackson feature for this (DeserializationFeature.READ_UNKNOWN_ENUM_VALUES_AS_NULL, DeserializationFeature.READ_UNKNOWN_ENUM_VALUES_USING_DEFAULT_VALUE)

I am really hesitant to add 400 lines of JSON processing with unknown performance impact.