[Java] fix restclient with useJackson3 omitting default HttpMessageConverters (#24587) - #24640
Conversation
| {{#useJackson3}} | ||
| Consumer<HttpMessageConverters.ClientBuilder> messageConverters = builder -> { | ||
| builder.registerDefaults(); | ||
| builder.addCustomConverter(new JacksonJsonHttpMessageConverter(mapper)); |
There was a problem hiding this comment.
shouldn't we use builder.registerDefaults().withJsonConverter(…)? Otherwise, it creates 2 json converters in the chain. Which technically works too, but it's unnecessary.
There was a problem hiding this comment.
Good catch on avoiding duplicate JSON converters. Since withJsonConverter requires Spring 7.0.7+ and pom.mustache currently defaults to 7.0.5, should we bump the template's Spring version to 7.0.8 and make the switch?
There was a problem hiding this comment.
I don't think bump is needed. the 7.0.7 requirement only applies without registerDefaults(). I think on 7.0.5: registerDefaults().withJsonConverter(…) gives the same 5 converters as a plain RestClient.builder()
There was a problem hiding this comment.
Let me check and get back
There was a problem hiding this comment.
Good point. I updated it to use withJsonConverter.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 5 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="samples/client/petstore/java/resttemplate-springBoot4-jackson3/pom.xml">
<violation number="1" location="samples/client/petstore/java/resttemplate-springBoot4-jackson3/pom.xml:272">
P3: The pom for this sample is bumped to Spring Web 7.0.8, but the Gradle build in the same generated sample still pins Spring Web 7.0.5 (build.gradle line 102, from build.gradle.mustache line 129 for useSpringBoot4). So the same templating options produce different Spring versions depending on build system, and the sample's pom and build.gradle now disagree with each other. If the intent of the 7.0.8 bump was the Spring 7.0.7+ withJsonConverter behavior, the Gradle path would silently stay on 7.0.5. Recommend bumping build.gradle.mustache (and regenerating the sample's build.gradle) to keep both in sync.</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
| <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> | ||
|
|
||
| <spring-web-version>7.0.5</spring-web-version> | ||
| <spring-web-version>7.0.8</spring-web-version> |
There was a problem hiding this comment.
P3: The pom for this sample is bumped to Spring Web 7.0.8, but the Gradle build in the same generated sample still pins Spring Web 7.0.5 (build.gradle line 102, from build.gradle.mustache line 129 for useSpringBoot4). So the same templating options produce different Spring versions depending on build system, and the sample's pom and build.gradle now disagree with each other. If the intent of the 7.0.8 bump was the Spring 7.0.7+ withJsonConverter behavior, the Gradle path would silently stay on 7.0.5. Recommend bumping build.gradle.mustache (and regenerating the sample's build.gradle) to keep both in sync.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At samples/client/petstore/java/resttemplate-springBoot4-jackson3/pom.xml, line 272:
<comment>The pom for this sample is bumped to Spring Web 7.0.8, but the Gradle build in the same generated sample still pins Spring Web 7.0.5 (build.gradle line 102, from build.gradle.mustache line 129 for useSpringBoot4). So the same templating options produce different Spring versions depending on build system, and the sample's pom and build.gradle now disagree with each other. If the intent of the 7.0.8 bump was the Spring 7.0.7+ withJsonConverter behavior, the Gradle path would silently stay on 7.0.5. Recommend bumping build.gradle.mustache (and regenerating the sample's build.gradle) to keep both in sync.</comment>
<file context>
@@ -269,7 +269,7 @@
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
- <spring-web-version>7.0.5</spring-web-version>
+ <spring-web-version>7.0.8</spring-web-version>
<jackson-version>3.1.5</jackson-version>
<jakarta-annotation-version>3.0.0</jakarta-annotation-version>
</file context>
There was a problem hiding this comment.
2 issues found across 8 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="samples/client/petstore/java/resttemplate-springBoot4-jackson3-jspecify/build.gradle">
<violation number="1" location="samples/client/petstore/java/resttemplate-springBoot4-jackson3-jspecify/build.gradle:102">
P2: Spring version now diverges within this regenerated sample: build.gradle was bumped to 7.0.8 but the sibling pom.xml still declares 7.0.5, so Maven and Gradle builds of the same sample use different Spring versions. Regenerate both build files from the template (which emits 7.0.8 for useSpringBoot4) to keep the sample in sync.</violation>
</file>
<file name="samples/client/petstore/java/restclient-springBoot4-jackson2/build.gradle">
<violation number="1" location="samples/client/petstore/java/restclient-springBoot4-jackson2/build.gradle:103">
P2: The sample regeneration for the Spring Boot 4 templates is incomplete, leaving three samples internally inconsistent: `build.gradle` now declares `spring_web_version = "7.0.8"` while the matching `pom.xml` in the same directory still pins `<spring-web-version>7.0.5`. This affects restclient-springBoot4-jackson2, resttemplate-springBoot4-jackson2, and resttemplate-springBoot4-jackson3-jspecify (the other three Spring Boot 4 samples bumped both files consistently). As generated artifacts, these samples should be reproducible from the templates (whose pom.mustache is already 7.0.8), so a Maven-based user of these samples would resolve Spring 7.0.5 while a Gradle user gets 7.0.8 — exactly the kind of sample drift this PR's commit intends to fix. Please regenerate these samples (or update the pom.xml to 7.0.8) so the Maven and Gradle artifacts match.</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
| jackson_version = "3.1.5" | ||
| jackson_annotations_version = "2.21" | ||
| spring_web_version = "7.0.5" | ||
| spring_web_version = "7.0.8" |
There was a problem hiding this comment.
P2: Spring version now diverges within this regenerated sample: build.gradle was bumped to 7.0.8 but the sibling pom.xml still declares 7.0.5, so Maven and Gradle builds of the same sample use different Spring versions. Regenerate both build files from the template (which emits 7.0.8 for useSpringBoot4) to keep the sample in sync.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At samples/client/petstore/java/resttemplate-springBoot4-jackson3-jspecify/build.gradle, line 102:
<comment>Spring version now diverges within this regenerated sample: build.gradle was bumped to 7.0.8 but the sibling pom.xml still declares 7.0.5, so Maven and Gradle builds of the same sample use different Spring versions. Regenerate both build files from the template (which emits 7.0.8 for useSpringBoot4) to keep the sample in sync.</comment>
<file context>
@@ -99,7 +99,7 @@ if(hasProperty('target') && target == 'android') {
jackson_version = "3.1.5"
jackson_annotations_version = "2.21"
- spring_web_version = "7.0.5"
+ spring_web_version = "7.0.8"
jakarta_annotation_version = "3.0.0"
bean_validation_version = "3.1.1"
</file context>
| jackson_annotations_version = "2.21" | ||
| jackson_databind_nullable_version = "0.2.11" | ||
| spring_web_version = "7.0.5" | ||
| spring_web_version = "7.0.8" |
There was a problem hiding this comment.
P2: The sample regeneration for the Spring Boot 4 templates is incomplete, leaving three samples internally inconsistent: build.gradle now declares spring_web_version = "7.0.8" while the matching pom.xml in the same directory still pins <spring-web-version>7.0.5. This affects restclient-springBoot4-jackson2, resttemplate-springBoot4-jackson2, and resttemplate-springBoot4-jackson3-jspecify (the other three Spring Boot 4 samples bumped both files consistently). As generated artifacts, these samples should be reproducible from the templates (whose pom.mustache is already 7.0.8), so a Maven-based user of these samples would resolve Spring 7.0.5 while a Gradle user gets 7.0.8 — exactly the kind of sample drift this PR's commit intends to fix. Please regenerate these samples (or update the pom.xml to 7.0.8) so the Maven and Gradle artifacts match.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At samples/client/petstore/java/restclient-springBoot4-jackson2/build.gradle, line 103:
<comment>The sample regeneration for the Spring Boot 4 templates is incomplete, leaving three samples internally inconsistent: `build.gradle` now declares `spring_web_version = "7.0.8"` while the matching `pom.xml` in the same directory still pins `<spring-web-version>7.0.5`. This affects restclient-springBoot4-jackson2, resttemplate-springBoot4-jackson2, and resttemplate-springBoot4-jackson3-jspecify (the other three Spring Boot 4 samples bumped both files consistently). As generated artifacts, these samples should be reproducible from the templates (whose pom.mustache is already 7.0.8), so a Maven-based user of these samples would resolve Spring 7.0.5 while a Gradle user gets 7.0.8 — exactly the kind of sample drift this PR's commit intends to fix. Please regenerate these samples (or update the pom.xml to 7.0.8) so the Maven and Gradle artifacts match.</comment>
<file context>
@@ -100,7 +100,7 @@ ext {
jackson_annotations_version = "2.21"
jackson_databind_nullable_version = "0.2.11"
- spring_web_version = "7.0.5"
+ spring_web_version = "7.0.8"
jakarta_annotation_version = "3.0.0"
bean_validation_version = "3.1.1"
</file context>
|
@cubic-dev-ai Fixed. I regenerated the samples so the Spring versions match. |
@SubhamAshok Looks right now. The key change is correct: chaining The sample regeneration looks consistent too — One small thing worth double-checking before merge: the Tip: get faster answers by chatting with cubic’s review copilot in the review UI |
…nverters (OpenAPITools#24587) Call builder.registerDefaults() inside configureMessageConverters lambda when useJackson3 is enabled in restclient library, ensuring default converters (ByteArray, String, Resource) are registered alongside Jackson. Fixes OpenAPITools#24587
…n3 (OpenAPITools#24587) Chain withJsonConverter(JacksonJsonHttpMessageConverter) directly on builder.registerDefaults() to substitute the JSON converter in-place without adding a duplicate converter to the chain.
b54df91 to
f8a8b87
Compare
|
@cubic-dev-ai Good catch! I updated the template to use |
@SubhamAshok That change is right, and I verified the API to back it. Spring's The rebase note about the unrelated JSONTest SHA mismatch makes sense too. I don't have any remaining concerns — this resolves the one open thread. Once CI is green, this is good to merge. Tip: get faster answers by chatting with cubic’s review copilot in the review UI |
|
@anatoly-tamarack @wing328 All requested changes have been made (including using |
3 participants
PR checklist
mvn clean install -DskipTests../bin/generate-samples.sh ./bin/configs/java*.Description of the Change
When generating the
restclientlibrary withuseJackson3=true,ApiClient.mustacheconfiguresJacksonJsonHttpMessageConverteronHttpMessageConverters.ClientBuilder. I believebuilder.registerDefaults()was accidentally omitted here. Without callingregisterDefaults(), standard Spring converters (such asByteArrayHttpMessageConverter,StringHttpMessageConverter, andResourceHttpMessageConverter) are not registered on the built client.Adding
builder.registerDefaults()insidemessageConvertersensures Spring's default converters remain registered alongside Jackson.Fixes #24587
cc @bbdouglas @s2308 @Javier20 @wing328 @jpfinne
Summary by cubic
Fixes missing Spring default HttpMessageConverters in
restclientwhenuseJackson3=trueby usingbuilder.registerDefaults().withJsonConverter(...), and switches XML towithXmlConverter(...)to prevent duplicates. Restores ByteArray/String/Resource support and avoids duplicate converters. Fixes #24587.ApiClient.mustacheto callbuilder.registerDefaults().withJsonConverter(new JacksonJsonHttpMessageConverter(mapper))andwithXmlConverter(new JacksonXmlHttpMessageConverter(xmlMapper)); add a regression test; regenerate samples.spring-webto7.0.8acrossrestclient/resttemplatetemplates and all Spring Boot 4 samples.Written for commit f8a8b87. Summary will update on new commits.