Fail on unknown property overridden by ConverterRegisteringWebMvcConfigurer > createHalConverter

[ghost]

Hello,
I have
spring.jackson.deserialization.fail-on-unknown-properties=true

But in the ConverterRegisteringWebMvcConfigurer > createHalConverter

there is
mapper.disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES);

The question
Is there an option to enable FAIL_ON_UNKNOWN_PROPERTIES ?

[gregturn]

Why would you want to do this? It would break your ability to support backwards compatibility with RESTful services.

[ghost]

Yes and no.
In the case which you mentioned - it makes sense. But for all monolith apps where a strict JSON contract should be enforced (also my case) - it does not.

It would be nice if you have application.settings variable which can force this value to true.

 @Value("${spring.something.something:#{true}}")
 private String enforceFailOnUnknownProperties;

........................................................

ObjectMapper mapper = objectMapper.copy();
if(enforceFailOnUnknownProperties){
    mapper.disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES);
}
mapper.registerModule(new Jackson2HalModule());

[ghost]

Any idea if this feature is going to be added in the next releases ?

[gregturn]

Included in the next release? Not likely. I'm not yet sold on this when discussing RESTful concepts.

If you need a workaround, you can always supply your own ObjectMapper and then apply a BeanPostProcessor after Spring HATEOAS has configured it.

[ghost]

@gregturn OK, it seems you restrict people from choosing another option, from the one you are enforcing.

An additional setting will make this choice a bit more "open" and flexible and it will fit wide variety of use cases.

It is just fixing something so small takes so much actions from the dev side (custom ObjectMapper and BeanPostProcessor). And by just adding a property you can solve that with an ease.

[gregturn]

It’s strange to dub this as a “restriction” given we are talking about Postel’s law.

We are building a toolkit aimed at REST, not contract enforcement.

We can’t add 50 knobs to accommodate every desired hook into Jackson. It would make our API hard to use. At that point why use this toolkit?

So what is the threshold for a good knob vs. one too many?

[ghost]

As far as I know Spring and most of add-on projects has auto config (as the case here).

But at the same time there is easy way to "plug" yourself in and do small corrections to the default behaviour. Implement an interface, extend class or change application.properties.

If you consider my request as "it does't really makes sense", it would be really helpful if you add a code snippet for achieving the mentioned functionality. There are few stackoverflow questions about that topic.

Thank you in advance.