2017-03-09 23:26 GMT+01:00 <gunnar.morling_at_googlemail.com>:
> Hi Romain,
>
> > 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
>
> I'm not quite following. Integrators doing their own validation
> anyways, such as JAX-RS, wouldn't use this feature in JSON-B. So how
> would things get harder for them?
>
> > a lib using jsonb to read its config. Here it makes sense to
> integrate
> > with BV
>
> Right, that's the use case I'd have in mind. As you say, they could
> validate themselves. Having support for this in JSON-B would just make
> this case a bit simpler.
>
> It'd be
>
> Validator validator = Validation.buildDefaultValidatorFactory()
> .getValidator();
>
> Jsonb jsonb = JsonbBuilder.create();
>
> Person p = jsonb.fromJson( "...", Person.class );
>
> Set<ConstraintViolation<Person>> violations = validator.validate( p
> );
> if ( !violations.isEmpty() ) {
> // throw some exception
> }
>
> Vs.
>
> Jsonb jsonb = JsonbBuilder.create(
> new JsonbConfig()
> .withValidationMode( CALLBACK )
> );
>
For sanity (or for "what it does worth") would rather be
Jsonb jsonb = JsonbBuilder.create(
new JsonbConfig()
.withValidationMode( FROM_JSON, TO_JSON ) // map to
serialization "side"?
.withValidator( validator ));
to enable the SE case where CDI is not assumed there no?
>
> Person p = jsonb.fromJson( "...", Person.class );
>
> So it saves a bit. Nothing more and nothing less :)
>
> Maybe others have thoughts on this, too?
>
> Cheers,
>
> --Gunnar
>