shale-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan (JIRA)" <>
Subject [jira] Commented: (SHALE-287) Faulty behavior of the "token" component with Apache MyFaces >1.1.1
Date Tue, 07 Nov 2006 19:15:57 GMT
    [ ] 
Craig McClanahan commented on SHALE-287:

OK, I can now see what I think is going on, and can reproduce your reload scenario using the
shale-test-core.war example.  Here's what I did:

* Start with a fresh session

* Navigate to the "Token Processor"

* Type in a value on Page 1 and click "Submit"

* Observe that Page 2 is now displayed

* Press F5 to try a refresh

* Get the warning about doing a POST again, click OK

* Get an error message about "invalid resubmit of the same form".
  Note that page *1* is shown here, not page *2* ... because it was
  indeed a duplicate submit of page 1.

My belief is that this is, in fact, the behavior we want to see ... the reload was indeed
a resubmit of the content for page 1, and we want to not process it.  The challenge is, what
happens next?  And that question is equally applicable if (from page 2) I had used the back
arrow to go back to page 1, then clicked it's submit button again.

It seems to me that the application needs to provide an "escape valve" of some sort, typically
in the form of a cancel button with its immediate attribute set to true, that aborts the current
workflow and gets the application back to a known state.  I don't see an approach that will
let the framework recover gracefully from this scenario within a current workflow -- the framework
is not going to have any knowledge of what state information might have been mutated, or where
to go next without resubmitting.  Do you have any suggestions?

At the moment, I'm leaning towards considering the current functionality as "works as designed."

> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>                 Key: SHALE-287
>                 URL:
>             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,
> 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
> 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:
For more information on JIRA, see:


View raw message