[
http://jira.jboss.com/jira/browse/JBSEAM-1832?page=all ]
Pete Muir updated JBSEAM-1832:
------------------------------
Fix Version/s: 2.0.0.GA
(was: 2.0.0.CR1)
Slipping as need to discuss this in more detail. Improved docs should help for now.
My conclusions are:
- something like dropTimedOutRequests="true" in RichFaces as an option for
requestDelay
- when non-ajax request occurs on a view, cancel all Ajax events (waiting for return?)
and then do submit (this in RF)
- Seam needs to know the difference between concurrent timeouts and conversation
timeout (diff warning)
- Granularity of conccurent request control (pages.xml?)
- More leniency from Seam when concurrent requests occur - perhaps (default?) of
dropping concurrent timeout requests. Options are to drop the conversation (eugh, current
behviour), drop the request, or to process the request in a temp context but to then
return to the correct context later (odd)
Use of <a:support> tag breaks conversation in Seam-gen (and
elsewhere)
----------------------------------------------------------------------
Key: JBSEAM-1832
URL:
http://jira.jboss.com/jira/browse/JBSEAM-1832
Project: JBoss Seam
Issue Type: Bug
Components: JSF
Affects Versions: 2.0.0.BETA1
Environment: Jboss 4.2.0.GA
Reporter: Vincent Latombe
Assigned To: Pete Muir
Fix For: 2.0.0.GA
Attachments: ConcurrentCalls.diff, hello.zip
I've seen the problem from BETA1 to HEAD
To reproduce the bug, try the following :
Create some seam-gen based project and generate-entities.
Go to an edit page, fill some data, and click on the submit button, without clicking
elsewhere (the focus must be on an edited field just before submit). Instead of validation
error, or adding the new data, you should get the "The conversation ended, timed out
or was processing another request" message. It seems that the validation triggered by
the onblur event messes up with the validation.
I have also seen the bug occuring while I was switching from one field to another quite
fast (fast enough to have many validation on queue in ajax4jsf). It seems that adding
<s:conversationId/> to the a:support solves this part.
Here is the snippet I currently use
<a:support event="onblur" bypassUpdates="true"
reRender="cityCodeDecoration">
<s:conversationId/>
</a:support>
I tried to upgrade ajax4jsf + richfaces 3.0.1 to richfaces 3.1.0 rc2, but it didn't
change anything.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira