Does Dropwizard 3.x Plan to Expose Virtual Thread Configuration for Jersey Resources on Jetty 11?

Context

Dropwizard 3.x migrated to Jakarta EE namespaces while retaining Jetty 11 as the default embedded server. Jetty 11 now includes experimental support for virtual threads (Project Loom), which can improve throughput for I/O-bound workloads by decoupling request handling from platform threads.

Unresolved Decision

The framework has not yet formalized a configuration option to enable virtual threads for Jersey resource methods. This leaves application developers uncertain whether to adopt virtual threads by default, require explicit opt-in per resource, or wait for a stable integration that accounts for thread-local dependent libraries such as Hibernate session management.

Goal

Clarify the project's direction on virtual thread adoption so that teams planning upgrades from Dropwizard 2.x can make informed architectural decisions about concurrency models and thread-local usage.

What is the current roadmap for exposing virtual thread execution in Dropwizard's Jersey integration? Will configuration be server-wide, per-resource, or left to manual executor customization? Are there known compatibility constraints with existing Dropwizard-managed components (e.g., Hibernate bundles, health checks) that would influence the default behavior?