@sbonebrake If we just retagged the latest alpha as beta, would that work for you? 😉

In all seriousness: Try upgrading your application to the latest Dropwizard 5.0.x alpha release and let us know how it went and what you would expect in the migration notes.

The more people do this, the quicker we can release Dropwizard 5.0.0.

FWIW I just upgraded our (very mature - in prod for 9 years) codebase to 5.0.0-alpha.5. We have 2,211 tests, the vast majority of which are full stack using the DropwizardAppRule against HSQLDB, and they all pass OK.

In the production code the changes were minimal:

import org.eclipse.jetty.server.session.SessionHandler;
import org.eclipse.jetty.servlets.CrossOriginFilter;

became

import org.eclipse.jetty.ee10.servlet.SessionHandler;
import org.eclipse.jetty.ee10.servlets.CrossOriginFilter;

In build.gradle I had more changes:

dependencies {
    implementation platform("org.eclipse.jetty:jetty-bom:11.0.24")
    implementation "org.eclipse.jetty:jetty-servlet"
    implementation "org.eclipse.jetty:jetty-servlets"
    implementation 'org.eclipse.jetty.toolchain:jetty-jakarta-servlet-api:5.0.2'
}

became

dependencies {
    implementation platform("org.eclipse.jetty:jetty-bom:12.0.16")
    implementation platform("org.eclipse.jetty.ee10:jetty-ee10-bom:12.0.16")
    implementation "org.eclipse.jetty.ee10:jetty-ee10-servlet"
    implementation "org.eclipse.jetty.ee10:jetty-ee10-servlets"
    implementation 'jakarta.servlet:jakarta.servlet-api:6.1.0'
}

I had more issues with my tests, because I was depending on io.dropwizard.modules:dropwizard-testing-junit4 and the DropwizardAppRule. I actually just ended up copying that class into my own codebase, switching to DropwizardAppExtension was going to be too painful.

No decision yet made as to whether we risk it in live.

JS: Try upgrading your application to the latest Dropwizard 5.0.x alpha release and let us know how it went...

We upgraded to 5.0.0-alpha.4 back in November due to an internal company mandate to stop using Jetty 11 given its EOL status. The main issue we encountered was the #9570 issue, which was subsequently resolved in 5.0.0-alpha.5. Here is an example PR of the changes made in case that is helpful: JobService/job-service#458.

We deployed a series of services using 5.0.0-alpha.5 to production in December and there have been no issues to date.

fwiw it looks like jetty somewhat significantly changed their websocket apis enough that the way I was using them is not quite as straightforward to match -- will spend some time on it but at least the non-websocket aspects did port over very easily (just pom/package changes)

ok example of changes needed that seem to be mostly working but still validating here: josephlbarnett/leakycauldron@main...dw5-jetty-12-wip
highlights:

• ws api changes (WebSocketAdapter -> Session.Listener.AutoDemanding, additional callback params/straightforward API changes, weird WS setup to initiate from a jersey resource instead of a top level servlet has changed in every recent major jetty version...)
• testing/mock changes, especially Request/Response variants
• movement from deprecated CrossOriginFilter to CrossOriginHandler and trying to insert that above the DW MutableServletContextHandler via env.applicationContext.insertHandler()