Add opt-in ServerInfo.properties override support - #1059
Open
csutherl wants to merge 1 commit into
Open
Conversation
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
|
I'd be tempted to skip the system property and go with the proposed fix for all current versions. |
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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change fixes what I think is a bug in how we override
ServerInfo.propertiesat runtime. The issue is that when using an overrideServerInfo.propertiesinlib/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 asGlobals.LOAD_SERVER_INFO_OVERRIDE). When set, everyServerInfo.propertieson the class path is merged in reverse order (lib/is loaded first), so the bundledcatalina.jarcopy 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 firstServerInfo.propertiesfound 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.xmlis that users should change the values they want (i.e. the version string) by creatingCATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.properties. In practice the overridden values happen, but the other values in theServerInfo.properitesare 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?