Can anything be done about the default value of FAIL_ON_UNKNOWN_PROPERTIES?

[Ryan Heaton]

Hi.

(See pull request #783 for context.)

This scenario happens a lot:

1. Somebody writes a client that uses Jackson to consume an API.
2. The API developers add a property.
3. The addition of the property breaks existing clients because they're configured by default to fail on unknown properties.
4. The developer of the client comes to me to ask why their client is so brittle.
5. I tell them that they have to provide a special configuration setting.
6. They ask me why Jackson, by default, fails on unknown properties.
7. I have no answer.

So why does Jackson fail on unknown properties by default? I can't think of any other binding libraries that fail on unknown properties (e.g. JAXB, gson, protobuf, etc.).

Since a request to change the default was rejected as a backwards-incompatible change, am I consigned to live with the above scenario playing out repeatedly?

What if we made the default change not in the core databind project, but just in the jackson-jaxrs-providers project? Would that be more reasonable?

Thanks!

-Ryan

[Jeff Schnitzer]

Agreed. This default is backwards, and one of the boilerplate things I have to fix every time I use Jackson in a project.

Jeff

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
To post to this group, send email to jackso...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tatu Saloranta]

My prediction here is that should the default was changed, we'd get users who are puzzled by things "working", but no data appearing. After debugging by user community, they would find a naming and/or structural incompatiblity, masked by the new default that does not care at all about the fact that no data matches any of the structure. This would offset some of the benefits of getting fewer questions at a later point.

Whether it is a good trade-off I can't say. It is true that a later breakage can be more problematic; although getting an earlier "hidden" problem (things fail but without direct indication) is a big turn-off factor for new users.

The original default was exactly based on JAXB's broken -- so I thought -- default choice: I cursed at JAXB authors who for some reason unknown to me had thought that omitting everything that does not match was a good idea. What a bunch of idiots was my thinking. ;-)

But I have since learned that there are two sides to the issue, and from my perspective you'll be damned either way. After everything does work, you are more likely to allow unknown properties either generally, or in specific cases. I am not as sure whether the choice of default setting helps, overall, because until you understand the trade-off involved you will be choosing one of common error modes over another. Or more accurately, the choice has been made for you.

Regarding JAX-RS defaults: I don't often use "plain" JAX-RS these days and I suspect that most usage is via DropWizard or Spring Boot, both of which use (or may choose to use) pre-configured version of Jackson JAX-RS mapper, and so can choose defaults they want.
But if the user community really wants this default to differ for JAX-RS module, I am not opposed.

Given that frameworks can more easily choose their own defaults, vanilla settings from databind can be blocked.

What would be the best way to proceed here? Setting an online questionnaire is easy, but how to get enough coverage?

For databind itself I am also not opposed to changing the default for 3.0, if we can determine that the feeling is strongly in favor of by default allowing ignoral of unknown properties.

Since there are no plans yet for 3.x backwards-incompatible-version yet, I don't think any voting is necessary.

But I will keep in mind that the choice of defaults is something that will need to be re-evaluated if and when we get there. So that where with 2.x, not much thought was put to default choices (compared to other kinds of clean up for API), this will be an area to revisit.

Thank you for all the opinions so far,

-+ Tatu +-