lukaszlenart opened a new pull request, #1928: URL: https://github.com/apache/struts/pull/1928
Fixes [WW-5670](https://issues.apache.org/jira/browse/WW-5670) ## Problem When `struts.locale` is unparseable, `Dispatcher.getLocale` logged `defaulting to request locale [X]`. Since WW-5668, `resolveRequestLocale` may reject the request locale (`struts.locale.validateRequestLocale=true` + a locale not in the JVM's available set) and return the JVM default instead, so the message attributed a runtime default to the client — the opposite of what an operator should conclude. The same path also re-parsed the already-known-unparseable value on every request. ## Change - `setDefaultLocale` parses `struts.locale` once into `parsedDefaultLocale` and warns once (with the parse exception) when it cannot. Reload/re-injection re-runs the setter, so `dispatcherReinjectedAfterReload` still covers the swap. - `getLocale` and `resolveRequestLocale` read the parsed value; no `LocaleUtils.toLocale` call remains on the request path. The protected `resolveRequestLocale(HttpServletRequest)` keeps its 7.3.0 signature and semantics, and the bad-`struts.locale` path still goes through it, so subclass overrides are honoured. - The per-request WARN now reads `defaulting to resolved locale [X]`, which is correct whether or not `validateRequestLocale` is enabled. No change to which locale is resolved in any combination of unset/parseable/unparseable `struts.locale`, validation on/off, or a throwing `request.getLocale()`. ## Tests - `testGetLocale_With_BadDefaultLocale_WarnsWithResolvedLocaleNotRequestLocale` — captures the `Dispatcher` WARN through an inline log4j2 appender and asserts the new wording; it reproduced the old misleading message before the fix. - `testGetLocale_With_BadDefaultLocale_ValidateOn_UnavailableRequestLocale` — pins the previously uncovered resolution path (JVM default) to guard the "diagnostics only" acceptance criterion. 7.x only, per the ticket. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
