new ValidationAdapter<User, User>() {} should work I think
Regarding a deeper integration I'm not particularly against but have to
admit I don't really see a strong use case ATM (tend to think even
standalone code has a container these days, spring or cdi standalone so it
is easy to bind the validation on the event bus for instance and less
intrusive in the marshalling layer)
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
https://blog-rmannibucau.rhcloud.com
https://github.com/rmannibucau
2017-03-09 15:40 GMT+01:00 <gunnar.morling_at_googlemail.com>:
> > What about events - we pushed it back to v >1.0 to see if there
> > is any need
>
> That sounds interesting, I was wondering indeed, too, whether there'd
> be support for listeners somehow.
>
> > - instead of a hard dependency to bean validation?
>
> Note I'm not suggesting to make it a hard dependency, but rather an
> optional one, as done in JPA.
> I.e. BV would only be used if a BV provider is available but of course
> JSON-B would be perfectly usable without it.
>
> For the listener approach to be beneficial - in terms of saving the
> user some work - should there be a ValidationListener defined by the
> spec? Or implementations would provide one (reducing portability)?
>
> I feel the suggested more explicit integration may be easier to use.
> Nevertheless listeners seemed like a good addition.
>
> > Thinking a bit more i think adapters can already play that role if
> you use
> > a JsonbAdapter<A, A>, so do we really need something? Did someone try
> that
> > option?
>
> How would that look like? I just tried
>
> public class ValidationAdapter implements JsonbAdapter<Object,
> Object> { ... }
>
> Jsonb jsonb = JsonbBuilder.create(
> new JsonbConfig()
> .withAdapters( new ValidationAdapter( v ) )
> );
>
> But it wouldn't invoke that adapter during unmarshalling.
>
> --Gunnar
>