ElasticsearchClientAutoConfiguration causes global ObjectMapper to be overwritten

[manofthepeace]

Tested with springboot 3.0.0

When the new ElasticsearchClient is in the classpath, it triggers the ElasticsearchClientAutoConfiguration which then overrides the application objectmapper / the one configured via Jackson2ObjectMapperBuilder.

Reproducer for this issue; https://github.com/manofthepeace/spring3-elasticClient-mapperissue

Steps to reproduce;

1. Run the test via mvn test the test will pass
2. modify the pom.xml and uncomment the elasticsearch-java dependency
3. run the test via mvn test the test will fail
4. in TestingWebApplication.java use @SpringBootApplication(exclude = ElasticsearchClientAutoConfiguration.class)
5. run the test via mvn test the test will pass

Expected behaviour;
the RestClientTransport should use a new ObjectMapper, or somehow a user provided one, but not the one that spring-mvc / the global one is using. Can be done with new JacksonJsonpMapper() or by passing an objectMapper to the JacksonJsonpMapper constructor.

[mhalbritter]

You specify the version of elasticsearch-java in your pom.xml:

        <dependency>
            <groupId>co.elastic.clients</groupId>
            <artifactId>elasticsearch-java</artifactId>
            <version>7.17.7</version>
        </dependency>

When removing the version and letting Spring Boot take care of the version, the problem goes away.

[mhalbritter]

it looks like that your version takes the passed ObjectMapper in org.springframework.boot.autoconfigure.elasticsearch.ElasticsearchClientConfigurations.JacksonJsonpMapperConfiguration#jacksonJsonpMapper and reconfigures it. The version boot uses (8.5.1 at the time of writing) doesn't do that anymore.

[manofthepeace]

@mhalbritter thanks you for your time, and your answer.

I find that really unfortunate that spring tries to do some auto configuration when the user specifies his own libraries (not a starter). The elasticsearch client is not backward compatible, like at all, so using the one provided with springboot is not an option for us as we need to support a large array of elastic server version (not that large, but 5.X, 6.X and 7.X), and we cannot just lag behind on spring versions because of elastic server (out of our control).

I would really appreciate if the autoconfiguration runs if one of the class of the starter is present, not the one from elasticsearch. I must say it was quite a painful debugging trying to understand why our rest api stopped providing the right responses, and now all our microservice that uses ES will need that specific exclude, which I find a bit dirty.

I understand that adding a starter would modify the behaviour in my app, but providing libs out of spring, I think they should be left untouched, for me the really seem like an issue.

I also think it is risky to let elasticsearch library do anything with the global object mapper, maybe it does do anything to it in 8.5.1, but what tell they wont in the future. I still think it needs its own, a user might want to parse differently the Es reponses than what is done via rest.

Again, thank you for your time.

[mhalbritter]

You can still use the old client if you really want to. The auto-configuration is built in a way that it backs off if you provide your own JsonpMapper, which can be done like this:

@Configuration(proxyBeanMethods = false)
class JacksonJsonpMapperConfiguration {
	@Bean
	JacksonJsonpMapper jacksonJsonpMapper() {
		return new JacksonJsonpMapper();
	}
}

Does this work for you?

And yes, i agree that ElasticSearch modifying the passed ObjectMapper is not good. I'll flag it for discussion to see what the rest of the team thinks.

[mhalbritter]

So we talked about that today, and we decided that all options we have are bad:

Either we change the default from not passing in the global ObjectMapper, which breaks everyone who's relying on the current behaviour.

Or we let it be and live with that the global object mapper is used for WebMVC and ElasticSearch and whatever else and if you reconfigure it, you reconfigure it in all places.

That the elasticsearch client reconfigures the given ObjectMapper is a bug which they fixed.

I'll create a ticket to maybe flip the default in Spring Boot 3.1: not using the global ObjectMapper for ElasticSearch but using the no-args constructor of JacksonJsonpMapper.