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

Dropwizard automatically registers a Jersey ValidationExceptionMapper that converts JSR-303 bean validation failures into a JSON array of constraint messages. The default response uses generic field placeholders and does not include an explicit property-to-error mapping, which makes it difficult for screen readers to announce the exact field requiring correction.

While the framework allows replacing the mapper with a custom Jersey provider, there is no documented configuration property that enables a verbose, field-aware error format out of the box. The exact serialization behavior may differ between Dropwizard 1.x and 2.x, and any custom provider must be registered correctly to override the default mapper. Additionally, the framework does not expose a built-in constraint for controlling whether detailed validation messages or stack traces appear in production responses, leaving a trade-off between accessibility and information disclosure.

Is there a supported configuration boundary in Dropwizard 2.x to enable field-aware validation error responses without replacing the default mapper? What is the recommended registration pattern for a custom provider that preserves constraint messages while adding explicit property names? Does Dropwizard provide any built-in constraint to limit validation error verbosity in production environments?