Seam Conversation Should Be Flexible but NOT

[app4you]

After implemented a full blown application using Seam 1.1, my experience on Seam comes to a mix, really and seriously. Why? Here are my reasons why:

* Maintaining the session timeout, say 30 minutes

* Maintaining the EJB3 timeout

* Maintaining the application component conversation timeout

* Live development in Eclipse using Tomcat plug-in for quick monkey-do-monkey-see will crash Tomcat server. If you modified a Java file then Tomcat will automatically updates the changes ====> crashed most of the time

* Conversation timer should be flexible to turn on/off. Say if your application requires that the application form has to be in the edit mode all time unless user clicked on the Done button. If you want to conversation to end at the same time as the http session timeout, then you have to set the conversation timeout to equal to the HTTP session timeout, 30 minutes, you are asking for bog down - too many sessions. Otherwise, say while the user is looking at the data report for 5 minutes then she tries to fix something on application entry form, boom! Conversation is timed out, redirected to the home.faces. This is bad!!! Imagine that you have the tree and tab interfaces and the application has tons of modules, unless your application is simple like the Hotel demo app.

* Seam's security is not sufficient enough to protect all the resources besides the component classes and the XHTML files, like the standard J2EE Form-based Authentication or ACEGI. If ACEGI or custom filter is used, Seam's conversation stack will kick in (from my experience here) very unpredictable.

My thoughts are Seam has simplified the development ALOT, but its conversation is not really ready for prime for those medium/big sized applications. If only Seam is flexible enough on its conversation setting to allow it to be on/off, then it will be more suitable. Remember that most of the applications' requirements don't NEED separate conversational workspaces at all. Why can't I turn off the conversation timer like Spring application for instance.

If you have any advice, comment or suggestion on how to stop the conversation timer or how to turn it on/off, please share. Otherwise, people like me is a bit hesitated for using Seam for any later projects.

Thank you.

John

[cptnkirk]

So you're asking for something like @Begin(timeout=ms)?

[pmuir]

* Maintaining the session timeout, say 30 minutes

* Maintaining the EJB3 timeout

This is a pain:

http://jira.jboss.com/jira/browse/EJBTHREE-788

* Live development in Eclipse using Tomcat plug-in for quick monkey-do-monkey-see will crash Tomcat server. If you modified a Java file then Tomcat will automatically updates the changes ====> crashed most of the time

I don't work with Tomcat, but I believe this is due to poor interaction between Eclipse and Tomcat. This works fairly well with JBoss AS, and Max was talking to the guy who deals with who writes the hot-replacement for Eclipse to try and improve it.

* Conversation timer should be flexible to turn on/off. Say if your application requires that the application form has to be in the edit mode all time unless user clicked on the Done button. If you want to conversation to end at the same time as the http session timeout, then you have to set the conversation timeout to equal to the HTTP session timeout, 30 minutes, you are asking for bog down - too many sessions. Otherwise, say while the user is looking at the data report for 5 minutes then she tries to fix something on application entry form, boom! Conversation is timed out, redirected to the home.faces. This is bad!!! Imagine that you have the tree and tab interfaces and the application has tons of modules, unless your application is simple like the Hotel demo app.

I don't quite get what you are after here. You want to have it so that conversations can never timeout? Then it's just SESSION scope (but admittedly isolated)... You can already achieve this effect by having a very very long conversation timeout. Or are you after flexibility - giving different conversations different timeouts (you can currently do this programmatically, but not through xml/annotations)

* Seam's security is not sufficient enough to protect all the resources besides the component classes and the XHTML files, like the standard J2EE Form-based Authentication or ACEGI. If ACEGI or custom filter is used, Seam's conversation stack will kick in (from my experience here) very unpredictable.

Can you file an issue for this (your underlying problem of not being able to protect resources, not the issues integrating other security solutions) :)

Thanks for the feedback :)

[app4you]

Petemuir,

I don't quite get what you are after here. You want to have it so that conversations can never timeout? Then it's just SESSION scope (but admittedly isolated)...

-> SESSION scope is never a good implementation unless you have a very good reason to go for, neither a very long running conversation timeout or even set it to the same time-out as the HTTP session time out. Standard is 30 minutes, or at least most of my apps.

