Closed asaf closed 5 years ago
Thank you for identifying the issue! I've created an internal JIRA issue to track issue and get it fixed and tested. There is no estimated time for resolution as the issue needs to be reviewed and prioritized.
Thanks again for reporting this, @asaf. This was fixed a year ago, but it looks like I forgot to close the issue.
This seems like it's still an issue:
Caused by: javax.ws.rs.ProcessingException: Error reading entity from input stream.
at org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(InboundMessageContext.java:889) ~[jersey-common-2.27.jar:?]
at org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(InboundMessageContext.java:808) ~[jersey-common-2.27.jar:?]
at org.glassfish.jersey.client.ClientResponse.readEntity(ClientResponse.java:321) ~[jersey-client-2.27.jar:?]
at org.glassfish.jersey.client.InboundJaxrsResponse$1.call(InboundJaxrsResponse.java:115) ~[jersey-client-2.27.jar:?]
at org.glassfish.jersey.internal.Errors.process(Errors.java:316) ~[jersey-common-2.27.jar:?]
at org.glassfish.jersey.internal.Errors.process(Errors.java:298) ~[jersey-common-2.27.jar:?]
at org.glassfish.jersey.internal.Errors.process(Errors.java:229) ~[jersey-common-2.27.jar:?]
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:389) ~[jersey-common-2.27.jar:?]
at org.glassfish.jersey.client.InboundJaxrsResponse.runInScopeIfPossible(InboundJaxrsResponse.java:264) ~[jersey-client-2.27.jar:?]
at org.glassfish.jersey.client.InboundJaxrsResponse.readEntity(InboundJaxrsResponse.java:112) ~[jersey-client-2.27.jar:?]
at com.unboundid.scim2.client.requests.RequestBuilder.toScimException(RequestBuilder.java:174) ~[scim2-sdk-client-2.2.1.jar:?]
... 89 more
Caused by: com.fasterxml.jackson.databind.exc.InvalidFormatException: Cannot deserialize value of type `java.lang.Integer` from String "NOT_FOUND": not a valid Integer value
at [Source: (org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream); line: 1, column: 107] (through reference chain: com.unboundid.scim2.common.messages.ErrorResponse["status"])
at com.fasterxml.jackson.databind.exc.InvalidFormatException.from(InvalidFormatException.java:67) ~[jackson-databind-2.9.8.jar:2.9.8]
at com.fasterxml.jackson.databind.DeserializationContext.weirdStringException(DeserializationContext.java:1549) ~[jackson-databind-2.9.8.jar:2.9.8]
at com.fasterxml.jackson.databind.DeserializationContext.handleWeirdStringValue(DeserializationContext.java:911) ~[jackson-databind-2.9.8.jar:2.9.8]
at com.fasterxml.jackson.databind.deser.std.NumberDeserializers$IntegerDeserializer._parseInteger(NumberDeserializers.java:522) ~[jackson-databind-2.9.8.jar:2.9.8]
Where we have:
status The HTTP status code (see Section 6 of [RFC7231]) expressed as a JSON string. REQUIRED.
I have a SCIM server, SCIMple returning NOT_FOUND
for status and the client library here fails to accept that. Using version 2.2.1
of the client library.
The data type of an error response's "status" field is "string", but the value should still be a numeric HTTP status code, such as "400" or "404", not "BAD_REQUEST" or "NOT_FOUND". In case that's unclear, the same section of RFC 7644 that you quoted provides the following examples:
Example of an error in response to a non-existent GET request:
HTTP/1.1 404 Not Found
{ "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], "detail":"Resource 2819c223-7f76-453a-919d-413861904646 not found", "status": "404" }
Example of an error in response to a PUT request:
HTTP/1.1 400 Bad Request
{ "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], "scimType":"mutability" "detail":"Attribute 'id' is readOnly", "status": "400" }
Hey,
According to SCIM v2 spec, the "status" field of an error message should contain the status code represented a string (don't ask me why),
Will you accept a patch that fixes this?
p.s: It makes sense to keep the status code in the
ErrorResponse
class as int but just serialize it back as string viaToStringSerializer
Jackson serializerThanks.