[ 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.