-
Notifications
You must be signed in to change notification settings - Fork 563
Closed
Description
Given the following type arrangement:
@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property = "type")
@JsonSubTypes({
@JsonSubTypes.Type(value = First.class, name = "first"),
@JsonSubTypes.Type(value = Second.class, name = "second")
})
class Base {
@JsonIgnore String ignored;
String common;
}
class First extends Base {
String first;
}
class Second extends Base {
String second;
}
class Wrapper {
Base base;
}, the original state of the resource being:
Wrapper { base : First { ignored : "ignoredValue", common : "commonValue", first : "firstValue" } }represented as
{
"base" : {
"type" : "first",
"common" : "commonValue"
"first" : "firstValue"
}
}and a PUT request with this body
{
"base" : {
"type" : "second",
"second" : "secondValue"
}
}we expect to end up with server state equivalent to:
Wrapper { base : Second { ignored : "ignoredValue", second : "secondValue" } }most notably, the type of the inner object has changed from First to Second, the submitted state of the second property has been applied and the common value has been removed (PUT semantics) but the value of the unexposed ignored property has been properly transferred to the new instance.
This is currently broken as the object mapping tries to bind the values of the new object Second to the instance of the old one and ultimately doesn't apply the type change unless the class is annotated with Spring Data's @Immutable.
Metadata
Metadata
Assignees
Labels
type: bugA general bugA general bug