You can already achieve this effect by having a very very long conversation timeout.

->. Imagine that your application has tab and tree UI components exposed all time and setting the conversation timeout greater than the HTTP session time out or unlimited, aren't you asking for trouble? You will have a whole bunch of runaway conversations running behind the scene and waiting to be closed by the their conversation timers, assume that the user did not click on the DONE or CLOSE button to close the forms' conversations properly.

Or are you after flexibility - giving different conversations different timeouts (you can currently do this programmatically, but not through xml/annotations)

-> Who would you go about that? And would that manually setting be scattered all over the place, for each component that is? What we need is the ability to control the conversation time-out to rely on the HTTP session timeout or a way to disable the conversation timeout but not by means of "never timed out conversations"

Just try to put a complex UI application that has a lot of business components with tree+tab interfaces and see how sufficient the application conversation stack can be. Please make sure that "the application data entry form has to be in the edit mode all the time unless the user want to close the form by clicking on the DONE, CLOSE or whatever... button to get back to the search result page".

Thank you all.

John

[pmuir]

-> SESSION scope is never a good implementation unless you have a very good reason to go for,

Yes, you shouldn't put data that doesn't need to be session scoped into the session. But if your spec says that you need session scope views then...

neither a very long running conversation timeout or even set it to the same time-out as the HTTP session time out. Standard is 30 minutes, or at least most of my apps.

Sorry, I can't parse this.

->. Imagine that your application has tab and tree UI components exposed all time and setting the conversation timeout greater than the HTTP session time out or unlimited, aren't you asking for trouble? You will have a whole bunch of runaway conversations running behind the scene and waiting to be closed by the their conversation timers, assume that the user did not click on the DONE or CLOSE button to close the forms' conversations properly.

I can't see why.

Or are you after flexibility - giving different conversations different timeouts (you can currently do this programmatically, but not through xml/annotations)

-> Who would you go about that? And would that manually setting be scattered all over the place, for each component that is?

You could have a property on the @Begin annotation and on the pages.xml begin-conversation element that takes either a integer or injects an integer using EL. Further, there is undocumented support for conversations which use natural ids - you could set the timeout for such a conversation.

What we need is the ability to control the conversation time-out to rely on the HTTP session timeout

Something like this would perhaps help (but you would still get conversations timing out before the session if they hadn't been "touched" recently).

components.xml

<core:manager concurrent-request-timeout="500"
 conversation-timeout="#{session.timeout}" conversation-id-parameter="cid"
 conversation-is-long-running-parameter="clr" />

or a way to disable the conversation timeout but not by means of "never timed out conversations"

Surely this is an oxymoron - you want to have conversations that don't timeout but don't never timeout. You need to explain this one better ;) If you are saying you want to clean up the conversations associated with a user when their session times out, then this is current behaviour.

Just try to put a complex UI application that has a lot of business components with tree+tab interfaces and see how sufficient the application conversation stack can be. Please make sure that "the application data entry form has to be in the edit mode all the time unless the user want to close the form by clicking on the DONE, CLOSE or whatever... button to get back to the search result page".

Yes, if you want to hold open a view as long as the sesion is active, then you have to use the session to hold the data. A shorter-lived scope won't ever cut it here!

[pmuir]

If your spec calls for session scoped atomic "conversations" (here I mean a dialog between the user and the application then thats what you have to give. Of course Seam's CONVERSATION scope also gives you browser window isolation.

[app4you]

-> SESSION scope is never a good implementation unless you have a very good reason to go for,

Yes, you shouldn't put data that doesn't need to be session scoped into the session. But if your spec says that you need session scope views then...

Did you read my post carefully yet :) Common I did not say that I need all components in SESSION.

neither a very long running conversation timeout or even set it to the same time-out as the HTTP session time out. Standard is 30 minutes, or at least most of my apps.


Sorry, I can't parse this.

Can't see? Can you look at the conversation stack for a bunch of runaway conversations waiting to be closed? Hardware is cheap but never enough for a large user base environment.

<core:manager concurrent-request-timeout="500"
conversation-timeout="#{session.timeout}" conversation-id-parameter="cid"
conversation-is-long-running-parameter="clr" />

