JSR-380 validation before serialization

[mluckam]

I am attempting to enforce JSR-380 validation after deserialization and before serialization without having a custom deserializer and serializer for each class. This is achievable before deserialization as shown in this baeldung article. Taking the same approach with serialization does not work because BeanSerializer.serialize is final.

A few questions:

1. Is there a suggested strategy to enforce validation before serialization?
2. Is there a reason that BeanSerializer.serialize is final?

Below is an example project showing this with two unit tests. Deserialization passes and serialization fails because serialization is not configured for validation.
sample project

[cowtowncoder]

There is probably no strict reason for BeanSerializer.serialize() being final -- class should not be sub-classed by any application/client code, but it should be possible for proxies or such to be generated.

So I'd be ok in removing final from there.

As to validation, I don't think there is any good hooks to add this in: this should not require sub-classing of serializers. But there is also the problem of requiring more metadata as context that may not be easy to solve.

Overall I think currently validation is best run separate from deserialization; but I'd be open to adding additional support for in-flow extension points. But I probably won't have time driving such efforts; can and will help as usual.

[cowtowncoder]

NOTE: BeanSerializer.serialize() no longer final since 2.18.0.

[goekay]

hey all, i needed this today and here is my attempt: steve-community/ocpp-jaxb#25

i was coming from the same baeldung article, and was able to create validation for serialization with a similar approach. therefore, the final access modifier was not a blocker for me. it works for my unit tests, but i am not sure how generalistic the impl is (i.e. whether there is an edge case it does not cover). hence, my message here. if someone finds something, please ping.

[mluckam]

@goekay

In my experience migrating to jackson3, I found a few edge cases in de-serialization to point out:

• In BeanDeserializerModifierWithValidation performing instanceof BeanDeserializer, your source misses out on deserializers that do not directly extend BeanDeserializer, ex BuilderBasedDeserializer. Instead the check should be instanceof BeanDeserializerBase. It appears you chose this strategy with serialization, your source.
• With the above change performed, BeanDeserializerWithValidation needs to extend DelegatingDeserializer to allow for the passing in of ValueDeserializer instead of BeanDeserializer. Using a delegate also addresses issues that arise with @JsonUnwrapped.

Looking at your serialization implementation I see that jackson-databind chose to implement a DelegatingDeserializer but not a DelegatingSerializer. There is a StdDelegatingSerializer, but this is not the same thing and a StdDelegatingDeserializer exists also. Having a DelegatingSerializer would also solve some of the edge cases mentioned above. Not sure why there was not symmetry of implementation, but possibly there is a reason.

[goekay]

@mluckam thanks for taking a look.

to be honest, i left the deserializer part as the baeldung article presented. i am aware of the delta you mention.

my initial attempt was with instanceof BeanDeserializerBase and my validating deserializer also extending BeanDeserializerBase. however, BeanDeserializerBase has so many abstract methods that need to be implemented:

and some of them are protected such that i cannot delegate to delegate's same method. very annoying.

then, for symmetry, i wanted deser approach use the same approach i am using in ser approach: extending ValueDeserializer<Object> and wrapping the original deserializer and delegating to it. however, i was facing errors as demonstrated in this PR's actions.

Caused by: java.lang.NullPointerException: Cannot invoke "tools.jackson.core.sym.PropertyNameMatcher.matchName(String)" because "matcher" is null
	at tools.jackson.core.base.ParserMinimalBase.currentNameMatch(ParserMinimalBase.java:498)
	at tools.jackson.databind.deser.bean.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:528)
	at tools.jackson.databind.deser.bean.BeanDeserializer.deserialize(BeanDeserializer.java:200)
	at de.rwth.idsg.ocpp.jaxb.validation.BeanDeserializerWithValidation.deserialize(BeanDeserializerWithValidation.java:24)

at the end of the day, and after both of these attempts failing, i left the deser part as is.

it is kind of surprising how many hurdles there are just to add a simple bean validation hook :)

edit: here is the impl adapted to your observations/suggestions. i hope i understood and followed them correctly. tests fail.

[mluckam]

I think that code could help more than words in this case. Here is an example of my implementation, serialize-validation-injection. A few differences between our two implementations.

[goekay]

thanks @mluckam adjusted my impl after your example: https://github.com/steve-community/ocpp-jaxb/pull/28/changes

also added overridden impl for deserializeWithType(JsonParser p, DeserializationContext ctxt, TypeDeserializer typeDeserializer) for completeness.