Polymorphic deserialization regression in 2.8.1 #1311
Comments
|
Interesting. I just saw the test failure in DW test suite, and was wondering whether there might be type hierarchy issue that was only now uncovered. But the test code seems solid enough suggesting an actual problem with validation Jackson does. Thank you for reporting this and providing a clear test case for reproduction. |
|
Also seems to specifically require discordant combination of expected type, and default implementation type, which somewhat explains why no test case covered this. |
|
Hmmh. And... this may be tricky to actually fix. There is a real problem due to example code supplying But at the same time it would seem like there should be a better way to handle this. Since I think this failure came from DropWizard test suite, I can have a look at test to see if type handling there makes sense. |
|
More that I look at DropWizard case, more confused I am. Test itself does nothing wrong, it just relies on definition of |
|
Ah. Found the culprit, it is a test artifact. Will do a PR for DropWizard, regardless of whether there is more work to be done on Jackson side. As to Jackson, it might make sense to walk the inheritance chain to see if a compatible supertype might be found "close enough"... however, heuristics may or may not work. And fundamentally doing this would trade one type of failure to another one, so hard to say a priori if it's worth it. |
|
Hi, we are experiencing almost same issue with indirect use of concrete subtype of an abstract type. From our point of view this is valid use case and this issue blocks us from upgrading to Jackson 2.8. Jackson 2.8.1, with 2.7.x work just fine. Reduced test case: import java.io.IOException;
import com.fasterxml.jackson.annotation.JsonTypeInfo;
import com.fasterxml.jackson.databind.ObjectMapper;
public class Jackson1311 {
@JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, defaultImpl = B.class)
public abstract static class A {
}
public static class B extends A {
}
public static class C extends A {
}
public static class X {
public C c;
}
public static void main(String[] args) throws IOException {
ObjectMapper mapper = new ObjectMapper();
mapper.readValue("{}", X.class);
}
}Exception thrown: |
|
@azuritus I am sorry but strictly speaking this is not legal or safe. Wouldn't it physically fail if you had JSON like: because value for Now, if you do happen to have legal default implementation class that extends |
|
I have another example of where this is broken. Here is a very simple test case that works fine with Jackson 2.7.5 but is broken with Jackson 2.8.1. package jackson.test;
import org.junit.Test;
import com.fasterxml.jackson.databind.ObjectMapper;
public class BrokenJackson {
@Test
public void test() throws Exception {
ObjectMapper objectMapper = new ObjectMapper();
final JacksonChild childObject = new JacksonChild();
String value = objectMapper.writeValueAsString(childObject);
objectMapper.readValue(value, JacksonChild.class);
}
}package jackson.test;
import com.fasterxml.jackson.annotation.JsonIgnoreProperties;
import com.fasterxml.jackson.annotation.JsonInclude;
@JsonIgnoreProperties(ignoreUnknown = true)
@JsonInclude(JsonInclude.Include.NON_EMPTY)
public class JacksonChild extends JacksonParent {
}package jackson.test;
import com.fasterxml.jackson.annotation.JsonIgnoreProperties;
import com.fasterxml.jackson.annotation.JsonInclude;
import com.fasterxml.jackson.annotation.JsonSubTypes;
import com.fasterxml.jackson.annotation.JsonTypeInfo;
@JsonTypeInfo(use = JsonTypeInfo.Id.NAME,
include = JsonTypeInfo.As.PROPERTY, property = "type",
defaultImpl = JacksonParent.class)
@JsonSubTypes({ @JsonSubTypes.Type(value = JacksonChild.class, name = "child") })
@JsonIgnoreProperties(ignoreUnknown = true)
@JsonInclude(JsonInclude.Include.NON_EMPTY)
public class JacksonParent {
}If you run the test case with these 3 classes, the resulting stacktrace is: |
|
@cshannon that looks like possible bug indeed. Given that there may be multiple distinct issues and/or root causes, would it be possible to create a separate GH issue, with sample code you gave? It is otherwise difficult to track down fate of specific reported pieces. |
|
@cowtowncoder , no problem, I created a new issue here with the same code example : #1339 |
|
As per earlier comment, I think the original case is failing as designed, and the second case is a new issue. |
Version: 2.8.1
When attempting to update DropWizard to 2.8.1, I encountered a regression in polymorphic deserialization. Here's a sample testcase to illustrate the problem.
Expected results: No error.
Actual results: Exception:
The text was updated successfully, but these errors were encountered: