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? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4097323#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...