You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Alexander Klimetschek (JIRA)" <ji...@apache.org> on 2010/12/29 20:55:45 UTC
[jira] Created: (SLING-1905) Custom LocaleResolver cannot fall back
to using the locale from the request's Accept-Language header
Custom LocaleResolver cannot fall back to using the locale from the request's Accept-Language header
----------------------------------------------------------------------------------------------------
Key: SLING-1905
URL: https://issues.apache.org/jira/browse/SLING-1905
Project: Sling
Issue Type: Improvement
Components: Extensions
Affects Versions: I18n 2.0.4
Reporter: Alexander Klimetschek
It is difficult for a custom LocaleResolver to use the default request locale (based on the HTTP Accept-Language header), because:
1) the I18NFilter passes its own wrapped request object to the LocaleResolver (instead of the original one), resulting in an endless loop if request.getLocales() is used inside the LocaleResolver
2) LocaleResolver.resolveLocale() returns a List<Locale> whereas request.getLocales() returns Enumeration<Locale>, making conversion unnecessarily difficult
3) the default LocaleResolver which uses the original request's getLocale() is not available as a fallback, it is solely used if no custom LocaleResolver is used at all
Ideas:
1) could easily be solved by passing this.getSlingRequest()
2) + 3) a public DefaultLocaleResolver class (as base for custom ones) could provide this fallback in its resolveLocale() implementation
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] [Commented] (SLING-1905) Custom LocaleResolver cannot fall
back to using the locale from the request's Accept-Language header
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051986#comment-13051986 ]
Felix Meschberger commented on SLING-1905:
------------------------------------------
Maybe calling the LocalResolver with the request wrapped by the I18N Filter is probably wrong. The request used to call the LocaleResolver should be the wrapped request.
Hence I suggest:
* Call the LocaleResolver with the request provided to the I18NFilter
* Move the existing DefaultLocaleResolver to the exported package (removing the unneeded unwrapping)
> Custom LocaleResolver cannot fall back to using the locale from the request's Accept-Language header
> ----------------------------------------------------------------------------------------------------
>
> Key: SLING-1905
> URL: https://issues.apache.org/jira/browse/SLING-1905
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: I18n 2.0.4
> Reporter: Alexander Klimetschek
>
> It is difficult for a custom LocaleResolver to use the default request locale (based on the HTTP Accept-Language header), because:
> 1) the I18NFilter passes its own wrapped request object to the LocaleResolver (instead of the original one), resulting in an endless loop if request.getLocales() is used inside the LocaleResolver
> 2) LocaleResolver.resolveLocale() returns a List<Locale> whereas request.getLocales() returns Enumeration<Locale>, making conversion unnecessarily difficult
> 3) the default LocaleResolver which uses the original request's getLocale() is not available as a fallback, it is solely used if no custom LocaleResolver is used at all
> Ideas:
> 1) could easily be solved by passing this.getSlingRequest()
> 2) + 3) a public DefaultLocaleResolver class (as base for custom ones) could provide this fallback in its resolveLocale() implementation
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1905) Custom LocaleResolver cannot fall
back to using the locale from the request's Accept-Language header
Posted by "Alexander Klimetschek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052080#comment-13052080 ]
Alexander Klimetschek commented on SLING-1905:
----------------------------------------------
Thanks!
> Custom LocaleResolver cannot fall back to using the locale from the request's Accept-Language header
> ----------------------------------------------------------------------------------------------------
>
> Key: SLING-1905
> URL: https://issues.apache.org/jira/browse/SLING-1905
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: I18n 2.0.4
> Reporter: Alexander Klimetschek
> Assignee: Felix Meschberger
> Fix For: I18n 2.1.0
>
>
> It is difficult for a custom LocaleResolver to use the default request locale (based on the HTTP Accept-Language header), because:
> 1) the I18NFilter passes its own wrapped request object to the LocaleResolver (instead of the original one), resulting in an endless loop if request.getLocales() is used inside the LocaleResolver
> 2) LocaleResolver.resolveLocale() returns a List<Locale> whereas request.getLocales() returns Enumeration<Locale>, making conversion unnecessarily difficult
> 3) the default LocaleResolver which uses the original request's getLocale() is not available as a fallback, it is solely used if no custom LocaleResolver is used at all
> Ideas:
> 1) could easily be solved by passing this.getSlingRequest()
> 2) + 3) a public DefaultLocaleResolver class (as base for custom ones) could provide this fallback in its resolveLocale() implementation
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (SLING-1905) Custom LocaleResolver
cannot fall back to using the locale from the request's Accept-Language
header
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053068#comment-13053068 ]
Felix Meschberger edited comment on SLING-1905 at 6/22/11 6:37 AM:
-------------------------------------------------------------------
So you say we basically have a few issues:
(1) We don't specify whether LocaleResolver.resolveLocale may return null or an empty list.
==> we should specifiy this; IMHO allow null or empty list but defining what the consequence would be
(2) I18NSlingHttpServletRequest.getLocaleList() does not check the result of resolveLocale (which may be empty or null)
==> check the result of resolveLocale. If empty or null use singleton list with the ResourceBundleProvider.getDefaultLocale()
(3) I18NSlingHttpServletRequest.getLocale() only checks for the empty list but may throw NPE if the list is null
==> No need for check since getLocaleList() always returns non-empty list
(4) I18NSlingHttpServletRequest.getLocales() may in fact return an empty list or even throw NPE if the list is null
==> No need for check since getLocaleList() always returns non-empty list
I create a new issue for that (SLING-2107).
was (Author: fmeschbe):
So you say we basically have a few issues:
(1) We don't specify whether LocaleResolver.resolveLocale may return null or an empty list.
==> we should specifiy this; IMHO allow null or empty list but defining what the consequence would be
(2) I18NSlingHttpServletRequest.getLocaleList() does not check the result of resolveLocale (which may be empty or null)
==> check the result of resolveLocale. If empty or null use singleton list with the ResourceBundleProvider.getDefaultLocale()
(3) I18NSlingHttpServletRequest.getLocale() only checks for the empty list but may throw NPE if the list is null
==> No need for check since getLocaleList() always returns non-empty list
(4) I18NSlingHttpServletRequest.getLocales() may in fact return an empty list or even throw NPE if the list is null
==> No need for check since getLocaleList() always returns non-empty list
I create a new issue for that.
> Custom LocaleResolver cannot fall back to using the locale from the request's Accept-Language header
> ----------------------------------------------------------------------------------------------------
>
> Key: SLING-1905
> URL: https://issues.apache.org/jira/browse/SLING-1905
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: I18n 2.0.4
> Reporter: Alexander Klimetschek
> Assignee: Felix Meschberger
> Fix For: I18n 2.1.0
>
>
> It is difficult for a custom LocaleResolver to use the default request locale (based on the HTTP Accept-Language header), because:
> 1) the I18NFilter passes its own wrapped request object to the LocaleResolver (instead of the original one), resulting in an endless loop if request.getLocales() is used inside the LocaleResolver
> 2) LocaleResolver.resolveLocale() returns a List<Locale> whereas request.getLocales() returns Enumeration<Locale>, making conversion unnecessarily difficult
> 3) the default LocaleResolver which uses the original request's getLocale() is not available as a fallback, it is solely used if no custom LocaleResolver is used at all
> Ideas:
> 1) could easily be solved by passing this.getSlingRequest()
> 2) + 3) a public DefaultLocaleResolver class (as base for custom ones) could provide this fallback in its resolveLocale() implementation
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1905) Custom LocaleResolver cannot fall
back to using the locale from the request's Accept-Language header
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053068#comment-13053068 ]
Felix Meschberger commented on SLING-1905:
------------------------------------------
So you say we basically have a few issues:
(1) We don't specify whether LocaleResolver.resolveLocale may return null or an empty list.
==> we should specifiy this; IMHO allow null or empty list but defining what the consequence would be
(2) I18NSlingHttpServletRequest.getLocaleList() does not check the result of resolveLocale (which may be empty or null)
==> check the result of resolveLocale. If empty or null use singleton list with the ResourceBundleProvider.getDefaultLocale()
(3) I18NSlingHttpServletRequest.getLocale() only checks for the empty list but may throw NPE if the list is null
==> No need for check since getLocaleList() always returns non-empty list
(4) I18NSlingHttpServletRequest.getLocales() may in fact return an empty list or even throw NPE if the list is null
==> No need for check since getLocaleList() always returns non-empty list
I create a new issue for that.
> Custom LocaleResolver cannot fall back to using the locale from the request's Accept-Language header
> ----------------------------------------------------------------------------------------------------
>
> Key: SLING-1905
> URL: https://issues.apache.org/jira/browse/SLING-1905
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: I18n 2.0.4
> Reporter: Alexander Klimetschek
> Assignee: Felix Meschberger
> Fix For: I18n 2.1.0
>
>
> It is difficult for a custom LocaleResolver to use the default request locale (based on the HTTP Accept-Language header), because:
> 1) the I18NFilter passes its own wrapped request object to the LocaleResolver (instead of the original one), resulting in an endless loop if request.getLocales() is used inside the LocaleResolver
> 2) LocaleResolver.resolveLocale() returns a List<Locale> whereas request.getLocales() returns Enumeration<Locale>, making conversion unnecessarily difficult
> 3) the default LocaleResolver which uses the original request's getLocale() is not available as a fallback, it is solely used if no custom LocaleResolver is used at all
> Ideas:
> 1) could easily be solved by passing this.getSlingRequest()
> 2) + 3) a public DefaultLocaleResolver class (as base for custom ones) could provide this fallback in its resolveLocale() implementation
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1905) Custom LocaleResolver cannot fall
back to using the locale from the request's Accept-Language header
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052839#comment-13052839 ]
Tobias Bocanegra commented on SLING-1905:
-----------------------------------------
i don' think that the behavior of request.getLocales() is correct. according to the servlet spec:
"Returns an Enumeration of Locale objects indicating, in decreasing order starting with the preferred locale, the locales that are acceptable to the client based on the Accept-Language header. If the client request doesn't provide an Accept-Language header, this method returns an Enumeration containing one Locale, the default locale for the server."
so the condition that request.getLocale() returns the default one, but request.getLocales() is empty, is invalid.
Further the case where a configured localeResolver returns an empty list should be delegated back to the original servlet request - or this behavior should at least be configurable.
(can you please clarify or re-open the bug)
> Custom LocaleResolver cannot fall back to using the locale from the request's Accept-Language header
> ----------------------------------------------------------------------------------------------------
>
> Key: SLING-1905
> URL: https://issues.apache.org/jira/browse/SLING-1905
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: I18n 2.0.4
> Reporter: Alexander Klimetschek
> Assignee: Felix Meschberger
> Fix For: I18n 2.1.0
>
>
> It is difficult for a custom LocaleResolver to use the default request locale (based on the HTTP Accept-Language header), because:
> 1) the I18NFilter passes its own wrapped request object to the LocaleResolver (instead of the original one), resulting in an endless loop if request.getLocales() is used inside the LocaleResolver
> 2) LocaleResolver.resolveLocale() returns a List<Locale> whereas request.getLocales() returns Enumeration<Locale>, making conversion unnecessarily difficult
> 3) the default LocaleResolver which uses the original request's getLocale() is not available as a fallback, it is solely used if no custom LocaleResolver is used at all
> Ideas:
> 1) could easily be solved by passing this.getSlingRequest()
> 2) + 3) a public DefaultLocaleResolver class (as base for custom ones) could provide this fallback in its resolveLocale() implementation
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1905) Custom LocaleResolver cannot fall
back to using the locale from the request's Accept-Language header
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051991#comment-13051991 ]
Felix Meschberger commented on SLING-1905:
------------------------------------------
Also updated the version number of the export to 2.0.4 (was 2.0.2). This allows users of the DefaultLocaleResolver to specify a sensitive minimum required version while implementors of the interfaces specifying an upper version range bound of <2.1.0 still work.
Done in Rev. 1137641
> Custom LocaleResolver cannot fall back to using the locale from the request's Accept-Language header
> ----------------------------------------------------------------------------------------------------
>
> Key: SLING-1905
> URL: https://issues.apache.org/jira/browse/SLING-1905
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: I18n 2.0.4
> Reporter: Alexander Klimetschek
> Assignee: Felix Meschberger
> Fix For: I18n 2.1.0
>
>
> It is difficult for a custom LocaleResolver to use the default request locale (based on the HTTP Accept-Language header), because:
> 1) the I18NFilter passes its own wrapped request object to the LocaleResolver (instead of the original one), resulting in an endless loop if request.getLocales() is used inside the LocaleResolver
> 2) LocaleResolver.resolveLocale() returns a List<Locale> whereas request.getLocales() returns Enumeration<Locale>, making conversion unnecessarily difficult
> 3) the default LocaleResolver which uses the original request's getLocale() is not available as a fallback, it is solely used if no custom LocaleResolver is used at all
> Ideas:
> 1) could easily be solved by passing this.getSlingRequest()
> 2) + 3) a public DefaultLocaleResolver class (as base for custom ones) could provide this fallback in its resolveLocale() implementation
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-1905) Custom LocaleResolver cannot fall
back to using the locale from the request's Accept-Language header
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger resolved SLING-1905.
--------------------------------------
Resolution: Fixed
Fix Version/s: I18n 2.1.0
Assignee: Felix Meschberger
Implemented the changes in Rev. 1137640.
The DefaultLocaleResolver is now exported and the unwrapped request is used to call the LocaleResolver.
> Custom LocaleResolver cannot fall back to using the locale from the request's Accept-Language header
> ----------------------------------------------------------------------------------------------------
>
> Key: SLING-1905
> URL: https://issues.apache.org/jira/browse/SLING-1905
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: I18n 2.0.4
> Reporter: Alexander Klimetschek
> Assignee: Felix Meschberger
> Fix For: I18n 2.1.0
>
>
> It is difficult for a custom LocaleResolver to use the default request locale (based on the HTTP Accept-Language header), because:
> 1) the I18NFilter passes its own wrapped request object to the LocaleResolver (instead of the original one), resulting in an endless loop if request.getLocales() is used inside the LocaleResolver
> 2) LocaleResolver.resolveLocale() returns a List<Locale> whereas request.getLocales() returns Enumeration<Locale>, making conversion unnecessarily difficult
> 3) the default LocaleResolver which uses the original request's getLocale() is not available as a fallback, it is solely used if no custom LocaleResolver is used at all
> Ideas:
> 1) could easily be solved by passing this.getSlingRequest()
> 2) + 3) a public DefaultLocaleResolver class (as base for custom ones) could provide this fallback in its resolveLocale() implementation
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira