struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Chaplin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (WW-4734) I18Interceptor ignores session or cookie Locale after first lookup failure
Date Fri, 13 Jan 2017 23:34:26 GMT

    [ https://issues.apache.org/jira/browse/WW-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822520#comment-15822520
] 

James Chaplin commented on WW-4734:
-----------------------------------

(Apologies - I'm not used to the text formatting options yet so I'm sticking to plain text).

Hello Lukasz.

The change for WW-4722 you mention in the comment above is related, but only part of the issue
noted here (it corresponds to element 2 of the bug described above).  Even with that latest
change the I18nInterceptor behaviour will still be different compared to 2.5.5 and before.

For example during an initial login (with no previous session or cookie present) the  I18nInterceptor
will not find a Locale at the session scope and has its storage type set to Storage.NONE.
 After that even if a Locale is added to that session (I18nInterceptor.DEFAULT_SESSION_ATTRIBUTE)
the i18n interceptor will never find it.  That appears to hold true forever afterwards (the
interceptor's storage type becomes "stuck" at none).

In 2.5.5 and prior one could set the Locale programmatically (e.g. during or after a login)
and the i18n interceptor would find/honour the value.  With 2.5.8 it appears broken.

Even looking at the 2.5.5 and earlier code it isn't clear to me clear why the I18nInterceptor's
storage value was dynamically changing anyway.  It seems that to work consistently it would
always need to search session/cookie in the event there wasn't a specific Locale request parameter
(unless I'm missing something ?).

> I18Interceptor ignores session or cookie Locale after first lookup failure
> --------------------------------------------------------------------------
>
>                 Key: WW-4734
>                 URL: https://issues.apache.org/jira/browse/WW-4734
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Core Interceptors
>    Affects Versions: 2.5.8
>            Reporter: James Chaplin
>            Assignee: Lukasz Lenart
>              Labels: interceptors
>             Fix For: 2.5.next
>
>
> In Struts 2.5.5 and prior 2.5.x/2.3.x, the I18nInterceptor honoured the locale state
set programmatically via session (e.g. session.put(I18nInterceptor.DEFAULT_SESSION_ATTRIBUTE,
localeForUser); ).
> Struts 2.5.8 ignores a locale state set programmatically via session (or at least it
does so after the 1st failed lookup).
> *Issue cause: Changes in 2.5.8 storeLocale()/readStoredLocale() behaviour causes "storage
== Storage.NONE" after 1st lookup failure, and i18nInterceptor will never again check session/cookie
scopes for a locale.  Appears to have been introduced with changes for WW-4722.
> *Bug elements:
>   1) readStoredLocale() - Never checks session/cookie level for a saved locale (after
first lookup failure sets "storage = Storage.NONE").
>   2) readStoredLocale() - The "if block" checks are inverted.  When "storage == Storage.COOKIE"
it checks session, when "storage == Storage.SESSION" it checks cookie (appears this was addressed
in update to WW-4722 on 2017/01/11).
>   3) LocaleFinder/saveLocale() - No longer provides default lookup at session level,
no longer preserves the storage level where the lookup succeded.
> *Suggested remedy:
>   1) Restore logic equivalent to 2.5.5 and earlier that will always check session and
cookie scopes for Locale, irrespective of what the current i18n interceptor instance's storage
value is set to.
>      Change readStoredLocale() to check all scopes, restore storage scope state to LocaleFinder
and calls to saveLocale().  Use LocaleFilender's scope state (tracking immediate request's
locale storage level) during request processing (and if possible, leave i18n interceptor's
scope fixed/unchanged).
>   2) Add logic to I18nInterceptor that preserves the initially configured storage type/scope
for the lifetime of the i18n interceptor.  This could be done by adding a new protected member
to I18nInterceptor (e.g. protected configuredStorage), which gets initialized similarly to
"storage" but only modified in the initial setLocaleStorage() call (so its value stays intact
until explicitly changed by configuration).
> Either way it appears the I18nInterceptor needs a mechanism to ensure that it will always
look for Locale at the session/cookie level (or at the very least the level that was initially
configured for the interceptor), irrespective of what the current storage value is set to.
 Without such logic the i18n interceptor stops looking for anything other than the request/invocation
context level (after the first lookup failure, irrespective of original storage setting).
 Tracking the configured storage scope (global) and the immediate request's scope (local)
separately might be appropriate.
> *Note: API documentation for I18nInterceptor "storage" parameter appears incorrect as
well.  The new configuration parameter in 2.5.8 should indicate "localeStorage" for configuring
the locale storage parameter (it indicates "storage" currently, but that fails as it doesn't
match the setter's name).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message