I knew this and did even use Seam's API to control programmatically but this is not what I was talking about in my original post. A more elegant timeout that coordinates with http session timeout.

Yes, if you want to hold open a view as long as the sesion is active, then you have to use the session to hold the data. A shorter-lived scope won't ever cut it here!

I don't want to use conversational session scope, only conversational scope here or no conversation at all by setting the conversation on/off.

Thanks anyway

[pmuir]

Did you read my post carefully yet :)

Yes, I have read it several times - I want to understand what you want/what your issues so we can try to make your apps work better with Seam. You are using a common paradigm for a user interface - one that you say Seam doesn't work well with.

Common I did not say that I need all components in SESSION.

No, you never explicitly stated what scope the components should be in. I inferred from this

the application data entry form has to be in the edit mode all the time unless the user want to close the form by clicking on the DONE, CLOSE or whatever... button to get back to the search result page

that you were looking for session scoping from your post.

What scope should your components have? Not in terms of Seam's SCOPEs necessarily, but in terms of user experience.

neither a very long running conversation timeout or even set it to the same time-out as the HTTP session time out. Standard is 30 minutes, or at least most of my apps.


Sorry, I can't parse this.

Can't see?

No, I meant I didn't understand the sentence.

Can you look at the conversation stack for a bunch of runaway conversations waiting to be closed?

Yeah. Look at the conversationTimeout method in org.jboss.seam.core.Manager for how Seam times out conversation. You could create an extended version of Manager and implement a custom conversationtTimeout that used an algorithm more suited to your app. The API for this stuff is all public :)

A more elegant timeout that coordinates with http session timeout.

Spell out what this means - I haven't understood yet ;) What do "elegant" and "coordinate" mean?

I don't want to use conversational session scope, only conversational scope here

Ok, so just to clarify: You don't want to use SESSION scope. You want to use CONVERSATION scope.

or no conversation at all by setting the conversation on/off.

What does setting the conversation "off" mean? Normally if you want a scope shorter than CONVERSATION you would use PAGE or EVENT

[atleprange]

If you set the conversation id manually, you can control the number of conversations created. (The side effect is that you might rejoin the conversation even if you don't want to.)

You could also be sure to end conversations whenever a new treenode or tab is clicked. That way you only have one conversation running at a time, giving you the option to have a long timeout period.
If the user enters a tab with a form, and the exits the form by clicking another tab, the conversation will be closed again.

And if the user opens a new window, the users could fill out two forms concurrently (which is one of the big benefits of the conversation)

Alas its not possible to "restart" a conversation with one action (correct me if i am wrong here), so you would have to redesign parts of the "tabbing"....

Of course it all depends on your requirements....

[app4you]

Atleprange,

Yes, I did all of your mentioned methods. Otherwise, you think I could get it done :).

For tree component, I was using Apache Tree2. The weird thing is the combination of AJAX4JSF won't work well with the <h:commandLink>. I had to use <s:link> instead. Now for ending the a form's conversation when user clicks on a treenode or tab, I used <s:link propagation="end"> to close any form that is being opened that has conversation scope, which failed to end the current conversation sometimes. And BTW, each tab will have its own Tree2 navigation menu tree display as well.

For window conversation isolation, there wasn't any need for it but I knew that since each time the @Begin got call, it will create a new id across the application.

As far as my app requirements, some search form has to be in session, specially those that requires to display the conversationList stack, while other are just conversation scope.

Well, I can tell that I had fun implementing a full blown app using Seam. But I am a bit skeptical to recommend or use it again soon. Unless there is a solid sample app bundled with Seam download that has some type of complex interface layout, like the trees and tabs, that handles the conversations sufficiently.

Thank you.

[atleprange]

Just a short comment: i had the similar issues you mentioned, as I also was risking an huge growth of un-ended conversations. (But my application requires multiple parallell windows.)
I was overwhelmed by the possibilites that the conversation context gave me that i started to see almost every user interaction as a candidate for a conversation. In the end i solved by just having one conversation, possibly nesting if needed. (The users just love really long conversations ;)

[app4you]

Atleprange,

Watch out for the performance I would say