What about events - we pushed it back to v >1.0 to see if there is any need
- instead of a hard dependency to bean validation?
Jsonb jsonb = JsonbBuilder.create(new JsonbConfig()
.withListeners(myJsonbListener));
@AppScoped
public class MyJsonbListener<T> implement JsonbListener { // we would use
default empty methods in the interface for user convenience
@Inject Validator validator;
@Override
public void onUnmarshall(T instance) {
....validate and throw violation exception if needed
}
}
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?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
https://blog-rmannibucau.rhcloud.com
https://github.com/rmannibucau
2017-03-09 12:49 GMT+01:00 <gunnar.morling_at_googlemail.com>:
> Hi Romain,
>
> > Do you have some more cases?
>
> I think it's mostly manually performed unmarshalling which would
> benefit from this:
>
> Jsonb jsonb = JsonbBuilder.create(
> new JsonbConfig()
> .withValidationMode( CALLBACK ) // or AUTO/NONE as in JPA
> .withValidationGroups( MyBasicConstraints.class )
> );
>
> // if the call returns, a valid instance is guaranteed
> // otherwise a ConstraintViolationException is raised
> Person personLoaded = jsonb.fromJson( jsonRepresentation,
> Person.class );
>
> That way people could configure a validating JsonbBuilder and e.g.
> expose it as CDI bean within their application. Wheras no validation
> would occur during unmarshalling performed by integrators such as
> JAX-RS.
>
> I.e. it'd just be an option to obtain an automatically validating
> JsonbBuilder, saving users from writing some glue code.
>
> --Gunnar
>