"matt.drees" wrote : Hi Jacob,
  | 
  | So you're not using a SMPC.  I guess I tend to assume everybody uses them. 
:-)  My bad.
  | 
  | So I understand more, but I'm still missing a few pieces.
  | 

As for Jacob's approach, I think I roughly understand what he wants to achieve 
with his use of nested conversations, but so far I cannot completely follow 
either because some details of his approach are still unknown to us.    

"matt.drees" wrote : 
  | "jacob.orshalick" wrote : ...Seam has taken a snapshot of my Person entity 
in the outer conversation on nesting (which didn't have the new addresses).  
The original Person instance will be reverted back to should the user back up 
to the original edit Person screen and submit.  Seam retrieves the outer 
conversation by id on submit and restores the state of my Person object at the 
time of the snapshot which doesn't include the new addresses.
  |   | 
  | 
  | It seems like you're embellishing Seam's behavior a little bit.  It's my 
understanding that when you begin a nested conversation, Seam doesn't take a 
snapshot, it just creates a new empty "container", and prevents you from 
storing new objects in the parent container.  While in the nested conversation, 
new objects are stored in this new container, and lookups look there before 
looking in the parent container; there's no automatic cloning going on.  And if 
a user backbuttons out of a nested conversation, then there's no "restoring" 
going on, either; the nested container is simply not there, so new objects get 
stored in the parent container and lookups look there first.
  | 
  |    

Exactly, I already thought the same yesterday evening.  Jacob has repeatedly 
mentioned that Seam saves "snapshots", but I think that is not really the case. 
  Seam manages contexts which are conceptually map-like data structures that 
associate context variable names (Strings) with object values.   As regards 
contexts and nested conversations, when a new nested conversation is begun, 
Seam does in fact NOT clone the objects to which context variables from the 
parent conversation are bound.     When a component class is annotated with  
@PerNestedConversation,    however, any component instance of the same name 
that might exists in the parent conversation is invisible to its child 
conversations.   This may lead to instantiation of a fresh component instance 
in the scope of a nested conversation when a @PerNestedConversationcomponent is 
being looked up.   Do you make use of this @PerNestedConversationcomponent 
feature, Jacob?

Alternatively, regarding Jacob's mentions of "saved snapshots", I was wondering 
whether perhaps he interprets the side-effects of the 
ManagedEntityIndentityInterceptor as "saving of snapshots".  As described in my 
first post in this thread (#1),  when a conversation-scoped component of the 
parent conversation is called from a nested conversation, the 
ManagedEntityIndentityInterceptor saves its wrappers for Entity fields
or Entity collection fields in the scope of the nested conversation and not the 
parent conversation.   It follows that once the nested conversation context is 
destroyed and the parent conversation resumes, these saved wrappers are gone, 
too  (if I'm not mistaken).    This may appear to be a reversion to a previous 
snapshot,  but it is a reversion only as far as Entity fields or Entity 
collection fields are concerned.  All other fields no wrappers are saved for by 
the ManagedEntityIndentityInterceptor  are not reverted to old values.

I'm not sure however whether Jacob's snapshot behavior is caused by the 
ManagedEntityIndentityInterceptor.   If a Seam component is an  Entity, no 
interceptor is added by Seam, thus no ManagedEntityIndentityInterceptor either.

"matt.drees" wrote : 
  | I'm guessing you must be doing this cloning manually somehow to get the 
behavior you describe, but you speak as if it's automatic.  Could you explain a 
little more or show some code?
  | 

we need to know exactly how Jacob's does the management of Entity instances.  
How are they accessed,   are context variables bound to them, and if so, with 
what scope?


View the original post : 
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086108#4086108

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086108
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to