Hi Gunnar,
thought to it as well but then thought "where would it be used", here few
cases which went to my mind immediately:
- JAX-RS ("dto" even if this word is no more trendy)
- JPA (serialization of a complex object in the DB, not sexy but "common")
- Service model passing (summarize it as CDI)
- ...
All these technologies are as you mentionned already integrated with BV so
it would lead to a double validation most of the time so think we are
"good" enough and consistent current.
So question was "which case doesnt have BV?". With CDI integration I
quickly concluded it was rare enough to not require anything in the spec
and ask for it. Do you have some more cases? BTW JAXB is not integrated too
AFAIK and it doesnt seem to miss there as well.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
https://blog-rmannibucau.rhcloud.com
https://github.com/rmannibucau
2017-03-08 17:34 GMT+01:00 <gunnar.morling_at_googlemail.com>:
> Hi,
>
> I'm the lead of Bean Validation 2.0 (JSR 380) and have been following
> the development of JSON-B with great interest.
>
> One thing I was wondering is whether it'd be helpful to integrate the
> two technologies. More specifically, JSON-B could trigger a validation
> of the unmarshalled object in the course of fromJson() calls - in case
> a Bean Validation provider is present. That way people would be sure to
> hold a valid instance in their hand after unmarshalling. Of course
> there could be an option to turn off validation entirely and it'd
> likely make sense to have this as the default so to not validate twice
> when e.g. using JSON-B via JAX-RS.
>
> It'd be just a small addition but I think it make the life of users
> simpler, as they don't need to explicitly trigger validation but it'd
> happen automatically for them, which is a pattern successfully employed
> by JPA, JSF, JAX-RS and other specs.
>
> Looking foward to your feedback and hearing what you think about this
> proposal.
>
> Thanks,
>
> --Gunnar
>