[pmuir]

http://jira.jboss.com/jira/browse/JBSEAM-2094

[pmuir]

Sorry about the delay getting to this thread.

"wschwendt" wrote:
One problem is that unfortunately Gavin King appears to be no longer present on this forum (yes, I understand that he's probably awfully busy and cannot answer mundane support questions here).

If you can persuade it us it's worth us looking at we can distill it down for him and see what he says (yes, its worth looking at IMO :) ). Gavin is busy with Web Beans atm.

And the following approach is not viable either: 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.

This is what you are supposed to be able to do.

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.

I'm 90% sure this is a bug. Do you have a JIRA issue open for it? Can you point me at it if you do? I need to review it carefully with Norman.

I'm puzzled by the fact that Seam offers nothing yet in this regard. A feature like that would be highly useful when modeling complex flows and composing them of one or more subflows. I hope that an output-mapper gets added to Seam, in order to avoid having to resort to ugly hacks such as writing from the nested conversation to the parent conversation scope.

Even if you were able to write attributes back to the parent conversation do you still think this would be useful?

[wschwendt]

Hi Pete, thanks for your post and please excuse my late response, too. I hardly followed this forum in October and therefore didn't notice earlier that you posted a response in this thread.

"Wolfgang Schwendt" wrote:
And the following approach is not viable either: 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.

This is what you are supposed to be able to do.

"Wolfgang Schwendt" wrote:
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.

I'm 90% sure this is a bug. Do you have a JIRA issue open for it? Can you point me at it if you do? I need to review it carefully with Norman.

ok, if one is really supposed to call a component of the parent conversation in order to transfer the result of the nested conversation, the behavior looks indeed like a bug. By the way, in the meantime another thread regarding the problem was opened by Denis Karpov in late October:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=121852

Therefore, as requested and in face of the second thread, I opened a JIRA issue at the weekend (you probably have noticed it already). http://jira.jboss.com/jira/browse/JBSEAM-2209

I'm puzzled by the fact that Seam offers nothing yet in this regard. A feature like that would be highly useful when modeling complex flows and composing them of one or more subflows. I hope that an output-mapper gets added to Seam, in order to avoid having to resort to ugly hacks such as writing from the nested conversation to the parent conversation scope.

Even if you were able to write attributes back to the parent conversation do you still think this would be useful?

from a technical point of view, it would not be necessary. It would already be a big improvement if it was possible to transfer state to the parent conversation by way of an explicit method call (invocation of a component of the parent conversation).

Nevetheless, from a software engineering perspective, an output mapper feature could still be very useful. But I'd need to write a more detailed explanation about that, with this post I just want to mention the JIRA case. And such an output mapper feature would have to be carefully designed.