Missing field-to-error mapping configuration in Dropwizard default validation responses

Answer

Dropwizard 2.x does not expose a configuration property that changes the default ValidationExceptionMapper output to include explicit field names. To obtain field-aware error responses you must replace or override the mapper with a custom Jersey ExceptionMapper.

Confirmed facts

• The default mapper in Dropwizard 2.x returns a JSON array of constraint-message strings (e.g., ["must not be null"]) without property paths.
• Dropwizard registers a Jersey provider for javax.validation.ConstraintViolationException (or the broader ValidationException) that produces this format.
• There is no built-in JSR-303 annotation or Dropwizard setting that toggles verbosity or adds stack traces in production; any such control must be implemented manually in the custom mapper.

Recommended registration pattern

1. Implement a custom mapper that extracts the property path and message from each ConstraintViolation and builds a JSON object (or array of objects) that maps field names to error messages.
2. Register the mapper in your Application.run method via the Jersey environment:

@Override
public void run(MyConfiguration config, Environment environment) {
    environment.jersey().register(new FieldAwareValidationExceptionMapper());
}

static class FieldAwareValidationExceptionMapper implements ExceptionMapper<ConstraintViolationException> {
    private final ObjectMapper json = new ObjectMapper();

    @Override
    public Response toResponse(ConstraintViolationException exception) {
        Map<String, List<String>> errors = new HashMap<>();
        for (ConstraintViolation<?> cv : exception.getConstraintViolations()) {
            String field = cv.getPropertyPath().toString();
            errors.computeIfAbsent(field, k -> new ArrayList<>()).add(cv.getMessage());
        }
        try {
            String body = json.writeValueAsString(errors);
            return Response.status(Response.Status.BAD_REQUEST)
                           .type(MediaType.APPLICATION_JSON)
                           .entity(body)
                           .build();
        } catch (JsonProcessingException e) {
            return Response.serverError().build();
        }
    }
}

Verification steps

1. Add a simple resource with a @Valid @NotNull String name parameter.
2. Send a request omitting the parameter (e.g., curl -X POST http://localhost:8080/resource -H "Content-Type: application/json" -d '{}').
3. Confirm the response JSON now contains an object like {"name":["must not be null"]} instead of a flat array.
4. Check startup logs or set a breakpoint in the custom mapper to ensure it is invoked and the default mapper is bypassed.

Missing diagnostic detail

To be certain the custom mapper overrides the default provider, please confirm whether your application throws ConstraintViolationException or the broader ValidationException for bean-validation failures. If the latter is used, map that type instead (or additionally) to guarantee interception.