PSI Probe: a Tomcat manager and monitor, and the fork that kept it alive

What the tool is, and where it came from

PSI Probe is an advanced manager and monitor for Apache Tomcat, and the repository description says it is forked from Lambda Probe.

That fork is the whole reason the project exists in a usable state. Lambda Probe was the long-standing third-party Tomcat manager, and when its development stalled the ecosystem was left with a tool that did not work on the Jakarta namespace Tomcat, and in general did not work on the versions of Tomcat that people actually run. A fork that keeps the interface and updates the internals is a pragmatic answer to that.

The project is written in Java, is licensed under GPL-2.0 with a `LICENSE` file and a `LICENSE_HEADER`, and the repository is not archived with the last push on 2026-10-12.

The release history is where the fork's structure becomes visible, because there are two release lines being published at the same time. The most recent releases are 5.5.0, titled as the jakarta release for Tomcat 10 and 11, published on 2026-09-20, and 4.7.0, the javax release for Tomcat 9, published on the same day, followed by 4.6.0 from 2026-06-13.

Two lines, released together, is the pattern a project follows when it has to support two incompatible namespace eras of its host platform. The choice of which line to install is therefore the first decision an operator makes.

Two release lines, and how to pick one

The version selection section is short and decisive.

PSI Probe 4.x supports Tomcat 9, in the javax namespace. PSI Probe 5.x supports Tomcat 10.1 and Tomcat 11, in the jakarta namespace. The README says to be sure to select the release series that matches your Tomcat version.

That is the Jakarta migration problem, and the same problem is visible in the repository layout. There are separate modules for `psi-probe-core`, `psi-probe-rest`, `psi-probe-tomcat10`, `psi-probe-tomcat11` and `psi-probe-web`, so the Tomcat-version-specific code is isolated in its own modules and the shared code is not duplicated.

The supported Tomcat list is long and includes the vendor distributions, which is what a support matrix in a production tool looks like. For the Tomcat 9.0 series it lists Tomcat 9.0.72 to 9.0.118, TomEE 8.0.16 which is based on Tomcat 9.0.82, the NonStop(tm) servlet container, and VMware Tanzu tc 4.1.44 and 5.0.23, based on Tomcat 9.0.102 and 9.0.104. For Tomcat 10.1 it lists 10.1.6 to 10.1.55, TomEE 10.0.0 to 10.0.1, NonStop Servlets For JavaServer Pages 10.1, and Tanzu tc 10.1.40.A. For Tomcat 11.0 it lists 11.0.0.M3 to 11.0.22, with TomEE and NonStop explicitly marked as no support yet.

Two caveats are stated for the Tomcat 9 line. Spring is no longer receiving updates, so vulnerabilities in Spring will not be addressed, and if you have a Spring subscription you should manually patch the jars. And the general policy is that support is only against non-CVE Tomcat releases.

The reflection precondition, which is the deployment headache

The Precondition section is the part of the README every operator should read before anything else.

PSI Probe uses deep reflection to access data, and the README says to take care that your Tomcat configuration considers this. The fix is to extend the `JDK_JAVA_OPTIONS` variable:

--add-opens=java.base/java.lang=ALL-UNNAMED \
--add-opens=java.base/java.lang.reflect=ALL-UNNAMED \
--add-opens=java.base/java.io=ALL-UNNAMED \
--add-opens=java.base/java.util=ALL-UNNAMED \
--add-opens=java.base/java.util.concurrent=ALL-UNNAMED \
--add-opens=java.base/sun.util.locale=ALL-UNNAMED \
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED \

The reason this exists is a change in the JDK itself. Since Java 9 the module system encapsulates the internals, and a tool that reaches into `java.lang` and `java.util` to read and manipulate a running server's state has to be told that the encapsulation is allowed. The flag list is a per-package permission grant, and the list is the exact set of packages the tool needs.

This is a genuine operational cost, and it is worth being clear about it. A Tomcat server running with a hardened JVM configuration, in a container image where the flags are set in a locked-down entrypoint, or on a runtime where the module system is enforced differently, will not start the probe without those flags. The tool is asking for broad access to the JDK internals, and a security review will ask why.

The answer is in the same sentence that causes the problem. A manager and monitor for a running servlet container has to reach into the container's own objects to deploy an application, read the request state, and inspect the class loaders, and there is no narrower interface for that.

Installing, and the war you rename

Official PSI Probe release artefacts are published to Maven Central, and the README asks you to download the latest `psi-probe-web.war` from there. GitHub Releases are used for the release notes and the source code history, while the official binary distributions live on Maven Central.

There is a small but useful detail in that arrangement. You can rename `psi-probe-web.war` to the traditional `probe.war` or to any other name you like. That matters because the artefact is deployed into a Tomcat instance, and the name of the war becomes part of the URL of the tool, and many installations and documentation refer to it as `probe`. The rename is what lets an upgrade replace the old artefact without changing the URL your operators have bookmarked.

