[
https://issues.apache.org/jira/browse/TRINIDAD-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688633#action_12688633
]
Matthias Weßendorf commented on TRINIDAD-1434:
----------------------------------------------
we already do nothing, when the provided encoding is equal to the already
underlying one...
Index: UploadRequestWrapper.java
===================================================================
--- UploadRequestWrapper.java (revision 757695)
+++ UploadRequestWrapper.java (working copy)
@@ -78,6 +78,11 @@
public void setCharacterEncoding(String encoding)
throws UnsupportedEncodingException
{
+
+ // If the encoding is already right, we can bail
+ if (encoding.equals(_encoding))
+ return;
+
// It is illegal to set the character encoding after parameters
// have been retrieved. This is an annoying restriction,
// but we shouldn't break it
@@ -87,10 +92,6 @@
return;
}
- // If the encoding is already right, we can bail
- if (encoding.equals(_encoding))
- return;
-
// Don't call super.setCharacterEncoding() - it's too late
// and we'll get a warning
_encoding = encoding;
however since the WARNING is without any harm, we could simple keep the current
behavior...
> avoid UploadRequestWrapper setCharacterEncoding WARNING when current encoding
> is same as the "new"
> --------------------------------------------------------------------------------------------------
>
> Key: TRINIDAD-1434
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1434
> Project: MyFaces Trinidad
> Issue Type: Bug
> Affects Versions: 1.2.11-core
> Reporter: Matthias Weßendorf
> Assignee: Matthias Weßendorf
> Priority: Minor
>
> In upload case we use a wrapper which "setCharacterEncoding()" throws a
> warning when the request param map was already request before.
> Mar 24, 2009 2:29:18 AM
> org.apache.myfaces.trinidadinternal.config.upload.UploadRequestWrapper
> setCharacterEncoding
> WARNING: Unable to set request character encoding to UTF-8, because request
> parameters have already been read.
> caller stack:
> ->
> org.apache.myfaces.trinidadinternal.config.upload.UploadRequestWrapper.setCharacterEncoding(UploadRequestWrapper.java:89)
> ->
> org.apache.myfaces.trinidadinternal.context.external.ServletExternalContext._initHttpServletRequest(ServletExternalContext.java:665)
> ->
> org.apache.myfaces.trinidadinternal.context.external.ServletExternalContext.setRequest(ServletExternalContext.java:514)
> ->
> org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:244)
> ->
> org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157)
> ->
> org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
> The behavior is correct, since it is (according to the servlet spec) illegal
> to set the character encoding after parameters have been retrieved.
> Even this is a pretty annoying restriction.
> However in almost all case the encoding has already been set to the desired
> one and when the current encoding is equal to the new one,
> we could suppress the WARNING
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
