Announcement Announcement Module
Collapse
No announcement yet.
Jackson Mixins vs. direct annotations Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Jackson Mixins vs. direct annotations

    Hi! I am trying to figure out a good way to handle Tumblr adding new fields to their responses, in my Spring Social Tumblr code. (https://github.com/sdouglass/spring-social-tumblr) I don't think just putting @JsonIgnoreProperties(ignoreUknown=true) on my classes is the best solution, as the new fields then are ignored and inaccessible. I'd like to try to use @JsonAnySetter to store the unknown values in a Map so that deserialization won't break if there are new fields and so people can still access them if necessary. So far I've used Jackson Mixins but now I'm thinking I'm going to wind up needing to modify all my data classes and all my mixins and making mixins for data classes where I didn't have them before, to add this new functionality. That seems like a lot of work, vs. if I were just directly annotating my data classes I could just create a new base class for them that has a Map<String, Object> and a @JsonAnySetter annotated method they could all inherit.

    Anyway, mixins seem cool in that they keep my data classes free of Jackson annotations but now they're feeling like a roadblock to what I want to do. So my question is, is it OK to skip mixins for a Spring Social library and just directly annotate classes with Jackson annotations? Most of the examples I worked from used mixins, so I'm wondering if that's a best practice I should stick to even if it becomes time consuming and unwieldy.

  • #2
    You're free to not use mixins if you don't want to use them. The key benefit of using mixins, though, is that they keep those model objects "clean" and free of any Jackson-specific code. And they also act kinda like mapping configurations (ala, old-school Hibernate XML files) expressed in Java.

    But I see what you're trying to do and how mixins might make that tricky. I wonder, though...would it be possible to have the base class with Map<String, Object> and @JsonAnySetter already in place and have the more specific subclasses continue to use mixins? (I don't know...I've not tried it.) But it's a worthwhile thing to try. That way you don't break the benefits of mixins, but you still get the benefit of a base class to carry the other, otherwise unhandled properties.

    Comment


    • #3
      That's actually the approach I've landed on trying out first, for now, adding the base class and putting the @JsonAnySetter in there but still using mixins with the subclasses. I'm not able to test it out at the moment, but I'll reply with results once I'm able to test it and see if it still works. I think you're right, that will sort of blend the good things about both approaches, so hopefully it will work. Thanks!

      Comment


      • #4
        That approach seems to work! Thanks a lot for your response. This should make my code a lot more robust/future-proof.

        Comment


        • #5
          That's awesome to hear that it works. Knowing that, I might use that technique in a few other places to accomplish the same thing you're doing.

          Comment

          Working...
          X