Is there any jackson json strategy (using annotations or another way), that will execute some logic prior and post deserialization of field?
Asked Answered
U

2

12

I need to execute some code after each deserialization is done on a POJO's fields. Is there any way I can do this through some jackson annotation (or other) strategy?

  1. One way to go with this is create a custom deserializer for each field type that will implement PostLogicDeserializerInterface or extend some PostLogicDeserializerAbstract. But this will make loads of cluttering code that will be hard to maintain (instead of just using @JsonProperty). So I think this is not a good idea.

  2. I saw that you can use @JsonDeserialize on class level but only for value classes. From the documentation:

When annotating value classes, configuration is used for instances of the value class but can be overridden by more specific annotations (ones that attach to methods or fields).

So I think this won't work, either.

  1. Using some custom logic in the POJOs setter methods is a bad practice! And on the other side, I think jackson uses reflection to set the fields anyway... Not a good strategy, neither.

My goal is to determine the percentage of fields that were set by the deserializer. I would need to have a counter that will increase on each invoked deserialization (populated field). And once the whole class(POJO) deserialization is over, I would need to execute some logic using reflection.

The way I have that implemented now, is

  • once I have the POJO deserialized by the jackson mapper, I go through each field using reflection
  • check if it has been set, f.i. if it is null or -1 for primitive numbers (previously initial values). (one conn of this approach is that you can't check a boolean if it was set)
  • use reflection for some other kind of checking (lets call it logic X)
  • execute logic that depends on percentage of set fields and logic X.

I would prefer some jackson strategy, since I wouldn't need to check the POJO with reflection. It would rather be done in place (at the time the POJO gets deserialized).

Cheers,
Despot

Unship answered 2/4, 2011 at 10:32 Comment(0)
W
5

There isn't any specific feature to do post- or pre-processing at this point; and this sort of gets close to boundaries of what data binding should do. If I had to do this for specific fields, I would probably just add it in setter, since that is simple thing to do and works; but requires same logic in all relevant setters.

@JsonDeserialize can also be used for individual properties (field, setter), so you could create a custom deserializer: and since you want post-processing, you could just locate "real" deserializer (ideally by making JsonDeserializer implement either ContextualDeserializer or ResolvableDeserializer -- this may not matter here, but for general case it's done here to avoid problems with cyclic dependencies), delegate to it, and modify value. This assumes it is value you care about more than field.

Finally, there are also ways to modify BeanDeserializer instances (by registering BeanDeserializerModifier) -- you could sub-class relevant components (SettableBeanProperty I think...) to hook in additional handling, or even replace deserializer to use, keeping a reference to the original "default" deserializer.

But in the end, your case sounds like something that may be best handled by something else: for example Bean Validation API (jsr-303) seems like a potentially good match for post-processing logic. Since it is somewhat orthogonal to data binding, it could be a superior alternative since it would be independent of data binding (jackson), reusable, all the good stuff.

Washstand answered 2/4, 2011 at 18:14 Comment(2)
I am not sure if, by using Bean Validation API (jsr-303), it is possible to create logic on each invocation of a setter method (update an instance field like a counter) and on end of deserialization doing some other logic. As far as I could see, this specification only allows (and is intended for) validation purposes. Any other suggestions?Unship
Correct: can't do it on sets, so re-reading your use case, it wouldn't really work. I think BeanDeserializerModifier might then the way to go -- it does require bit elaborate code on changing SettableBeanProperty instances (which do actual per-field work), but it would be place to add more work, as you know property in question, value being set. But you would be able to reuse existing code for actual data binding.Washstand
T
0

Another way is to use @JsonCreator to mark a constructor which will receive the data. Inside the constructor, you have full control over how to assign them to fields.

Tody answered 13/12, 2020 at 9:52 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.