[
https://issues.apache.org/jira/browse/MYFACES-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872897#action_12872897
]
Jakob Korherr commented on MYFACES-2734:
----------------------------------------
That's a really good idea Leonardo!
However this might be tested by the TCK, so I don't know if we should change it
now or wait for the EG to respond. What do you think?
> Character encoding not set correctly before Restore View
> --------------------------------------------------------
>
> Key: MYFACES-2734
> URL: https://issues.apache.org/jira/browse/MYFACES-2734
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Affects Versions: 2.0.1-SNAPSHOT
> Reporter: Michael Kurz
> Attachments: MYFACES-2734-test-app.zip, MYFACES-2734.patch
>
>
> In my examples I have a phase listener that outputs all request parameters. I
> accidentially did this before restore view and got some strange behaviour.
> With MyFaces 2.0, reading the request parameters before the restore view
> phase kills german umlauts. This happens because the character encoding is
> calculated and set in the request at the beginning of restore view but after
> the before phase listeners are executed.
> As this is not happening with Mojarra, I set a breakpoint in
> ServletRequest.setCharacterEncoding and saw that they are setting this
> somewhere at the beginning of the lifecycle.
> I quickly checked the spec but the only thing I found regarding the character
> encoding was at the beginning of restore view (which is done correctly in
> MyFaces). But I wonder if it should not be set earlier as, like in my case,
> an earlier access to the request parameters kills umlauts. This might also be
> necessary for extensions doing something with request parameters in a before
> restore view listener.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
