On Wed, Feb 4, 2026 at 7:34 PM Christopher Schultz <[email protected]> wrote: > > Dimitris, > > On 2/4/26 6:36 AM, Dimitris Soumis wrote: > > All, > > > > I’d like to propose adding an integration test layer to the Tomcat source > > tree that validates Tomcat behavior when deployed behind httpd as a reverse > > proxy. > > > > Tomcat’s documentation treats reverse proxy operation as a distinct > > configuration surface (e.g. utilizing RemoteIpValve and SSLValve). These > > are paths for which having automated regression coverage would reduce risk > > in future changes and test that everything's working as expected flawlessly. > > > > I’m proposing a new directory in the Tomcat repo (e.g. integration/ ) that > > contains the entire implementation: > > > > 1. A Java-based harness to provision a test environment. > > - Creates an isolated CATALINA_BASE under output/ > > - Writes templated Tomcat and httpd configs for each scenario per > > proxy mode > > - Starts/stops Tomcat and httpd as external processes > > - Waits for readiness and captures logs into a dedicated output > > direcotry > > 2. A minimal test web application used as a stable assertion target > > 3. A set of JUnit integration tests that send requests to httpd and > > validate the results as seen by Tomcat testing the documented proxy > > configuration behaviors. > > > > This would be added as Ant target(s), separate from the default 'ant test' > > workflow, e.g. 'ant integration-httpd'. > > > > I would appreciate your feedback on this. > > +1 for all of that, particularly as long as it: > > 1. Is completely optional > 2. Doesn't break anything already working > > You said you would do this as completely new ant targets, so I say "go > for it". > > We'll all want to know how to use it for release testing, of course, but > you can tell us when it's ready. Remember that we are all on different > environments: I'm primarily on Mac, Mark straddles the fence of > Windows/Mac, Konstantin is primarily Windows, Rémy is Linux (and I > assume you as a Red Hatter are also on Linux), and Rainer has a zoo of > *NIX environments on which to test. > > If you want to go environment-by-environment, make sure to use the ant > support for doing things differently on each OS. For Mac, you can just > "fail with error message saying Mac isn't supported" for example, and > then we can add support later.
I would be using a folder name starting with "test" for this, so that it is explicit this is for testing. Then I don't know what infrastructure to use. Straight hardcoded control of other processes (like OCSP is doing with OpenSSL now, for example), or do we consider libraries ? Rémy > -chris > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
