Dropwizard resources support some great declarative validation with the @Valid annotation.

However, Dropwizard does marshall the errors out to a response object for you and hides some of the underlying details whilst also string formatting a little. See ConstraintViolationExceptionMapper and ConstraintViolations format method.

If the default Dropwizard behaviour meets your needs (often the case) you can stop reading now!

For my scenario, I wanted to keep the nice declaritive validation, but get a bit more insight into the error and also control of the response.

A sample of triggering validation manually is below … (you should probably inject the ValidatorFactory etc into where you need it).

Jump into your debugger and inspect the violations objects returned … of interest is usually the properties that violated, and their associated messages.

		ValidatorFactory factory = Validation.buildDefaultValidatorFactory();	
        Validator validator = factory.getValidator();
        Set<ConstraintViolation<SomeObjectToValidateType>> violations = validator.validate(someInstanceToValidate);
        assert(violations.size() > 1);

You can usually build on that to create a custom response as you need, either manually rolling a Response object or by creating exceptions and plumbing that into the response pipeline with some error handling

Like with anything, if you decide to go it alone, instead of using the standard built in Dropwizard functionality, make sure you have a good reason!