Does @Valid not produce a meaningful message for basic conversion issues?

[mberdev]

Look at this scenario :

@POST
@Path("my-endpoint")
@Produces(MediaType.APPLICATION_JSON)
public Response myEndpoint(
    final @Valid @NotNull Payload payload
) {
    return ok(); // pseudo-code
}

...

@Value
public class Payload {
    @Valid @NotNull Long mSomeLong;
}

• If I call the endpoind with this value for a body : { } then I get a meaningful error message in HTTP 400 : "someLong cannot be null"
• If I call with { someLong: null } then same thing. I get a meaningful message
• If I call with { someLong: "not a long" } then I only get HTTP 400 but no meaningful message. I would expect something along the lines of "could not parse someLong".

Is there a built-in mechanism of RestEasy that I'm missing?

[jamezp]

This is done for security reasons. If you report the type like that, then an attacker would know they need to pass a long next time.

[mberdev]

That is a strange strategy!
When it comes to security, there are only two paths :

• First make sure the user is authenticated, then say what the validation problem is, every time
• If the user is not authenticated, then do not reach validation at all and don't ever return a meaningful message

In this case RestEasy is suffering form double personality disorder :

• It already returns a meaningful message 90% of the time (when a sub-sub-sub-field is null but shouldn't, RestEasy returns a detailed message with the entire path to the field, and says that it shouldn't be null).
• But then RestEasy decides to "obfuscate" the validation of the remaining 10% for no reason? (saying that the field should be a long is no more a security leak than saying the name of the missing field and giving its expected path in the json)