Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      1

      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.

        Activity

        Hide
        Fabrice Delhoste added a comment -

        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).

        Show
        Fabrice Delhoste added a comment - 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).
        Hide
        Tatu Saloranta added a comment -

        Yes, current assumption is that there is just one mix-in per target class.
        This could be changed with more work. But I am not sure if this is the optimal path to take all things considered.
        I was about to suggest sub-classing, but since annotations just mask each other, and not add,
        it would not help.

        I think better approach will be to add a specific non-annotation based method for declaring sub-classes; and possibly even helper classes for
        automatic discover (like jersey and other packages have: give a package name, and they go
        and find all classes in that package; this is heuristic based on class loader, files etc,
        but seems to work).

        I think there is already an issue for this... yes, JACKSON-257.

        Show
        Tatu Saloranta added a comment - Yes, current assumption is that there is just one mix-in per target class. This could be changed with more work. But I am not sure if this is the optimal path to take all things considered. I was about to suggest sub-classing, but since annotations just mask each other, and not add, it would not help. I think better approach will be to add a specific non-annotation based method for declaring sub-classes; and possibly even helper classes for automatic discover (like jersey and other packages have: give a package name, and they go and find all classes in that package; this is heuristic based on class loader, files etc, but seems to work). I think there is already an issue for this... yes, JACKSON-257 .
        Hide
        Tatu Saloranta added a comment -

        Included in 1.5.0

        Show
        Tatu Saloranta added a comment - Included in 1.5.0
        Hide
        Jesper Peterson added a comment -

        Just a reminder of the type identified by Fabrice Delhoste is still in 1.5.6

        ObjectMapper.setDefaltTyping ==> ObjectMapper.setDefa*u*ltTyping

        Show
        Jesper Peterson added a comment - Just a reminder of the type identified by Fabrice Delhoste is still in 1.5.6 ObjectMapper.setDefaltTyping ==> ObjectMapper.setDefa*u*ltTyping
        Hide
        Tatu Saloranta added a comment -

        Holy guacamoley. I totally missed that one... thanks.

        Also, with respect to ability to register subtypes; JACKSON-257 was implemented for Jackson 1.6, so it is now possible to register subtypes without annotations.

        Show
        Tatu Saloranta added a comment - Holy guacamoley. I totally missed that one... thanks. Also, with respect to ability to register subtypes; JACKSON-257 was implemented for Jackson 1.6, so it is now possible to register subtypes without annotations.

          People

          • Assignee:
            Tatu Saloranta
            Reporter:
            Tatu Saloranta
          • Votes:
            17 Vote for this issue
            Watchers:
            16 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: