Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jsonb-dev] [External] : [jsonp-dev] @JsonbRequired for JSONB and JSON Schema
As written on the list I fully agree with JL.

@JsonbRequired is indeed a half baked validation which does not serve much actual purpose in practise since:

1. it does not cover any actual user validation, even the more basic ones (minimum being ranges, shape validation, etc...)
2. On JSON-B side the presence or not of the attribute with null value is likely the same in 99% of the cases (not on JSON-P)
3. For "small" payloads the difference is not that relevant in terms of perf so validation can happen in the creator itself
4. For too big payloads the validation belongs to the parser or reader but not to any other top layer (so nothing in JSON-B would work)

@JsonbRequired can't really be compared with @JsonbNillable because on the serialization side you can't do anything anything whereas, in a creator, you always have a natural callback after the deserialization - or during at JSON-P level - to do it so it is not the same for users.

> Schema support was not goal for the original JSONB specification. We can change mind if there is a strong demand for this functionality, but I don’t see it now.

I read it as "validation is not a goal" so required has no place too since its role is to fail the deserialization so it is literally a validation and does not match the scope you define, no?

What about just dropping this annotation from master and we are done.
Our default was wrong, nobody was able to use it properly so we fixed it, period. It is so true that the PR does not even enable a global toggle for backward compat so I guess removing @JsonbRequired is the best option we have so far to keep providing a high quality API and with added value for end users.
Lastly, technically JSON-B is built on top of JSON-P (thanks JsonbConfig) so validation can be injected in the JsonProvider provided there quite easily for any user willing to validate more than just the functional object after instantiation.

So overall let's keep it user oriented and drop this misleading and wrongly designed @JsonbRequired please.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book


Le mar. 16 nov. 2021 à 12:37, Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> a écrit :

Hi,

 

There is a misunderstanding about the purpose of @JsonbRequired annotation. It’s scope (currently) is limited to @JsonbCreator annotated methods and these methods parameters. JSONB 1.0 specification required presence of @JsonbCreator parameters in deserialized JSON document. Based on users feedback we decided to remove this restriction and not require it. Instead, we introduced a set of default rules in case the parameters are defined using primitive types and @JsonbRequired annotation which can be used to roll back to the JSONB 1.0 behaviour. That’s it for now. There are no plans to introduce more validation. As you said Jakarta Bean Validation can be used for that.

 

I see a way how we can extend @JsonbRequired functionality. It theoretically can replace @JsonbNillable. Currently @JsonbNillable effects only objects serialization. Property annotated with @JsonbNillable(false) is serialized even if its value is null. By default, null properties are NOT serialized. @JsonbRequired may have the same effect as @JsonbNillable on serialization and in addition to it add the same functionality as it has in @JsonbCreator area (require the property value in the deserialized JSON document) on deserialization.

 

Also, we are not planning to introduce any kind of schema support. As far as I know JSON schema RFC still not final. I’m not sure that there is any progress in that area. Schema support was not goal for the original JSONB specification. We can change mind if there is a strong demand for this functionality, but I don’t see it now.

 

Thanks,

Dmitry

 

From: jsonp-dev <jsonp-dev-bounces@xxxxxxxxxxx> On Behalf Of Jean-Louis Monteiro
Sent: 16 November 2021 12:12
To: jsonb-dev@xxxxxxxxxxx; jsonp-dev@xxxxxxxxxxx
Cc: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Subject: [External] : [jsonp-dev] @JsonbRequired for JSONB and JSON Schema

 

Hi all,

 

I’d like to follow up on some discussions around the @JsonbRequired introduced.

 

https://github.com/eclipse-ee4j/jsonb-api/pull/285

 

On the feature itself, I clearly see some benefits to have validation happening before the bean is constructed and fields populated with the JSON payload. Good feature.

 

On the other hand, I don’t think @JsonbRequired is a good way to achieve it.

 

Basically I see 2 options for validation 

  • payload validation 
  • bean validation

 

@JsonbRequired in the bean to do payload validation does not seem accurate to me. It will set us for failure in the future.

 

If we want to address bean validation, we should consider having some integration of Bean Validation using Bean Validation annotations. Of course, this means validation will happen after the bean is constructed, but it also is way richer than “is the field required or not”. Users will be able to reuse constraints and implement business logic validation.

 

I agree that validating the payload before the object gets constructed is very interesting. But then, we should use JSON Schema for it. I am ok to create JSON Schema equivalent annotations, at least for the stable subset and the most interesting rules. From there, we can generate the JSON Schema, and feed the JSON Parser with it so the parser can effectively validate the payload before with a valid JSON Schema (same way an XML parser would get the XSD to validate the payload in JAXB).

 

Having @JsonbRequired seems to be in the middle and a hack for a very simple use case. I would not introduce it now and give us more time to discuss and think about the payload validation a bit more.

 

The hack has been introduced to solve an issue with the design of @JsonbCreator. See https://github.com/eclipse-ee4j/jsonb-api/issues/121

 

Again the design for @JsonbCreator and the need for the feature is awesome for immutable objects. The way to solve it with @JsonbRequired is messy.

 

Moreover, if we look at MicroProfile and OpenAPI, we are also half way because OpenAPI has @Schema, for instance

 

@Schema(type = SchemaType.OBJECT, implementation = InventoryList.class)

or 

@Schema(required = true)

private final String hostname;

 

From there, we generate an openapi document with all constraints (not a JSON Schema but pretty close).

 

Let’s say we need business validation or cross fields validations, we’ll use Bean Validation.

Let’s say we want OpenAPI documentation, we’ll use OpenAPI @Schema

And now let’s say we want JSON Payload validations, we’ll use @JsonbRequired?

 

Can we maybe consider the schema validation as a whole?

We could use the same set of annotations to generate the OpenAPI documentation and to generate the JSON Schema for the JSON Parser.

 

Thoughts?

I am happy to create an issue to revert @JsonbRequired if there is a consensus to wait.

_______________________________________________
jsonb-dev mailing list
jsonb-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jsonb-dev

Back to the top