From: Dmitry Kornilov <dmitry.kornilov_at_oracle.com>
Date: Fri, 10 Mar 2017 14:57:21 +0100

Hi,

Let me put my 2 cents here. I think that BV support makes sense on deserialization. The scope of JSONB 1.0 is already defined. We will come back to this conversation when we will start working on the next version of the spec.

Thanks,
Dmitry

On 09/03/2017, 23:26, "gunnar.morling_at_googlemail.com" <gunnar.morling_at_googlemail.com> wrote:

    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 )
        );
    
        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