I'm particularly interested if I can run Seam in WebSphere and Tomcat. What do I loose/gain in comparison to running the app in JBoss? Also, are there any licensing restrictions running a Seam app which does not use JBoss?
Yes, that Seam only works with JBoss is a big misconception. It will run in Tomcat fine and can run along with the embeddable ejb3 container as well. Seam can certainly run in WebLogic, WebSpere, and even SAP NetWeaver, but not sure about the ejb3 container.
What you might lose? I can't really think of anything, but maybe things like jBPM and JBoss Rules, but I think they can run in any app server as well.
The bottom line in my opinion is that JBoss is probably more widely used with Seam and there may be a bit more in terms of community support, but if that's not an option, you should be fine in those other environments.
Also, are there any licensing restrictions running a Seam app which does not use JBoss?
There is absolutely no licensing restrictions. Seam is open source to the bone. In fact, it is arguably the the most "open" open source I have come across because the community of users play an extremely active role in the forums and in JIRA. At least 1/4 of the Seam project members are people we absorbed from our user-base (they supplied a new feature, we supplied them with commit access). Of course, we don't just let anyone through the door, but rather those that have a compelling contribution to make. The most telling example is the developers that contributed the Excel module.
What do I loose/gain in comparison to running the app in JBoss?
The question is not what you gain or lose in comparison to running an app in JBoss, but rather what you gain or lose by not running the application in a Java EE container. In my opinion, servlet containers are a half-done job. You know when you go into a new house and the kitchen looks great but there is a ladder to get to the upper floor (or the basement is not finished)? That is what a servlet container is like. You don't have any real management console and you have to take a weekend away from your wife to figure out how to get JTA working in Tomcat (I am done with screwing around with JTA in Tomcat because frankly it is a waste of time).
At this point, seam-gen only supports deployment to JBoss out of the box, so it happens to be easiest to deploy to JBoss. But I have provided instructions on how to modify a seam-gen application to deploy to GlassFish, and to control all aspects of GlassFish, including starting and stopping it. In my opinion, it is easier to deploy to GlassFish now than it is to JBoss.
The Seam project members must support JBoss first and foremost, but several project members, including myself, don't have any problem recommending another app server. And there is even extensive documentation for how to deploy Seam to just about every app server you know of (OC4J, Weblogic, Websphere, and more), and even documentation on how to fix quirks in those other app servers (something even the app server vendor refuses to document).
[ October 08, 2008: Message edited by: Dan Allen ]
[ October 08, 2008: Message edited by: Dan Allen ] [ October 08, 2008: Message edited by: Dan Allen ]
Btw, to cite actual features, when you use Tomcat, you lose JTA transactions out of the box and you may lose JNDI datasource if you don't feel like configuring it in Tomcat. In Seam, you just have to switch to resource-local transactions and perhaps configure the database connection in the hibernate.cfg.xml or persistence.xml file with the vendor properties.