Jackson version conflict

[sysmat]

Description

• RestClientTransport it need JacksonJsonpMapper which is limiting
• if app use jackson with different version than you will have erros like java.lang.NoSuchMethodError: com.fasterxml.jackson.core.JsonParser.isExpectedNumberIntToken
• with RestHighLevelClient you could deserialize raw string response with your own mapper
• is there any way to use ElasticsearchClient without jackson mapper?

[l-trotta]

Hello, the RestClientTransport does not need JacksonJsonpMapper: it needs JsonpMapper, which is an interface that we provide and has two main implementations available within the client: Jackson and JsonB. Users are free to choose the implementation they prefer, we usually use Jackson in the examples because it's usually the most requested - more details in the client installation guide.

There's a third implementation which is SimpleJsonpMapper, which does not require any external dependencies because it handles serialization exclusively for Java API client, meaning it will fail if any custom class is used. If data is inserted using formats such as JsonData or BinaryData, there will be no serialization/deserialization involved and it's possible to actually use the client with no external mapper.

Here is a full example where the only dependency used is the java client:

SimpleJsonpMapper jsonpMapper = new SimpleJsonpMapper();

ElasticsearchTransport transport = new RestClientTransport(restClient, jsonpMapper);

ElasticsearchClient esClient = new ElasticsearchClient(transport);

// indexing a simple document as a json string
esClient.index(i -> i.index("my-binary-test").document(JsonData.fromJson("{\"doc\": \"1\"}")));

SearchResponse<BinaryData> binRes = esClient.search(s -> s.index("my-binary-test"), BinaryData.class);

// just getting the first item of the list for simplicity
BinaryData bin = binRes.hits().hits().get(0).source();

// text will be 
//{
//  "doc" : "1"
//}
String text = new String(bin.asInputStream().readAllBytes(), StandardCharsets.UTF_8);

[swallez]

@sysmat I renamed the issue from "RestClientTransport bad design" to "Jackson version conflict" because this is really what it is. If every library that uses JSON had a bad design because they depend on Jackson, then a large part of the Java ecosystem would have a bad design!

That being said, JsonParser.isExpectedNumberIntToken was added in Jackson version 2.12 that was released 4 years ago so you should really upgrade the version of Jackson you use in your project.

[sysmat]

@swallez thx for replay.
Upgrading large code base and lagacy code.
I was thinking way to have in construction this restriction of seralization provider

[swallez]

@sysmat as outlined by @l-trotta the JSON parser is pluggable and Jackson is not a requirement. and you can have the raw data as a string. This can be a workaround to keep using your old version of Jackson, but comes with a performance price as the Java client will serialize the JSON to a string, that I guess you will parse again.