Building from source is four steps. Clone the repository, which creates a directory called `psi-probe`, and that directory is the base directory the later steps refer to. The minimum JDK version required to build is JDK 21 and the minimum to run is JDK 17. You need Maven 3.9.16 or better. And then, from the base directory:

mvn package

which creates a deployable file at `web/target/probe.war`.

So the source build and the released artefact use the same war name, and the build itself is heavier than the runtime, which is a sensible split. Contributors are told to create their own fork on GitHub first and clone that, rather than cloning the upstream directly, which is a small thing that saves a mess when the work is a pull request.

The badge wall, and what the project measures itself on

The README header is a row of badges, and taken together they describe a project with an unusually mature process for a tool of this kind.

There is a Java CI workflow badge, a Coverity scan badge, a Coveralls coverage badge, and a Snyk badge for known vulnerabilities. There is a Maven Central badge for the `psi-probe-web` artefact, a Renovate badge for automated dependency updates, a GPLv2 licence badge, a project stats badge from OpenHub, and a badge for reproducible builds from the jvm-repo-rebuild project.

Three of those are worth explaining. Coverity and Snyk together are two independent static analysis passes, which is a lot of scrutiny for a web application that reads and manipulates a running server. Renovate means the dependency updates are not a matter of somebody remembering, which matters most in a project that has to support several Tomcat and Java versions. And the reproducible builds badge is the unusual one, because it asserts that the same source produces a bit-identical artefact, which is what lets a downstream user verify that the jar on Maven Central is the one that was built from the source in the repository.

The licence headers are managed too, with a `LICENSE_HEADER` file alongside the licence itself and both an Eclipse and an IntelliJ style configuration, so the format is enforced by the build rather than by review.

The project also has a site at psi-probe.github.io and a SonarCloud project, and a `docs/` directory in the repository.

The community channels and the FAQ

The User Groups section lists three places to talk to other people, and they are of different kinds.

There is a Google group for announcements, which is where release notes and news go. There is a second Google group for discussions. And there is a Slack workspace, with the URL given directly.

The split between announcements and discussions is a small but sensible design for a project that has been around long enough to accumulate a user base, because a question in an announcements list is noise and an announcement in a discussion list is missed.

The FAQ section is short and links to two wiki pages, which tells you the depth is in the wiki rather than the README. One is on adding additional loggers, which is the kind of thing every deployment ends up needing. The other is on forcing the Tomcat version, linked from the troubleshooting page with the anchor for an error on first request.

That second link is a good hint about where the sharp edges are. An error on the first request is exactly what a deep reflection tool produces when the JVM flags are missing, so the wiki page on forcing the Tomcat version is where you would end up if you skipped the Precondition section.

The repository also carries a `CONTRIBUTING.md` that the README points to for information on working on PSI Probe and sending patches, and a `CODE_OF_CONDUCT.md`.

Where PSI Probe is the wrong choice

The first wrong case is a Tomcat version the project does not support. The support list starts at Tomcat 9.0.72, and the Tomcat 11 entries are still milestone builds, 11.0.0.M3 to 11.0.22, with TomEE and NonStop explicitly marked as unsupported on 11. If you are on Tomcat 8, or on an old Tomcat 9 build, there is no release for you.

The second wrong case is a hardened JVM configuration. The tool needs a list of `--add-opens` grants to the JDK internals, and if your deployment has a fixed startup with no room for them, or an image whose entrypoint is managed centrally, the tool will not start. That is a policy decision about the server, not a configuration detail.

The third is a deployment that will not accept a GPL-2.0 licensed web application on the application server. Some organisations have a rule about what runs alongside their own code, and a GPL tool deployed into a Tomcat instance is a question for whoever owns that policy.

The fourth is a container-first environment where the application server is not a long-lived server you control. PSI Probe is a manager for a running Tomcat, with a web interface, and the value is in the deep access to a live server's state. A container that is replaced rather than restarted is a different problem.

The fifth is a team that has already standardised on a different Tomcat administration approach and has the monitoring it needs. The tool is large in scope, the description says advanced manager and monitor, and the cost of running an extra web application on your application server is not zero.

What the project gives you is a maintained tool for a platform that many people still run, with the fork work done and the release discipline to keep it current across both namespace eras of Tomcat.

Editorial conclusion

PSI Probe suits an operations team that runs Tomcat and wants a web interface for deploying, monitoring and inspecting a live server, and who can accept a web application deployed alongside their own. It does not suit a team on Tomcat 8 or earlier, and it does not suit a container image with a locked-down JVM configuration, because the deep reflection the tool relies on requires explicit `--add-opens` flags that a hardened image may not have. Before deploying it, pick the release line that matches your Tomcat major version, since 4.x is the javax line for Tomcat 9 and 5.x is the jakarta line for Tomcat 10.1 and 11, and add the `--add-opens` list to `JDK_JAVA_OPTIONS` before you try the first request.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. psi-probe/psi-probe on GitHub
4. README
5. Releases