[
https://issues.apache.org/jira/browse/MYFACES-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871757#action_12871757
]
Jakob Korherr commented on MYFACES-2734:
----------------------------------------
I did some research about this issue and I found out that, as you said, the
restore view phase is the only point where this is mentioned in the spec.
However I agree that this should happen earlier (before the
before-PhaseListeners of restore view are executed).
Furthermore I think it is sufficient to do a
viewHandler.initView(facesContext); somewhere in LifecycleImpl.execute() before
the phases are executed, so we do not need the code on FacesServlet.
The problem is that the spec dictates that this has to be the very first thing
that happens in the restore view phase, but (implicitly) after the
before-PhaseListeners where executed:
Spec section 2.2.1: "The JSF implementation must perform the following tasks
during the Restore View phase of the request processing lifecycle: Call
initView() on the ViewHandler. This will set the character encoding properly
for this request. ....."
Spec section 7.5.1: "The initView() method must be called as the first method
in the implementation of the Restore View Phase of the request processing
lifecycle, immediately after checking for the existence of the FacesContext
parameter...."
I also tried to move the call to initView() from RestoreViewExecutor to
LifecycleImpl and the demo worked fine, however 4 tests in
RestoreViewExecutorTest failed, because they expected the call to
viewHandler.initView() in the RestoreViewExecutor.
In addition I also did some black box tests of Mojarra and you are right, they
don't do that on Restore View, but somewhere earlier. I guess this is yet
another undocumented spec-change. I recommend that you create a spec issue for
this and when we get response from the EG, we can move the code to
LifecycleImpl to solve this issue.
> 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.
