How to control end of conversations/state of stateful beans

[trouby]

Hey,

I find myself using @Begin(join=true) almost anywhere I want to start a conversation,
The main reason is that I cannot be sure that I'm out of a conversation,
If a user clicked on some button that started a conversation, how can I control the end of the conversation?


I have somehow to force the user to press a button that ends the conversation as they never do that :-) (I can think of ways somehow make to disable all other buttons) or wait for the timeout but this is not a solution,


What is the suggestion? or just use @Begin(join=true) anywhere?





Second question is regarding stateful beans,
If I understand correctly, stateful ejbs are bounded to CONVERSATION context by default, if that is correct, I have the following scenario:

1)A stateful bean with a method annotated with @Begin
2)some forms inputs bounded to the statefulbean properties
3)a method in the same stateful bean annotated with @End

What could be the reason that the bounded data posted from the forms is not there within the method that is annotated with @End?



Many thanks,

Asaf.

[gus888]

For "How to control end of conversations":
I have the same problem. I think that it is critical issue for the core (conversation) of Seam. The Seam forum here suggested that you use "propagation=none" to all other buttons and links which users can reach and propagate away from the current conversation. I think, maybe I am wrong, that this way is not practicable in a production project. One reason is that maybe there are a couple of dozens links and buttons on screen, the second is that maybe there are other conversation begin buttons and links on screen.

My previous suggestion is that as long as system run a @Begin, system should put current foreground conversation to background (let system timeout clean) and start a new foreground conversation (if the conversation id is automatically created by system). Currently, in the Seam, this functionality only works on the SAME foreground conversation bean, for example, I start a conversation A from Conversation Bean A by clicking @Begin from A, then if I go back to click @Begin from the same Conversation Bean A, Seam will create a new conversation, BUT instead, if I go back to click @Begin from Conversation B, the whole system will throw exception (need @Begin (join=true)) and the system will be down. This is critical problem in a production project. Please correct me if I am wrong. I like to create a JIRA if Seam team think it is necessary. Thank you and have a good holiday.

[pmuir]

"gus888" wrote:
For "How to control end of conversations":
I have the same problem. I think that it is critical issue for the core (conversation) of Seam. The Seam forum here suggested that you use "propagation=none" to all other buttons and links which users can reach and propagate away from the current conversation. I think, maybe I am wrong, that this way is not practicable in a production project. One reason is that maybe there are a couple of dozens links and buttons on screen,

So this is just laziness?

the second is that maybe there are other conversation begin buttons and links on screen.

This is application design. If you *have* to start other conversations from that screen look at ending the conversation before redirect.

Its perfectly possible to use conversations in an application, you just need to consider the paths the user will take through the application.

[pmuir]

"gus888" wrote:
My previous suggestion is that as long as system run a @Begin, system should put current foreground conversation to background (let system timeout clean) and start a new foreground conversation (if the conversation id is automatically created by system). Currently, in the Seam, this functionality only works on the SAME foreground conversation bean, for example, I start a conversation A from Conversation Bean A by clicking @Begin from A, then if I go back to click @Begin from the same Conversation Bean A, Seam will create a new conversation, BUT instead, if I go back to click @Begin from Conversation B, the whole system will throw exception (need @Begin (join=true)) and the system will be down. This is critical problem in a production project. Please correct me if I am wrong.

Not really. Clicking back *does not* propagate the conversation. It just takes you back to the page as it was when you were on it before (read about how the back button works). So if you aren't in a conversation on your "start" page, you go into conversation A, then click the back button, you won't be in a conversation, and can start another one. Seam doesn't differentiate between conversations based on what method they are started from.

I like to create a JIRA if Seam team think it is necessary. Thank you and have a good holiday.

I really don't think this is necessary, and would just be (another) thing to learn about Seam. So I'm -1.

[gus888]

"gus888" wrote:
For "How to control end of conversations":
I have the same problem. I think that it is critical issue for the core (conversation) of Seam. The Seam forum here suggested that you use "propagation=none" to all other buttons and links which users can reach and propagate away from the current conversation. I think, maybe I am wrong, that this way is not practicable in a production project. One reason is that maybe there are a couple of dozens links and buttons on screen,

So this is just laziness?

