Does anyone have first hand experience deploying a Seam-enabled application in the real world?

I'm particularly interested in the use of SFSBs to hold state for Conversations in a clustered environment, and also the packaging/deployment strategy...

- No doubt Conversations are a better programming model. But are they more efficient than the alternatives? (e.g., storing state in the DB, or as hidden form parameters, or even in the HttpSession.)- Does it make sense to have two separate app-server clusters for the Web/Seam layer and the Business Logic EJBs?

We're using it on light test-level volume now to run about 40k / month in sales. This includes the management back-end to setup products / manage customers, etc.

Performance is fine, but then we aren't using some of the potentially heavyweight Seam features like conversations. Our primary scope types are EVENT and SESSION. We were early adopters, and conversations just never worked quite right for us, so we didn't look back. They would be nice to use in some cases, but our workflows are simple enough that having the state in hidden fields is sufficient. Still, Seam is the most wonderful way to develop JSF apps in general.

Right now we are deploying two Seam WARs into one EAR. One WAR is the order site, and the other WAR is the management tool. The only annoying thing about this setup is that Seam always WARNs on startup, "There should only be one Seam phase listener per application", and I always worry about future side effects of that warning. Having 2 Seam WARs in the same EAR doesn't really seem that exotic.

I'd like to second that. Getting that "There should only be one Seam phase listener per application" is not really helpful, since jboss-seam.jar should be placed in the EAR, not in the WAR. So with more than one SEAM application on the server you get that message because of the UCL.

"rdewell" wrote:Our primary scope types are EVENT and SESSION. We were early adopters, and conversations just never worked quite right for us, so we didn't look back.

Are there any others who made long-running conversations work in production environment?We also have a main problem on long running conversations: If a user @Begin a conversation, he doesn't finish the whole conversation by @End the conversation, but he @Begin another long-running conversation (this happens in production), then system will through exception like below from "ConversationInterceptor" this:

javax.ejb.EJBTransactionRolledbackException: begin method invoked from a long running conversation, try using @Begin(join=true) on method: createInstance

Based on I understand about the long-running conversation from Seam docs, click on @Begin with a id, system will check the existing conversations, if found, system will recover the conversation, otherwise, system will invoke a new conversation with the given id. @Begin without a id, system always invoke a new conversation with a new id. I don't know whether we can remove the following code from ConversationInterceptor:

gus888 - I don't completely understand what you are after, but if you are in an long running conversation, then if you try to begin another you will get an exception unless you use join=true. If you always want to rejoin an existing conversation when you hit @Begin, then just add join=true. Or design your application so that a user can never hit a @Begin from inside a conversation (certainly possible to do).