| Re: [jsonb-dev] [External] : [jsonp-dev] @JsonbRequired for JSONB and JSON Schema |
|
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 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
@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. -- Jean-Louis Monteiro |