[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4028) way to outject someting in to the CURRENT conversation even if a new one is started before the context is flushed

David Schlotfeldt (JIRA) jira-events at lists.jboss.org
Sat Mar 21 19:17:22 EDT 2009


way to outject someting in to the CURRENT conversation even if a new one is started before the context is flushed
-----------------------------------------------------------------------------------------------------------------

                 Key: JBSEAM-4028
                 URL: https://jira.jboss.org/jira/browse/JBSEAM-4028
             Project: Seam
          Issue Type: Feature Request
    Affects Versions: 2.1.2.GA
            Reporter: David Schlotfeldt


If you outject and then create a new nested conversation the outjected variable ends up in the nested conversation. This is because ServerConversatoinContext keeps the "additions" to it separate from the actual context variables -- just in the case it needs to "rollback". When the render response phase takes place ServerConversationContext "commits" the new additions. The "key" of each addition is determined at that time. The key of entries is prefixed with the conversation id to allow Seam to determine what conversation it is for.  It would be nice if when one could outject the variable into the conversation that  was current when it was outjected. This could easily be done by storing the conversation id that was current in the "additions" information and using it instead of the current conversation id when flushed. This of course is a change that could cause many issues for people so I propose an attribute is added to @Out called "conversation-at-flush=[true|false]" with the default value of true. If you want the outject to be in the converation current  when outjected you set this attribute to false.

Just to point out an issue I could see happen if not kept in mind when implementing: A nested conversation could in theory start, things outjected, and then the nested conversation ended before flush takes place. When flush does happen we need to filter out those outjects from the nested conversation that had  conversation-at-flush=false since that conversation was ended. This simply means checking the conversation id is still active before making the addition/removal.

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

       




More information about the seam-issues mailing list