ContentType override is reset when quarkus-rest-client-jackson is a maven dependency

[benDeMtp]

Describe the bug

Quarkus documentation says that Content-Type could be overridden : https://quarkus.io/guides/rest-client#multipart-mixed-odata-usage

It works as expected with quarkus-rest-client dependency. But it doesn't when quarkus-rest-client-jackson is added.

Quarkus 3.15.2 and 3.17.5

Expected behavior

Same behaviour with or without quarkus-rest-client-jackson

Actual behavior

No response

How to Reproduce?

reproducer : https://github.com/benDeMtp/contentype-bug-reproducer

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @cescoffier (rest-client), @geoand (jackson,rest-client), @gsmet (jackson), @mariofusco (jackson), @quarkusio/devtools (maven)

[geoand]

In your case you can solve the issue by adding:

    @Produces(MediaType.TEXT_PLAIN)
    @Consumes(MediaType.TEXT_PLAIN)

to the REST Client method.

A case could be made that it shouldn't be strictly necessary

[lasteris]

@geoand Am I understand problematic correctly ?
If dependency quarkus-rest-client-jackson added, @ClientHeaderParam does not work ?
Does it use 'application/json' instead ?

[geoand]

Not exactly. What happens is that when there are no @Produces and @Consumes, then application/json is used.

[gsmet]

But shouldn't we avoid enforcing it if Content-Type is defined via @ClientHeaderParam?

It feels odd that we are enforcing a default behavior.

[geoand]

Yeah, that's why I mentioned

A case could be made that it shouldn't be strictly necessary

above.
I'm always weary changing content type related stuff though since it can easily break existing code.
That said, it probably does make sense to do and is probably not hard to achieve as most of the infra needed should already be in place.

[lasteris]

I'm not sure, but I can try this issue

[gsmet]

@lasteris sure go ahead. An issue with a reproducer is always nice to work on :).