Hi Pete,
First, thank you for your reply. I think that it is not just laziness. The conversation is specifically useful for complicated project, based on Kavin's statements in the tutorial. For a complicated project with top drop-down menus, left bar menus and right bar menus, developers have to put "propagate=none" to **every buttons and links** at every conversation step to prevent users from propagating away from a conversation. Importantly, this way seems that software developers are completely controlled by non-coorporate user's behavior, but based on my little experience, software developers should always control non-coorporate user's behavior. Correct me if I am wrong. Thank you.

[pmuir]

This is correct, I don't see why putting propagate=none for all menu type links is a problem...

[gus888]

I don't see why putting propagate=none for all menu type links is a problem...

Hi Pete, really, it is not a problem, but what I mean whether it is possible let Seam system to do the propagate=none job for a conversation once a user propagates away from the conversation and starts a new conversation. Thanks.

[trouby]

Hey,

I still don't get it, what about links that -should- start a new conversation? is it possible to combine begin/end annotations together for the same method? like ending the current conversation and starting a new one?


btw, I have a seam link which invoke an method that is annotated with @Begin, invoking the same link just after the first invocation throws "begin method invoked from a long-running conversation, try using @Begin(join=true)", so what should I do in such situation?? I don't want -another- conversation to start in this case,

I guess I'm doing something wrong, as in seam booking example the 'setHotel' is annotated with @Begin and can be invoked many times without this exception,



Thanks.

Asaf.

[gus888]

"trouby" wrote:
I guess I'm doing something wrong, as in seam booking example the 'setHotel' is annotated with @Begin and can be invoked many times without this exception

No, you didn't do anything wrong. As I posted above, the @Begin in booking example always was invoked in the same bean ("hotelBooking"), so no exception thrown. If you change "hotelSearch" bean to CONVERSATION, then add @Begin in find() method, you will get the exception you mentioned. In the book of JBoss Seam (Michael Yuan) P 114, it also states that as long as you invoke new @Begin or even have a coding error (forgot @End), the current conversation will time out. I think it should not work at least in current Seam release.

[trouby]

So if the same method that is annotated with @begin is invoked within the same bean -instance- a new conversation is created without exception? what's the difference between a new conversation starting from the same bean instance or from different bean instance? why the behavior is different?


Asaf.

[gus888]

"trouby" wrote:
what's the difference between a new conversation starting from the same bean instance or from different bean instance?

I think that they are the same. Both of them create new conversations with new ids.

"trouby" wrote:

why the behavior is different?

I think that this is a Seam bug according to Michael Yuan's JBoss Seam book P114.

[trouby]

Alright,

Well, sorry for being so annoying but I still don't get the point,
If I have buttons that should start a conversation, propagation='none' is not an option,


big part of my buttons start a new conversation, so no matter what, I find myself adding join=true, at least for these buttons,


But as it seems most of the people are comfortable with it, I still find it really confusing and not exactly correct,


What I think is that it might be useful to have an option to end/start a new conversation on the same method/link/etc...


Asaf.

[pmuir]

"trouby" wrote:
I still don't get it, what about links that -should- start a new conversation? is it possible to combine begin/end annotations together for the same method? like ending the current conversation and starting a new one?

Yes, but you have to end the current conversation before a redirect, and start a new conversation after a redirect (you can do this from pages.xml or from annotations). I've not seen a great use case for this though.

btw, I have a seam link which invoke an method that is annotated with @Begin, invoking the same link just after the first invocation throws "begin method invoked from a long-running conversation, try using @Begin(join=true)", so what should I do in such situation?? I don't want -another- conversation to start in this case,

If you want to join the current conversation, use join=true, otherwise, design your app so the use can't be on that page when a long running conversation is in progress.

I guess I'm doing something wrong, as in seam booking example the 'setHotel' is annotated with @Begin and can be invoked many times without this exception,

Yes, because you can't be on the page which calls this method and inside a long running conversation.

[pmuir]

"gus888" wrote:
No, you didn't do anything wrong. As I posted above, the @Begin in booking example always was invoked in the same bean ("hotelBooking"), so no exception thrown.

What Seam component conversation demarcation is expressed in has no effect on conversation boundaries or behaviour.

[pmuir]

"trouby" wrote:
So if the same method that is annotated with @begin is invoked within the same bean -instance- a new conversation is created without exception?

No, this is not true.

what's the difference between a new conversation starting from the same bean instance or from different bean instance? why the behavior is different?

There is no difference, if there is, it is a bug.