Handle json deserialization exception

[maheshrajamani]

Create exception mapper for JsonMappingException

[tatu-at-datastax]

JsonMappingException is a subtype of JsonProcessingException; maybe add mapper of that type to handle all exceptions Jackson throws?

JsonMappingException is used to report data-binding level problems, its sibling type JsonParseException(both subtypes of JsonProcessingException) is used to indicate json-parsing (invalid JSON) problems.

[ivansenic]

Possible duplicate of #87

[ivansenic]

@maheshrajamani Are you sure this is an issue? I have test for this in all resource tests:

/~https://github.com/stargate/jsonapi/blob/a219ea120051e7152cd16453fc85e11fb2e131f0/src/test/java/io/stargate/sgv2/jsonapi/api/v1/CollectionResourceIntegrationTest.java#L73-L87

[maheshrajamani]

I created this issue for 3 issues that was observed.

• If command is not found api throws 404, but if there is serialization error it returns as error messages with 200. We need to fix this to always return 200 with error message.
• Since these are application error message, imo don't need to return "WebApplicationException" in error message as "errors[0].message"

[ivansenic]

I was trying to test some other deserialization errors in order to see if we are covered now. I just hit that this:

      String json =
          """
          {
            "createNamespace": {
              "name": true
            }
          }
          """;

deserializes the name to the String. Was expecting to fail with wrong type or smth like this. @tatu-at-datastax any idea what's going on here?

[tatu-at-datastax]

@ivansenic Jackson is quite permissive when target type is String: this conversion is indeed allowed and automatic by default. Same would be true for numbers.
(original rationale -- this is from Jackson 1.0 or before -- is to try support coercions that are safe -- there are users who really like looseness, and others who dislike it, difficult to find defaults everyone agrees with).

There are ways to configure stricter handling (added in 2.14.x) if we feel this is important to prevent, see:

• Allow disabling Integer to String coercion via CoercionConfig FasterXML/jackson-databind#3013 (for integer->String)
• Implement float and boolean to String coercion config FasterXML/jackson-databind#3613 (for boolean->String)

(default behavior cannot be changed due to backwards-compatibility constraints)

[tatu-at-datastax]

Change to ObjectMapper building would be something like (from PR test above):

   ObjectMapper mapper = JsonMapper.builder()
           // For logical target type of "Textual" (includes String)
            .withCoercionConfig(LogicalType.Textual, cfg ->
                    // fail conversion from source Shape of Boolean
                    cfg.setCoercion(CoercionInputShape.Boolean, CoercionAction.Fail))
            .build();

[ivansenic]

@tatu-at-datastax I merged #119. If you think we need more stricter handling please open a new issue.

[tatu-at-datastax]

@tatu-at-datastax I merged #119. If you think we need more stricter handling please open a new issue.

Thank you! I think we are good now (I don't see an immediate problem); will keep this in mind should there be something to make it an issue.