Repository navigation
[pull] master from OpenAPITools:master - #803
Merged
Merged
Conversation
…of the container (HV000271) (#24176) Hibernate Validator 9.1+ (bundled with Spring Boot 4) logs HV000271 ("Using @Valid on a container is deprecated. You should apply the annotation on the type argument(s)") for every @Valid-annotated List/Set/Map — on both model properties and API parameters. This relocates @Valid from the container to its type argument — the Bean-Validation-2.0 form (List<@Valid T>, Map<String, @Valid V>) — which cascades identically but is not deprecated. Backward-compatible: element validation is preserved, never dropped; single-object @Valid is untouched. Verified on Spring Boot 3.3 (Spring 6.1) and 4.1 (Spring 7): a container parameter carrying only the type-argument @Valid still triggers element validation via method validation, with no HV000271. Scope (Java family): spring, java client, JAX-RS (jersey, resteasy(+eap), cxf(+extended/cdi), spec), java-camel, java-msf4j. Models (property/getter): the container @Valid is moved to the type argument. Map values are gated behind a new AbstractJavaCodegen#useBeanValidationOnMapValueType() (default false; overridden true in Spring/JavaClient/JAX-RS) so untouched generators don't silently gain map-value validation. Arrays/sets already injected the type-argument form. oneOf/anyOf/allOf model elements now also receive the type-argument @Valid (List<@Valid ShapeOneOf>), so their element validation is preserved rather than dropped; a oneOf of constants (an enum) stays without @Valid. Parameters (@RequestBody/@RequestParam/@RequestPart): the redundant container-level @Valid is dropped for container parameters; element validation is driven by the type-argument @Valid. Single-object parameters keep @Valid. An Optional-wrapped scalar parameter (useOptional, e.g. Optional<Integer>) no longer emits a parameter-level @Valid either — Hibernate Validator treats Optional as a container, so it was the same HV000271 with nothing to cascade into. Reactive Mono/Flux bodies are intentionally untouched (not Jakarta containers, so no HV000271). Regenerated all affected samples and added/updated codegen tests in SpringCodegenTest, JavaClientCodegenTest, JavaJAXRSSpecServerCodegenTest and JavaValidationArrayPrimitivesTest.
…ackson-default-impl / typeInfoDefaultImpls support to allow specifying of fallback schema when deserializing (#23955) * feat(kotlin-spring, java-spring): add x-jackson-default-impl / typeInfoDefaultImpls support Emit `@JsonTypeInfo(defaultImpl = ...)` for both deduction-based and discriminator-based oneOf interfaces. Two configuration sources (config option takes precedence): - Schema extension: `x-jackson-default-impl: ClassName` - Config option: `typeInfoDefaultImpls: {SchemaName: ClassName}` The resolved class name passes through `toModelName()` so schemaMapping, importMapping, and DTO prefix/suffix are all honoured. A LOGGER.warn is emitted when the config option shadows a schema-level annotation. * implement CR feedback suggestion * feat: move TYPE_INFO_DEFAULT_IMPLS to CodegenConstants and extend to Java generators - Add TYPE_INFO_DEFAULT_IMPLS/DESC constants to CodegenConstants (addresses reviewer request to avoid duplication across SpringCodegen and KotlinSpringServerCodegen) - Move typeInfoDefaultImpls field, option registration, processOpts parsing, and x-jackson-resolved-default-impl resolution loop from SpringCodegen into AbstractJavaCodegen so all Java generators inherit the feature - Remove duplicated code from SpringCodegen; update KotlinSpringServerCodegen to reference CodegenConstants.TYPE_INFO_DEFAULT_IMPLS and apply the same safe instanceof cast fix already present in SpringCodegen - Update Java/deductionAnnotation.mustache: emit defaultImpl = X.class on @JsonTypeInfo(use = DEDUCTION) when x-jackson-resolved-default-impl is set - Update Java/typeInfoAnnotation.mustache: emit defaultImpl = X.class on both @JsonTypeInfo(use = NAME) variants (discriminator present/absent) via discriminator.vendorExtensions.x-jackson-resolved-default-impl - Add JavaClientCodegenTest tests covering deduction, discriminator, typeInfoDefaultImpls config option, and absence cases for Java client Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * update documentation * document the new vendor extension * feat: add warning for unresolved models in vendor extensions * update documentation * address CR feedback and update documentation * address CR feedback and update documentation * address CR feedback and update documentation * add to kotlin-client as well. * add compiled samples * fix compiled samples * implement CR feedback * updated samples * updated samples * Update samples and documentation Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix Jackson defaultImpl oneOf resolution and related issues - Extract shared JacksonDefaultImplResolver used by AbstractJavaCodegen, KotlinClientCodegen and KotlinSpringServerCodegen (dedup resolution logic) - Preserve external/FQN class names for defaultImpl (add import, emit simple name) instead of mangling them through toModelName - JavaMicroprofileServerCodegen: strip x-jackson-default-impl before model post-processing so the vendor extension no longer leaks defaultImpl - Guard typeInfoAnnotation with discriminator in Java/oneof_interface.mustache so deduction-based oneOf keeps defaultImpl and drops the bogus property="" - Correct kotlin-client typeInfoDefaultImpls description (discriminator/jackson only) and regenerate docs/generators/kotlin.md - Move ext{} version block before the android branch in Java build.gradle templates (base + 12 libraries) to fix -Ptarget=android config failure - Default stricter generateJsonInclude/JsonSetterNulls options on Spring-family jackson-default-impl configs and render them in java-camel-server pojo - Add useDeductionForOneOfInterfaces to the restclient sample config - Regenerate all affected samples Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix oneof interface annotation regressions and webclient jspecify ordering - oneof_interface.mustache: render typeInfoAnnotation for non-discriminator oneOf when not using deduction, so sealed oneOf interfaces keep their @JsonTypeInfo/@JsonIgnoreProperties (byte-for-byte stable with master); only suppress it in the deduction path to avoid a duplicate @JsonTypeInfo - deductionAnnotation.mustache: add a leading newline and render at column 0 (mirroring typeInfoAnnotation) so @JsonTypeInfo no longer lands on the same line as @generated - webclient build.gradle.mustache: move the stray jspecify implementation out of the ext{} block into dependencies{} so it runs after the java plugin creates the implementation configuration (fixes useJspecify=true builds while keeping ext{} before the android branch) - Regenerate affected Java client samples Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Use Locale.ROOT with String.format in JacksonDefaultImplResolver The forbiddenapis check rejects locale-dependent String.format(String, Object...). Pass Locale.ROOT explicitly, matching the convention used across the codegen language classes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Revert "Use Locale.ROOT with String.format in JacksonDefaultImplResolver" This reverts commit 9cfd134. * Reapply "Use Locale.ROOT with String.format in JacksonDefaultImplResolver" This reverts commit 57f56be. * updated samples --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ibraries (#24971) * fix(spring): honor useTags=false for HTTP interface libraries - SpringCodegen: include spring-http-interface in supportLibraryUseTags() so useTags=false groups operations by first path segment instead of tag. - KotlinSpringServerCodegen: include spring-declarative-http-interface in the addOperationToGroup path-grouping condition alongside spring-boot. spring-cloud was deliberately left out of this condition since useTags defaults to false there and changing it would alter existing default grouping behavior for that library. - Add regression tests covering useTags=false/true grouping for both spring-http-interface and spring-declarative-http-interface. - Update two pre-existing kotlin-spring tests whose expected output filenames assumed the old (buggy) tag-based grouping for spring-declarative-http-interface. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * fix(spring): sanitize path segments to valid Java identifiers for HTTP interface; update samples * fix(spring): preserve unique HTTP interface path groups Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * fix(spring): normalize HTTP interface path groups Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * fix(spring): handle empty HTTP interface path groups Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Jáchym Metlička <metlicka@2n.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Jachym Metlicka <krisna.visnu@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )