[
https://issues.apache.org/jira/browse/WW-5670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-5670:
------------------------------
Priority: Trivial (was: Major)
> 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
> Priority: Trivial
> Fix For: 7.4.0
>
>
> 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)
