[
https://issues.apache.org/jira/browse/MYFACES-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Korherr updated MYFACES-2734:
-----------------------------------
Status: Resolved (was: Patch Available)
Fix Version/s: 2.0.1-SNAPSHOT
Resolution: Fixed
> 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
> Assignee: Jakob Korherr
> Fix For: 2.0.1-SNAPSHOT
>
> Attachments: MYFACES-2734-doPrePhaseActions.patch,
> 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.
