[
https://jira.jboss.org/jira/browse/JBSEAM-2209?page=com.atlassian.jira.pl...
]
Dan Allen commented on JBSEAM-2209:
-----------------------------------
There are a lot of questions floating around in this thread, so what I am going to do is
specifically address the issue at hand and then take the rest up as a documentation task
or future design changes. My research on this issue led me to a very clear understanding
of the MEI and some short term corrections that can be made to improve its effectiveness.
To make a long story very short, you DO need to MEI if you are using SFSB w/ passivation
enabled, even if you are not in a cluster. In the fact, the clustering is a separate and
distinct concern of this interceptor that involves other parts of Seam as well.
The issue at hand is that when the MEI is active, and a component from a parent
conversation is invoked from the context of a nested conversation, the preserved state of
parent conversation component ends up in the nested conversation. As a result, when the
nested conversation ends, the state is not properly transfered to the component in the
parent conversation. I have solved this problem by implementing switch conversation logic
within the MEI. Whenever a method is called on a conversation-scoped component, the
interceptor will switch to the conversation that hosts that component during the
"passivation" step, thus ensuring the correct conversation context (in this
case, the parent conversation). Note that the conversation switch is localized to the
actual passivation logic and does not affect the call itself (so your outjections will
still work as expected).
Fix passivation/activation of entities loaded using an SMPC
-----------------------------------------------------------
Key: JBSEAM-2209
URL:
https://jira.jboss.org/jira/browse/JBSEAM-2209
Project: Seam
Issue Type: Bug
Components: Core
Reporter: Wolfgang Schwendt
Assignee: Dan Allen
Priority: Blocker
Fix For: 2.1.1.CR1
Attachments: nestedConversationsBehavior-Screenshots.pdf,
nestedConversationsBehavior.zip
When a nested conversation ends, it is difficult to transfer an ending result back to the
parent conversation. The following approach is currently not viable with Seam: We
cannot simply access a component from the parent conversation and call a property Setter
of this component with the ending result of the nested conversation supplied as argument
for this Setter. The reason is that when a component from the parent conversation is
called while the nested conversation is still in progress, the
ManagedEntityIdentityInterceptor saves wrappers for the called component in the scope of
the nested conversation (!) and not the scope of the parent conversation. So once the
nested conversation scope gets destroyed at the end of the nested conversation, the saved
wrappers for the component from the parent conversation get destroyed as well.
Scenario:
Suppose that we have a component AA in the conversation context with a field reference
named 'bb' to an another component Q. At some point of time this reference is
moved by the ManagedEntityIdentityInterceptor to a conversation-scoped context variable
with the name "AA.bb". Then we start a nested conversation. While the nested
conversation is in progress, we can call a method of component AA and successfully access
the field bb because at the time of the method invocation, the
ManagedEntityIdentityInterceptor can retrieve the saved wrapper for field bb from the
parent conversation context and put the contained reference into the component AA.
But then we call a method of component AA which changes the field bb. At the end of
this method invocation, the ManagedEntityIdentityInterceptor moves the new value of
reference field bb to a wrapper saved in the nested (!) conversation context. Afterwards
we end the nested conversation and the parent conversation resumes again. When we
then call a method of component AA again, the ManagedEntityIdentityInterceptor retrieves
the wrapper for field bb from the conversation context. But this wrapper contains the
old value for field bb, not the new value. Note that the wrapper with the new value for
field bb got destroyed already at the time when the nested conversation context was
destroyed.
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=118936&a...
Feature request regarding nested conversations
Tue Sep 18, 2007 00:28 AM
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=121852
Nested Conversations (tricky interceptor)
Mon Oct 22, 2007 11:03 AM
--
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