[
https://issues.apache.org/jira/browse/WW-5670?focusedWorklogId=1041190&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1041190
]
ASF GitHub Bot logged work on WW-5670:
--------------------------------------
Author: ASF GitHub Bot
Created on: 13/Sep/26 09:29
Start Date: 13/Sep/26 09:29
Worklog Time Spent: 10m
Work Description: 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)
Issue Time Tracking
-------------------
Worklog Id: (was: 1041190)
Remaining Estimate: 0h
Time Spent: 10m
> Dispatcher.getLocale logs "defaulting to request locale" for a locale that
> may not come from the request
> --------------------------------------------------------------------------------------------------------
>
> Key: WW-5670
> URL: https://issues.apache.org/jira/browse/WW-5670
> Project: Struts 2
> Issue Type: Bug
> Components: Core
> Reporter: Lukasz Lenart
> Assignee: Lukasz Lenart
> Priority: Trivial
> Fix For: 7.4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Follow-up to WW-5668.
> {{Dispatcher.getLocale(...)}} handles an unparseable {{struts.locale}} by
> falling back to a locale resolved from the request, and logs a WARN saying it
> is "defaulting to request locale [X]".
> Since WW-5668 that fallback goes through {{resolveRequestLocale(...)}}, which
> -- when {{struts.locale.validateRequestLocale}} is enabled and the
> request-provided locale is not in the JVM's available-locale set -- does not
> return the request locale at all. It returns the configured {{struts.locale}}
> if that parses, and otherwise the JVM default. In the branch that emits this
> WARN, {{struts.locale}} is by definition unparseable, so the value logged is
> the JVM default.
> The logged value itself is correct; the sentence describing where it came
> from is not. An operator diagnosing a locale problem would read {{defaulting
> to request locale [en_US]}} and conclude the client sent {{en_US}}, when in
> fact the client's locale was rejected and this is the runtime default. That
> is the opposite of the conclusion the log should lead to.
> There is a related redundancy on the same path: the WARN branch is only
> reached because {{struts.locale}} failed to parse, yet
> {{resolveRequestLocale(...)}} attempts to parse it a second time before
> giving up.
> h2. Scope / acceptance
> * The message no longer asserts a source it cannot guarantee -- e.g.
> "defaulting to resolved locale [X]" -- and reads correctly whether or not
> {{struts.locale.validateRequestLocale}} is enabled.
> * Optionally, avoid the second parse of a {{struts.locale}} value already
> known to be unparseable on that path.
> * No change to which locale is actually resolved; this is a diagnostics fix
> only.
> Only affects the 7.x line. The 6.x backport carries the same wording but will
> not be changed there.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
