I did some research and figured out that while this does not work:

data class ContactCreateRequest(
	@JsonUnwrapped
	val person: Person,
)

this does:

data class ContactCreateRequest(
	@field:JsonUnwrapped // Apply @JsonUnwrapped to field
	val person: Person,
)

The decompiled byte code for those look like that:

public final class ContactCreateRequest {
   @NotNull
   private final Person person;

   public ContactCreateRequest(@JsonUnwrapped @NotNull Person person) {
      Intrinsics.checkNotNullParameter(person, "person");
      super();
      this.person = person;
   }
   
   @NotNull
   public final Person getPerson() {
      return this.person;
   }
// ....
}

vs

public final class ContactCreateRequest {
   @JsonUnwrapped
   @NotNull
   private final Person person;

   public ContactCreateRequest(@NotNull Person person) {
      Intrinsics.checkNotNullParameter(person, "person");
      super();
      this.person = person;
   }
   
   @NotNull
   public final Person getPerson() {
      return this.person;
   }
// ....
}

Funny thing is that if I try to replicate the first approach with pure Java, @JsonCreators with @JsonUnwrapped are not supported yet:

public class Book {
    private final Author author;
    private final String title;

    public Book(@JsonUnwrapped(prefix = "author_") Author author, @JsonProperty("title") String title) {
        this.author = author;
        this.title = title;
    }
}

Exception in thread "main" com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Invalid type definition for type `com.example.demo.Book`: 
   Cannot define Creator parameter 0 as `@JsonUnwrapped`: combination not yet supported

This must be the Kotlin plugin doing some magic on top of default Jackson. This however is expected to change in the next Jackson minor release with FasterXML/jackson-databind#1467 merge.

Given that in this example ContactCreateRequest used for request body, it is deserialisation "view" that should be considered. It looks like the lookup for @JsonUnwrapped since 2.5.0 has been reduced to looking at field annotations only.
Both for Kotlin support and upcoming support of creators + unwrapped, I believe springdoc should bring the support back at looking for @JsonUnwrapped in creators and should distinguish between deserialisation and serialisation configurations.

@wingsofovnia,

There is no code in Springdoc responsible for JsonUnwrapped causing this behavior.
Looks like i will count on your deeper analysis!

@bnasslahsen there is though. I am afraid this is a bug in PolymorphicModelConverter#resolve.

I've just replicated the issue on 2.8.4. This condiiton:

Is not going through because the annotation is on the getter, which is valid placement of this annotation too. Once I force this via debugger:

Please re-open the ticket.

@wingsofovnia,

I am merging your PR now.

Hi,
I have an issue with the fix.

If you have a class like the next one, then the isUnwrapped boolean in the PolymorphicModelConverter is now false, but it was true before :

public final class ContactCreateRequest {

   @JsonProperty(access = JsonProperty.Access.READ_ONLY)
   @JsonUnwrapped
   private final Person person;

   public ContactCreateRequest(Person person) {
      this.person = person;
   }
   
   public final Person getPerson() {
      return this.person;
   }
}

I am talking about this line:
Before, isUnwrapped was true:

Now, isUnwrapped is false:

Wouldn't there be an other way to get the annotation ?