Hi all, On Thu, Nov 20, 2025 at 2:44 PM Coty Sutherland <[email protected]> wrote:
> Mark, > > On Thu, Nov 20, 2025 at 10:24 AM Mark Thomas <[email protected]> wrote: > >> On 19/11/2025 23:28, Christopher Schultz wrote: >> > On 11/19/25 2:18 PM, Coty Sutherland wrote: >> >> <snip/> >> >> >> After writing all of that out, maybe this should be a separate tool >> >> instead >> >> of enhancements to configtest or we should incorporate some of the >> checks >> >> into a pre-startup step in the boot process? Thoughts? >> > >> > A separate tool does make sense to me if you already plan on the large >> > feature set shown above. I can only guess it will continue to >> metastasize. >> >> While the size of the feature set does suggest a separate tool would be >> better, that makes me think of the (very) old admin app where we had a >> real problem keeping it in sync with changes to the components it was >> meant to administer. That makes me think integration into the core >> Tomcat code might be better. >> > > Thanks for the tip. > > >> >> That in turn got me thinking about how strict we want these checks to >> be. We probably want three options: ignore, warn, refuse to start. And >> probably want to set those per category - for some value of category. >> > > Yes, I was thinking exactly that. > > >> >> Implementation-wise, something built on LifecycleListener? >> > > Maybe; I hadn't considered a listener. I was thinking of a custom > validator architecture that uses SPI to register custom validators which > would allow users to put their own validators in jars within lib/...but > that might be overengineering this particular set of features unless it > gets put into a separate tool/library. I don't want to add anything that's > very complicated to maintain, but I think that these changes do have value > for users. > > >> >> Sorry I don't have concrete proposals and I'm unlikely to have much time >> to help but in general I am in favour. >> > > No problem, thanks for the feedback. > OK, I'm back with an update and some thoughts :) The ideas keep coming so I'll try and pull out the most important bits to get feedback on. There are quite a bit of changes queueing up as well, so I'll take a phased approach with PRs for review as well. Phase 1 will implement the core framework logic for adding Validators with a single Validator. I'll add a new class (org.apache.catalina.startup.validator) to house the PortValidator, ValidationResult which will collect findings, and ValidatorRegistry to iterate through the (eventual) list of Validators. The PortValidator will check port conflicts, invalid port numbers, duplicate assignments across connectors, priv ports, AJP connector security, etc. I'll also amend the exit codes returned from the current configtest in the Bootstrap class which calls the new Catalina.configtest() that implements the validation logic and nice output. As it stands it always exits 0 unless the server object is null :) I'm almost ready to fire this PR off. Phase 2 is adding other Validators; depending on how large these get they may be their own PRs to avoid a huge one: * FileResourceValidator to check file existance (like keystores), file permission security checks, invalid keystore passwords, cert expiry warning, etc * JndiResourceValidator to validate JNDI resources, invalid JDBC URLs and missing classes, connection pool conflicts, etc * SecurityValidator for comprehensive security checks, like default credentials in tomcat-users.xml, manager application accessible outside of lo, insecure protocols, and whatever other security best practices make sense Lastly, Phase 3 will add a StartupValidationListener to allow running Validators at startup (which can be configured to abort on error or warnings and not log informational messages from Validators by default) and enable an extensible plugin architecture with the Java Service Provider Interface (introduce new Validator interface, update the registry to be dynamic, etc). Adding the plugin architecture allows for supporting customer Validators from jars placed in lib/ (auto-discovery via META-INF/services), configurable validator ordering, and allows us to skip Validators that are too expensive for startup. We could add other things like allowing overriding default implementations with third party jars, maybe having some environment specific Validators that run, etc. Thoughts?
