In my testing I've noticed that it looks like Seam will obtain a single instance of an SFSB and store it in the HTTP session, and then overlay conversation contexts onto the SFSB when a conversation changes.  When I add bijection annotations on property methods and log what is happening, I notice that injected properties are initialized with the values of the context variables, and at the end of the invocation they are set to null, presumably to ensure a clean slate for the next conversation switch.

Up to this point I had assumed that only fields and properties that have injection annotations are affected.  However, recently we've been experiencing a number of situations in which the fields of the SFSB nulled out.  This happens most frequently when a conversation-scoped SFSB in a child conversations raises an event that is observed by a method in another conversation-scoped SFSB in the parent conversation; during the observer method invocation the fields on the latter SFSB (in the parent conversation) are null.  Changing the beans to session scope eliminates the problem.

This leads me to believe that there a conversation switch may actually change the state of non-injected fields on an SFSB.  Is this the case?

If it is not the case, then what are the implications of having a conversation scoped SFSB instance that is used by multiple nested conversations?  Can the field values then be shared from child to parent?  Doesn't that violate conversation isolation?  What are the best practices in this case?