Skip to content

Add opt-in ServerInfo.properties override support - #1059

Open
csutherl wants to merge 1 commit into
apache:mainfrom
csutherl:server-info-override
Open

Add opt-in ServerInfo.properties override support#1059
csutherl wants to merge 1 commit into
apache:mainfrom
csutherl:server-info-override

Conversation

@csutherl

@csutherl csutherl commented Sep 3, 2026

Copy link
Copy Markdown
Member

This change fixes what I think is a bug in how we override ServerInfo.properties at runtime. The issue is that when using an override ServerInfo.properties in lib/ and not setting some values (i.e. server.built), the defaults that are hardcoded in the class are used rather than the bundled values.

The change adds an opt-in system property, org.apache.catalina.util.LOAD_SERVER_INFO_OVERRIDE (exposed as Globals.LOAD_SERVER_INFO_OVERRIDE). When set, every ServerInfo.properties on the class path is merged in reverse order (lib/ is loaded first), so the bundled catalina.jar copy supplies the defaults and an override file (e.g. in $CATALINA_BASE/lib) replaces only the individual properties it sets instead of falling back to the hard coded defaults. When unset (the default), behaviour is unchanged: only the first ServerInfo.properties found is loaded and if you don't provide a value in your override file, the hardcoded value is used.

My reading of the documentation in the security-howto.xml is that users should change the values they want (i.e. the version string) by creating CATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.properties. In practice the overridden values happen, but the other values in the ServerInfo.properites are set to the hardcoded defaults rather than the bundled values, which isn't explicitly stated and unexpected behavior. The addition of this flag makes the documented/expected behaviour actually work, via partial override.

The change is adding an opt-in configuration because merging by default would change class-path loading semantics for every existing deployment which may result in unexpected values at runtime. The flag keeps the default identical and lets operators opt in if desired. I think we should maybe add it and backport it, deprecate it in Tomcat 11, then switch the default and drop the configurable option in Tomcat 12. Thoughts?

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@markt-asf

Copy link
Copy Markdown
Contributor

I'd be tempted to skip the system property and go with the proposed fix for all current versions.

@csutherl

csutherl commented Sep 3, 2026

Copy link
Copy Markdown
Member Author

I'd be fine with that. I didn't want to push a fix that changes some behavior that could potentially result in different server info being available. If there's no objections, I'm happy to drop the config option and change the default behavior to match what I'd expect from reading the doc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants