2017-03-09 17:45 GMT+01:00 <gunnar.morling_at_googlemail.com>:
> > new ValidationAdapter<User, User>() {} should work I think
>
> Ok, I kinda hoped one wouldn't need one validation adapter per type.
> One single generic implementation should actually suffice.
>
> But I tried what you suggest with the RI and my adaptor is invoked now,
> but I'm ending in an stack overflow exception:
>
> at
> org.eclipse.yasson.internal.serializer.AdaptedObjectSerializer$AdaptedO
> bjectSerializerModel.getCustomization(AdaptedObjectSerializer.java:71)
>
> It seems it's calling the adapter again and again as the input and
> output type are the same. So this route seems not viable?
>
>
Sounds like a bug we should fix, nothing prevents it. Same for Object,
should be usable as a wildcard too.
> > 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)
>
> I hear you; and yes, people could put a validation decorator around
> JsonbBuilder and expose it as managed bean for their DI framework. The
> proposal would make life just a tad easier also for those not knowing
> the ins and outs of decorators and the like which is why I thought I'd
> bring it up.
>
And also way harder for all frameworks cause in 99% of the cases this will
be configurable cause in properties and not usable cause hidden in the
framework stacks (think to jaxrs for instance where marshalling is not part
of the business code so you can't help. Now take the opposite case: a lib
using jsonb to read its config. Here it makes sense to integrate with BV
but then the lib will likely have the validator as an option and all the
needed hooks to call validate itself and wrap the exception in
MyLibException which would likely be the expected behavior there. no?