[ 
http://issues.apache.org/struts/browse/SHALE-287?page=comments#action_38611 ] 
            
Mike Meessen commented on SHALE-287:
------------------------------------

Hi Craig,

I tested your attachement (shale-test-core.war). Indeed, this runs well and 
behaves as expected.

However, I replaced all the libraries I was using in my test project with the 
ones you included in your war, I moved the token tag to the end of the <h:form> 
declaration too, but the problem still persists in my test case.

I don't use any inputText though, but simply the refresh button of the browser. 
I don't think this behavior is expected, since with MyFaces 1.1.1 it works...

I included the mofidied test project as ShaleIssueDemo.war. I hope it will help 
you finding the issue.

Regards,
Mike Meessen

> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
>                 Key: SHALE-287
>                 URL: http://issues.apache.org/struts/browse/SHALE-287
>             Project: Shale
>          Issue Type: Bug
>          Components: Core
>         Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
>            Reporter: Mike Meessen
>         Assigned To: Craig McClanahan
>         Attachments: shale-test-core.war, ShaleIssueDemo.war, 
> ShaleIssueDemo.zip
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces 
> project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The 
> core refers to the JSF 1.1 implementation as specified by JSR-127. It has 
> passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should 
> hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue 
> appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to 
> check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data 
> resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic 
> gets invoked).
> **** This is the part where the behavior changes according to what MyFaces 
> version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets 
> invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT: 
> I forgot to mention that with both MyFaces versions, I set the context-param 
> "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't 
> make a difference since I'm using HTTP POST just as the javascript would do, 
> but I think it's worth the hint.
> Regards,
> Mike

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to