Upgrade Notes for Dropwizard 2.1.x
Hibernate Validator Expression Language overhaul
The Expression Language is now disabled by default for custom violations.
@SelfValidating feature has been a source of various security vulnerabilities in Dropwizard:
This originally lead to the introduction of SelfValidating#escapeExpressions().
Due to some changes regarding the interpolation of messages in custom violations in Hibernate Validator 6.2.0.Final and later, this flag is not required anymore and has been removed in Dropwizard 2.1.0.
While strongly discouraged, you can enable EL interpolation in custom violations with Hibernate Validator, by customizing the
HibernateValidatorConfiguration created by
Validators#newConfiguration() and use the Hibernate Validator instance created from it in your application via
Details about these changes in Hibernate Validator can be found at:
Migrating from dropwizard-health
Migrating from the HealthBundle
dropwizard/dropwizard-health module Starting in Dropwizard 2.1, the functionality from the external dropwizard/dropwizard-health module has been integrated into the main dropwizard/dropwizard project.
Perform the following steps to migrate your application:
Remove the HealthBundle from your Application’s initialize() method.
Remove the reference to HealthConfiguration from your application’s Configuration class.
Migrate YAML configuration previously associated with your HealthConfiguration field to instead be nested under a top-level health field (at the same level as server, logging, and metrics).
Review the new and changed configuration options mentioned below.
Ensure that you don’t already have a custom configuration class member using the health name or rename it to something else or nest it under another field in order not to conflict with the new top-level field.
Remove the dependency on the io.dropwizard.modules:dropwizard-health library from your application’s pom.xml file (or other build dependency definition file).
New Configuration Options
enabledflag added to turn on/off health functionality (defaults to
nameconfiguration added, used in metric naming, thread naming, and log messages.
responderfactory added, to control how health check requests are responded to. For more info, see the config reference.
responseProviderfactory added, to control the body of health check responses, separate from the mechanics of responding. For more info, see the config reference.
Changed Configuration Options
delayedShutdownHandlerEnableddefault value changed to
servletremoved in favor of the new
Changes in versioning
Although Dropwizard tries to postpone big changes to major releases, some breaking changes had to be introduced into Dropwizard 2.1. This change is necessary due to new versioning of Dropwizard releases.
The Dropwizard 2.x releases will stay on a Java 8 baseline and the
Dropwizard 3.x will stay on the
javax namespace too, but will drop support for Java 8 and upgrade to Java 11 instead.
Dropwizard 4.x will eventually mirror the 3.x versions on the
jakarta namespace and maybe introduce some more changes.
Therefore major updates for the Java 8 baseline have to be brought to minor releases on the 2.x branch. The major changes introduced in 2.1 are the following:
0.8.x → 0.9.x
6.1.x → 6.2.x
2.10.x → 2.13.x
2.33 → 2.35
3.10.x → 4.9.x
4.1.x → 4.2.x
Upgrade to Liquibase 4.x
Most of the updates come with low migration cost, but Liquibase gets a major version upgrade and needs some attention.
Liquibase 4.x changes the way it finds files. This means previously recognized migration files could be reported as missing.
Liquibase lets users of the library specify paths, where it should search for files.
Dropwizard therefore adds the file system specific roots to these
root paths, as well as the code location (of the current JAR).
This essentially means migration files now must be specified with absolute paths or be located under
src/main/resources and specified relative to that path.
Upgrade to Jersey 2.35
The upgrade of Jersey from version 2.33 to 2.35 introduces a behavior change in the handling of
If such a parameter is invalid, now a status code
404 is returned instead of the former
400 status code.