Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.5
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
Although I feel that it is not a good idea to heavily use polymorphism (by inheritance) when exchanging data (Json != Object graph), there are cases where this is useful. And perhaps full object serialization is something Jackson could eventually do well enough.
Currently it is hard to handle sub-classing correctly and generally without having a way to embed class information in Json transmitted. But if class information (qualified name should be enough) was added, it would be much easier to support proper deserialization to exact types (from serialization).
This of course also renders resulting Json somewhat less portable, since impls on other languages would achieve the same result some other way. That is probably acceptable risk, given that no one has to use such feature.
So.... It would make sense to have simple serialization/deserialization feature that:
- On writer (serialization) side would include "class" (or, "@class"?) member in beans that are serialized as Json Objects
- On reader (deserialization) side would look for the same member, and use that class as the value type, instead of declared type, or annotation-derived type.
In addition to global setting, perhaps similar annotation should be added that could be attached to class (to add such class declaration for class itself) and setters/getters (to add declaration for property method represents, iff it's serialized as a Json Object).
One thing to note is that this would not allow specifying container type of Collections, but it would still work for contents. This is probably acceptable deficiency as well.
-
Hide
-
-
jackson_test/bin/org/.../jaxb/Mike.class
-
jackson_test/bin/.../jaxb/MyJAXBObject.class
-
jackson_test/bin/.../ObjectFactory.class
-
jackson_test/bin/org/.../jaxb/IMike.class
-
jackson_test/bin/org/mike/Tester.class
-
jackson_test/.project
-
jackson_test/src/org/mike/jaxb/Mike.java
-
jackson_test/src/.../jaxb/ObjectFactory.java
-
jackson_test/src/.../jaxb/MyJAXBObject.java
-
jackson_test/src/org/.../jaxb/IMike.java
-
jackson_test/src/org/mike/Tester.java
-
-
Activity
Quick comment on polymorphism being frowned upon: I think this may be related to multiple things, like:
- Part of that may be serialization vs data binding impedance: as in, "object first" or "data first". If you view JSON data as the primary thing, there is no strict type structure, no identity, no behavior, just data. But starting with (Java) objects reverse is true. So from "purist" data binding/mapping perspective, metadata that is needed for serialization (type/class) seems like noise.
- It is also quite tricky to get polymorphism work right – this is not necessarily a good reason to be against that, as long as it can be made to work.
My view on this has evolved a lot, and although I think there is fundamental difference between views here I think Jackson can and should evolve to handle important aspects of both approaches. Jackson's background is data binding, so there is much more to do with serialization side; and it can not be done solely focusing on how to transfer java objects (if that was the goal, it'd be easy – could just use very strict serialization of class metadata etc, no need to allow custom JSON structures etc).
I'll try to add more thoughts on exact details tho: above is just some philosophic/background stuff, and not directly related to implemntation.
I was able to reproduce additional problems: difference between my test case and yours is that I only had public field with annotations.
Your code had annotation for the field, but not accessor/setter, and Jackson JAXB annotation introspector apparently does not link the two.
I assume JAXB does this (given that test case relies on linkage), so this seems like a discrepancy between Jackson and JAXB handling.
I will try to resolve this issue.
What concerns me a bit tho is that error message I get is somewhat different – looks like test case manages to make ObjectMapper think that polymoprhic type info is included, which should NOT be the case.
This is because plain @XmlElement does not indicate polymorphic type (but rather just specialization of single type), whereas @XmlElements does.
Hence test case should not actually use PTH, just "regular" type definition.
Anyway, one thing at a time, I will address the problem I do see and see if there are other problems lurking behind it.
Hello !
I was able to do a bit of polymorphic (de)serializing with Jackson 1.4 (not wanting to wait for 1.5 
), but I'd like to come up with something more "generic".
The idea is to add a "clazz" field to the parent for serializing, and to use a custom deserializer for this parent type, that first deserialize the bean to a map, look for the "clazz" key, and uses om.convertValue to convert the map to the real bean.
Here is the code :
************************
public class JacksonTestPolymorphic {
private static abstract class MyBean
{ public String name; public String clazz = getClass().getName(); } private static class SubMyBean1 extends MyBean {
public String myString;
@Override
public String toString()
}
private static class SubMyBean2 extends MyBean {
public double myDouble;
@Override
public String toString()
}
public static void main(String[] args) throws Exception {
final ObjectMapper om = new ObjectMapper();
CustomDeserializerFactory cdf = new CustomDeserializerFactory();
DeserializerProvider dp = new StdDeserializerProvider(cdf);
cdf.addSpecificMapping(MyBean.class, new JsonDeserializer<MyBean>() {
@Override
public MyBean deserialize(JsonParser arg0, DeserializationContext arg1) throws IOException,
JsonProcessingException {
Map<String, String> map = om.readValue(arg0, new TypeReference<Map<String, String>>() {});
Class clazz;
try
catch (ClassNotFoundException e)
{ throw new IOException(e); } return (MyBean) om.convertValue(map, clazz);
}
});
om.setDeserializerProvider(dp);
SubMyBean1 bean1 = new SubMyBean1();
bean1.name = "b1";
bean1.myString = "yeah !";
SubMyBean2 bean2 = new SubMyBean2();
bean2.name = "b2";
bean2.myDouble = 42;
String bean1AsJson = om.writeValueAsString(bean1);
String bean2AsJson = om.writeValueAsString(bean2);
System.out.println(bean1AsJson);
MyBean bean1Back = om.readValue(bean1AsJson, MyBean.class);
MyBean bean2Back = om.readValue(bean2AsJson, MyBean.class);
System.out.println(bean1Back);
System.out.println(bean2Back);
}
}
***********************
I used om.convertValue because I needed to read the Json to determine the real implementation class, and then delegate to the good deserializer.
There might be other ways to do so, without having to convert twice.
Also, adding a "clazz" field in the bean is not clean, I'd rather set a special Serialiser using @JsonSerializer. This Serialiser could then write the "clazz" property, but then I don't know how to delegate to the "real" expected Serializer. So here, the question is : how can we add fields (metadata) for some specific classes serialization in 1.4 ? Any kind of "InterceptorSerializer", that would let you serialize data before/after the std serializers for some specific classes ?
I may be going to far, or completely missing the point.. Please let me know
I'm just starting to use this feature by compiling the trunk and as far as I know the 1.5 is nearly the delivery (cool!).
So just a little note for the release if not yet identified: ObjectMapper.setDefaltTyping ==> ObjectMapper.setDefa*u*ltTyping
Is there any sample on how to customize default typing?
Actually,my use case is probably taken into account but I miss documentation (and time .
I want to force a specific implementation class B to be the default deserialization for an interface A.
And I'd like do it without introducing a dependency from A to B (@JsonSubTypes).
Do I have to use JsonTypeResolver? Any sample to make it easy?
Hi, after dealing with other stuff, I come back to my deserialization use case
Let's take the following sample: my objective is to avoid declaring JsonSubTypes on the mother class, to avoid coupling, by using mixins.
(Dog and Cat are part of two different packages, and Animal is used in a framework not knowing all animals in advance)
@JsonTypeInfo(use=Id.NAME, include=As.PROPERTY, property="objectType")
abstract class Animal { }
@JsonTypeName("doggie")
class Dog implements Animal { }
@JsonTypeName("kitty")
class Cat implements Animal { }
@JsonSubTypes (
{ @Type(value = Cat.class, name = "kitty") } )
static class MixinCat {
}
@JsonSubTypes(
{ @Type(value = Dog.class, name = "doggie") } )
static class MixinDog {
}
m.getDeserializationConfig().addMixInAnnotations(Animal.class, MixinDog.class);
m.getDeserializationConfig().addMixInAnnotations(Animal.class, MixinCat.class);
The problem here is that a mixin can only be associated to one and only one target class.
What I need would be kind of aggregation of annotations on all of my mixins and apply it to a target class.
Any idea on how to do that?
Probably by using tricky reflection/generation on annotations to generate the composite mixin.
Or change the underlying mixin map behavior to aggregate list of mixin per class (but I don't have the background to know if it would be right way).
But maybe I'm in the wrong direction and there's a totally different way (more at the annotation capability level).
One quick comment: one specific set of classes for which this is sorely needed are exceptions (Throwable and subtypes). For example,
JACKSON-95can only be partially resolved without resolving this issue. Put another way, adding class info will help a lot with exception deserialization.