Re-using ObjectMapper from spring-boot for EntityViewAwareMappingJackson2HttpMessageConverter leads to issues about blaze-persistence

[EugenMayer]

This one is interesting, cloning the ObjectMapper will make IdView support in DTOs disappear again.

The point is, if BPs deserializer is not added on the OM of spring boot, spring boot will not be abler to deserialize things like

public class SomeDTO {
   public UserIdView user;
}

The be frank:

• using a clone of OM, will make the deserialization of SomeDTO not work
• NOT using a clone will make the deserialization SomeDTO , but will break some serialization

[EugenMayer]

After reading up what INFER_PROPERTY_MUTATORS actually does, it seems like disabling it is actually rather a good practice after all.

To fix the issue for us, we had to add setters to our ProblemResponse.

I'am not sure where it leaves us, since there are arguments in both directions

1. clone within BP so no surprising changes like the above happen to the OM for any other deserialization (side effect)
2. ensuring the educate the user of the integration about this side effect, and let the user decide to clone or not

Wit 1. BP loses the support to deserialize any IdViews in DTOs (while it would have the support), with 2., if uncloned, the support for the former still works.

So it is kind of surprising on each strategy, but since doing 1. cannot be reverted and thus the user cannot opt in for deserialization support, but .2 lets the user decide himself to clone (lose it, less side effects), or not (deserialization support).

So considering there is no right or wrong in having less side effects or support for des., i would tend to go with 2., so depending on external clone if needed. It is flexible and can cover all cases - and it is what is implemented now.
The only thing that needs consideration is, documentation and education about the side effect

[EugenMayer]

Thank you for the discussion and clarification @beikov - we know understand that what happened here was actually 'using a side-effect' of a non-clone OM which we ourself used to create a custom EntityViewAwareMappingJackson2HttpMessageConverter ( see #1899). So BP already clones the OM just fine for the MVC integration.

In addition, the support for deserializing EVs in DTOs was yet never intended, thus #1898 tries to discuss it's implementation.

Closing this issue as invalid / miss understanding. Thank you @beikov for your patience :)