Add post-processing (deserialization) hook, like @JsonPostDeserialize

I am not sure this is something Jackson should handle: that's what JSR-303 (Bean Validation API) is about. So this omission is deliberate.

But I am not against someone writing a module (and adding hooks it needs, if any, from core) that would offer such validation functionality.
In fact, using a JSR-303 implementation as the validator would make lots of sense. I just don't see this as something core or mapper should specifically implement.

can you please link me to the source of such module already done right? (outside of your source, independent effort?); and link for adding hooks?

may be you should expose generic interface for JSR-303 in your core?

I am open to adding necessary hooks, but would need to get better idea as to what this should look like. I guess it would be sort of post-binding callback.
I am not quite sure how useful this would be, mostly since what I do myself (just call validator after data binding) seems straight-forward and explicit; and keeps separate concerns (data binding, data validation) separate.

But if a generic post-binding callback made sense for multiple use cases, this could be added.

here is my use case du jour:

I deserialize object form json; object has field: [String iconURL];
this happens in osgi plugin which must convert url from [String] to [URL] in current bundle classloader before this object will be used in another bundle (which has different classloader, and can not see resource url from current bundle)

so "post-binding callback" in this case would load:
URL url = getClass().getClassLoader().getResource(iconURL)

as a last step of deserialization

so you are right: this is not @JsonMandatory it is @JsonPostDeserialize
and it allows essentially to avoid making a custom deserializer
for cases when you just need to tweek a couple of fields
along with validation / default value enforcement

Actually I think it would be reasonable to have both: will leave this one for @JsonMandatory (which might make sense to add actually), also create @JsonPostDeserialize for separate RFE.

Hello,

I'm just catching up with this thread, as I was looking to see if Jackson had such hooks. My only suggestion against @JsonMandatory is that it is only convering one facet of JSR-303 validation (for example, in addition to @NotNull, which I suppose would be the implied equivalent of @JsonMandatory, JSR-303 has things like @Min(2). I presume that is why Andrei suggested "@JsonPostDeserialize", as I think what we are seeking is an annotation that says "call JSR-303 validation, whatever that is", and leave the "what" to the JSR-303 annotations themselves. May I suggest @JsonValidate?

Also, I would be glad to help with this if I can get familiar with the sources, or write unit tests.

Hi Tatu,

Yes, it makes perfect sense, having jsr303 specific hooks build on top of the generic post-deserialization hook. The only thing I may add is: should this exist in serialization too?

Regards,

Alex

Good question. If history is any guidance, there's high chance of wanting something similar eventually, even if it wasn't immediately obvious.
But I think we can split this in two parts: hook to call should probably differ anyway, and it might be that one rather wants "pre-serialization" hooks... so we can add another Jira entry for serialization side.

Sounds great. If you'd like, once you have the post-deserialization hook in place, I could take a stab at doing the jackson4jsr303 one. Or let me know if I can help in any way.

Cheers,

Alex

Definitely, I could use help with jsr303 module, once hook is added. It may take a while, given large number of items to work on 1.9, but it sounds like one of more important features to add.

Glad to hear it. I'm getting familiar with it myself, so hopefully I'll be able to contribute by the time you get this in 1.9. I am watching this jira, so I'll keep an eye out for an email sometime.

Just realized one practical concern: for validation, annotation should only apply to root value, since it is recursive. But for other kinds of post-processing, makes more sense to apply to all pojos.
So it is quite possible that hook for specific validation use should be different after all; something to call after root-level readValue() call.

Good morning Tatu,

Let's see if I am understanding you correctly: if you have class A instance that has class B instance as a child, would you expect the implementor to call the hook by annotating class A only, and jackson recurse through to B, or would the post processing callback provide the root level object to the method, and the implementor decides on the scope of their callback?

Alex

I remember Bean validators to do recursive validation (depending on annotations), which makes sense, otherwise calling app would indeed have to manually implement recursive solution. And without validation framework doing this there are many things that can not really be verified.
So for that use case calling validation-hook for all POJOs would cause lots of unnecessary calls.

I am basically suggesting possible need for two kinds of callbacks; one only for the mapper.readValue() context, and another for each time object was complete. Latter actually requires lots of work just because each and every deserializer would need to be aware of having to check for registered listeners.

That makes sense. Maybe you can wait on the latter, more complicated use case, until you see a need?

Note: JACKSON-767 now exists for adding something simple like:

@JsonProperty(required=true)

which would handle '@JsonMandatory' use case; but no additional post-processing.

Closing as part of move to github issues. Does not mean this isn't on our radar; need to have an entry at jackson-databind project, either specific for use case (check-is-required), or generic.

Main challenge is still the fact that BeanDeserializer has too many codepaths, and passing of state is difficult currently.