[jira] [Updated] (WW-5670) Dispatcher.getLocale logs "defaulting to request locale" for a locale that may not come from the request

["Lukasz Lenart (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WW-5670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukasz Lenart updated WW-5670:
------------------------------
    Component/s: Core

> 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: Major
>             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)