Consider adding support for injecting a custom ObjectMapper bean

[vpavic]

To my knowledge, currently it isn't possible to inject a custom, Spring HATEOAS dedicated, ObjectMapper bean into ConverterRegisteringWebMvcConfigurer as it will either work with the primary instance, or create new one:

spring-hateoas/src/main/java/org/springframework/hateoas/config/ConverterRegisteringWebMvcConfigurer.java

Line 105 in 9131a82

ObjectMapper objectMapper = mapper.getIfAvailable(ObjectMapper::new);

It would be nice to have the capability to configure Spring HATEOAS to work with a non-primary ObjectMapper bean as in quite a few non-trivial apps the ObjectMapper will be used in different places and therefore with different configuration requirements.

For example, in Spring Session we have qualifiers that enable users to provide their own, Spring Session dedicated, bean definitions for infrastructure related components. As an example, see:

• RedisHttpSessionConfiguration - allows injection of Spring Session specific RedisConnectionFactory, RedisSerializer, Executor.
• JdbcHttpSessionConfiguration - allows injection of Spring Session specific DataSource, LobHandler, ConversionService.

It would be nice if Spring HATEOAS would provide similar configuration capabilities. I'm working on a project where we're adding a new version of API (HAL based) but still have to support the previous API for quite some time - it would be nice if we could have a simple way of hooking a dedicated ObjectMapper instance into Spring HATEOAS config. At the moment we're using a BeanPostProcessor in a similar manner like described here, which obviously isn't ideal.

[vpavic]

Any feedback on this? Thanks.

[odrotbohm]

In #1382 we introduced callbacks on HalConfiguration and HalFormsConfiguration to customize the ObjectMapper. Does that do the trick for you?

[vpavic]

The originally reported problem disappeared for us when we moved to Spring HATEOAS 1.0.

To clarify: we're also using a custom media type that's based on HAL, and with 1.0 providing a first-class support custom media types, IIRC we were able to remove the BPP-based workaround by simply implementing HypermediaMappingInformation#configureObjectMapper.

For stock HAL usage I do find these new callbacks quite helpful and will certainly make use of them so many thanks for this addition. 🙂

So I assume this issue can be closed, right?

[odrotbohm]

Good feedback. Glad it's working for you now.