myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jakob Korherr (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (MYFACES-2734) Character encoding not set correctly before Restore View
Date Wed, 26 May 2010 14:49:39 GMT

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


Mime
View raw message