[TCK] REST and JSONB/JSONP

[hantsy]

When I prepared my example project: https://github.com/hantsy/jakartaee11-starter-boilerplate

I encountered an issue with the latest Payara community version: it cannot serialize/deserialize DateTime Instant as expected because it uses Jackson 2 by default in REST and refuses to include the Jackson JSR310 module. https://github.com/hantsy/jakartaee11-starter-boilerplate/actions/runs/23273748402/job/67672079972?pr=125#step:4:22128

Caused by: com.fasterxml.jackson.databind.exc.InvalidDefinitionException: 
Java 8 date/time type `java.time.Instant` not supported by default: 
add Module "com.fasterxml.jackson.datatype:jackson-datatype-jsr310" 
to enable handling (or disable `MapperFeature.REQUIRE_HANDLERS_FOR_JAVA8_TIMES`)
at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); 
line: 1, column: 15] (through reference chain: java.util.ArrayList[0]->com.example.domain.Todo["createdAt"])

(I have reported this to Payara, but got the answer I have to add Jackson jsr310 myself, but Java 8 DateTime is a support feature in Jakarta EE for a long time, it should cover all specs.)

On Glassfish v8, it could use JSONB to do this(there is no such an problem).

I want to ask:

1. Does the REST spec require JSONB/JSONP to serialize/deserialize JSON data?
2. If not, is there a list of the supported types (aka the Instant here) in the spec/TCK to ensure alignment with JSONB and other specs to smooth the developer's experience?

[jamezp]

It's loosely worded, but typically yes implementations should prefer Jakarta JSON Processing and Jakarta JSON Binding.

https://jakarta.ee/specifications/restful-ws/4.0/jakarta-restful-ws-spec-4.0#jsonp

11.2.5. Java API for JSON Processing

In a product that supports the Java API for JSON Processing (JSON-P) [18], implementations MUST support entity providers for JsonValue and all of its sub-types: JsonStructure, JsonObject, JsonArray, JsonString and JsonNumber.

Note that other types from the JSON-P API such as JsonParser, JsonGenerator, JsonReader and JsonWriter can also be integrated into JAX-RS applications using the entity providers for InputStream and StreamingOutput.

11.2.6. Java API for JSON Binding

In a product that supports the Java API for JSON Binding (JSON-B) [19], implementations MUST support entity providers for all Java types supported by JSON-B in combination with the following media types: application/json, text/json as well as any other media types matching /json or /*+json.

Note that if JSON-B and JSON-P are both supported in the same environment, entity providers for JSON-B take precedence over those for JSON-P for all types except JsonValue and its sub-types.

[hantsy]

To provide a consistent experience for REST, JSONB and Faces/Persistence, I think the Jakarta REST TCK should add ser/deser for JSR 310 data types.

Payara declared that it had passed the TCK, but Jakarta REST in Payara did not support JSR-310.

[jamezp]

Well, that's more of an issue with the JSON provider than REST. While it might be reasonable to have a test which uses dates, there's a fine line between testing the Jakarta REST API and another API or implementation. In other words, we don't want to have to test that which ever JSON Binding provider used for all cases that are expected to be serialized/deserialized.

[hantsy]

Sadly know this inconsistency is allowed

[hantsy]

@jamezp Although REST is not dependent on JSONP/JSONB, I think in the Jakarta REST TCK, it should cover all Java 8 DateTime data types to make sure they are supported in the HTTP messages serialization/deserialization in both JSON/XML format.

[mkarg]

@jamezp Although REST is not dependent on JSONP/JSONB, I think in the Jakarta REST TCK, it should cover all Java 8 DateTime data types to make sure they are supported in the HTTP messages serialization/deserialization in both JSON/XML format.

As the Jakarta REST Spec does not mention that these classes MUST get supported, and as the Jakarta REST TCK's sole purpose is to confirm compliance of an implementation with the spec but nothing else, I need to reject this idea. But I think it would be worth to discuss active adoption of that classes the the spec. Once we have a majority for that, it makes sense to add these tests.