Anyone care to share the typical architecture to be used in a Seam project.
Take a look at some of the larger example projects in the Seam distribution.
AppFuse provides you with some cool stuff right away, but definitely imposes many architectural and layering constraints on your project. The tradeoff is a baseline for development that is wired up OOTB.
seam-gen'ed projects do this to a much lesser extent. You get a working shell of an app right away, but you're free to layer the application the way you decide. If you want, you can use seam-gen to create Rails-like scaffolding for different parts of your app. Infact, I think the plan is for Eclipse tooling to do this for you in the future.
Thanks for your response. I had to google scaffolding since I don't know much about Rails.
Yes, I thought Appuse was great too but also "bloated"
Given the hassles with EJB in the past, do you think Seam using EJB3 stateless beans as managers is a good idea?
I'm just very skeptical about that. Developing for EJB3 supported application servers is not my problem.
If you use Seam, you don't want to restrict yourself to stateless beans, you loose the power of the framework (find a video/audio interview with Gavin, he always rants on about this).
Of your possible choices I definitely don't recommend using stateless session beans everywhere. You should use an appropriate mix of stateless and stateful if you take the EJB route.
If you don't take the EJB route, you have a choice between Seam POJOs or Spring POJOs. In a JSF-based architecture, there is a compelling reason to choose Seam components: the contextual state management model is simply a much better fit to JSF, and the next rev of Java EE will include this model (the Web Beans spec).
So it comes down to session beans or not session beans. Your choice. Try out EJB3. If you like it, stick with it. If you don't, use plain Seam components. You can always change your mind later.
Note that there are a couple of problems for which you really do need EJB in Seam: eg. REQUIRES_NEW transactions and message-driven beans. However, you can always mix and match.