JMX notification listeners fail after Tomcat 10.1's jakarta.management migration

JMX notification listeners fail after Tomcat 10.1's jakarta.management migration

Upgrading to Tomcat 10.1 changes the JMX API from javax.management to jakarta.management. Existing notification listeners that still import the old package are silently dropped during registration, so alerts for thread‑pool saturation, request latency spikes, and lifecycle events are lost without any server‑side error.

The migration guide does not state whether notification payloads, attribute names, or emission timing have changed alongside the package rename, and there is no built‑in way to confirm that listeners are active after deployment short of generating synthetic load.

What is the recommended migration path for JMX notification listeners to avoid silent registration failures? Are there any changes in notification types or attributes emitted by ThreadPool and GlobalRequestProcessor MBeans in Tomcat 10.1+ that require listener updates? How can operators verify that notification listeners are correctly registered and receiving events after the upgrade without generating test load?