Well that's an open ended question isn't it?

I think any valid response would have to be to a specific set of complaints.

I definitely do see some potential maintainability issue with a large project and a large team using annotations to name components, for instance. Obviously you can standardize on using the components.xml file or something like that.

Seam is also somewhat in it's its youth, meaning that the code base is constantly changing and new releases come out frequently. It's not an an annual release cycle. It also lacks some of the mature documentation, and the wealth of knowledge which gets generated by tens of thousands of people using it to do all kinds of things on a day to day basis. i.e. googling an odd error or trying to research how to do something tricky will be easier with JBoss itself, or WebLogic, or Struts, because they've been around longer and been put through more paces by more people.

There's also a lack of design and coding conventions so far, and no real examples (although I do think it's possible) on how to manage a LARGE Seam application, worked on by a team of 20, which has to be deployed to individual dev machines, shared dev instances, assembly test env, functional test env, load test cluster, preview, and a production cluster, each needing their own configuration overrides and whatnot. Again, i think it's doable, but I don't know that anyone has done it yet. Or at least they haven't documented best practices.

I'm also not sure what level of support is currently offered from Redhat for Seam. I know it didn't used to be available for enterprise support, although that may have changed.

All of that said, I think from an architectural standpoint, there isn't a reason to doubt Seam's applicability to large enterprise use.

Can you be more specific about why Seam may not be for large apps?

Recently I heard someone claim to have been abducted by aliens. What do you think?

Seriously, we've designed Seam to be useful at all scales, from simple web apps to complex enterprise applications. You get more leverage from Seam on smaller apps, but that's mainly because traditional J2EE apps (and most Java solutions, for that matter) are way too complex for simpler applications.

If you are writing a Java EE application with Seam, you are using the same for EE technologies as if you weren't using Seam. Seam is giving you the potential for simplified architecture and easier integration with all the technologies you are likely to want to use. (JSF, JBPM, Drools, etc...) Seam isn't making your large EE app less-reliable or less scalable - it's just making it easier to develop.

On the question of support - yes, Red Hat does offer production support for Seam. If that's of interest to you, please contact sales.

Maybe this is the place to define "seam design patterns"?

@norman.richards: I absolutely agree. Thanks for the info about the production support!

@amitev: this may be a place to start hammering them out, but they need to be published somewhere less fleeting I think.

@hubaghdadi: well, could you be more specific about what you heard? Also, we'll need that guys address so we can pay him a little visit:> (j/k)

We are getting very close to the new community site for Seam which will give us all a good place to develop this kind of information.

That will be great!

I'm very interested waiting for Seam Design Patterns!

When will new community site starting?
(Say, with Seam 2.0.0.GA or later?)

As soon as Christian finishes writing it ;) Soon :)

So the new site will be developed using seam?

Check out the wiki example in the seam source. I bet that'll be what drives the community site. Incidently the wiki example is an excellent place to look at to see a non-trivial seam application. I've learned a lot from it.

Of course! http://in.relation.to is a blog based on the wiki (which is what the community site will be based on). And its a delight to use!