OK, I had time to sit down and do this properly and actually test it this time. Its now working fine. What this means is that Seam now no longer needs a JTA or JNDI implementation to run (though you will still need the jta api jar in your classpath). Instead, Seam can delegate to EntityTransaction or Hibernate Transaction via an adaptor that implements UserTransaction. So, the question is, is this a good thing to do? Is it better to run Seam in Tomcat with just the Hibernate jars, and resource-local transaction management, or is it better to go to the effort of installing JBoss Embedded on Tomcat? Well, if you go the resource-local route you are totally on your own when it comes to: * connection pooling (last time I checked, Tomcats connection pool was still a PoS and not usable in production) * JMS * Mail * REQUIRES_NEW or NOT_SUPPORTED transaction propagation * transactions across multiple datasources * Enterprise-level security * WebServices Now, to me these features are kind of non-optional. I simply can't imagine building an application that doesn't need to send and receive email, for example. Sure, you can certainly find solutions to each of these problems and integrate them into the environment yourself, but it seems to me that this is a fucking lot more work than editing two files in Tomcat's conf/ directory and copying some jars across! But, you object, before you used to be able to deploy everything in the WAR and not have to futz with Tomcat configuration at all. Well, yes, thats true, and when Bill explained this redesign to me, I knew immediately that there would be lots of complaints about that. But its not like the old way was perfect, not by a long shot. Sure, you didn't have to "reconfigure" Tomcat, but what you did have to do was add additional configuration in components.xml, and add additional jars in your WAR, which made it impossible to create a WAR that deployed on both Tomcat and JBoss (or GlassFish/WLS/WAS). Oh, and you probably didnt see the awful crap code I had to write to workaround the problem of two JNDI trees in Tomcat deployments (I will never understand the reasoning behind a read-only JNDI implementation - it makes about as much sense as a read-only JPA implementation). Did I make a mistake by removing the MC-only support? I dunno, but my feeling is that there are a lot more people currently using Embeddable EJB3 than plain Microcontainer, and I really wanted to narrow the choice-space of deployment options. We need one or two well-documented options for deploying Seam, not 3 or 4 subtly different permutations of similar things! Nevertheless its a huge problem for me that people can't now deploy the Seam examples to Tomcat just by typing "ant deploy.tomcat" in the directory. And so I will probably end up using my new resource-local transactions for the Tomcat examples in future releases of 1.3. OTOH I don't really consider it a good or useful feature for people building serious applications. Unfortunately, one of the things I know about the tech industry is that there are some things you simply can't change people's opinion of, no matter how strong your arguments and evidence. This whole quasi-religious "lightweight" nonsense is one of those things. It used to refer to a meaningful distinction between technologies like Hibernate/Pico/Spring/etc versus the screwed-up IBM-and-Oracle-designed programming models in J2EE. Now it's degenerated to a general vacuous point of FUD directed at anything which depends upon more than 3 jars, or happens to implement standards instead of reinventing boring, well-understood things like transaction management in a proprietary way. The idea that Tomcat=lightweight but JBoss/GlassFish=heavy is simply absurd. JBoss is easier to develop/debug on and easier to deploy into production. And it's a strict superset of Tomcat, that can run Tomcat applications with no code changes. But, you have to sometimes give people what they think they want, even when it makes little sense. We'll have more success trying to lead people gradually to EE5 by letting them adopt a little piece at a time, as they feel comfortable with it, than we will by telling them to ditch the thing they feel safe and comfortable with. (Aside: "POJO" is another one that's got totally out-of-hand: I like to believe that I wrote one of the "first" POJO frameworks, certainly people point to the success of Hibernate as validation of the concept. But what I was looking for was just a simpler, more practical programming model, that emphasized the business problem. Now you got guys on TSS arguing that ORM is fundamentally broken because objects need id attributes and hence aren't POJOs. WTF! An identifier attribute is making you unproductive? Your users are complaining that your objects aren't POJO enough? This is not a software development problem, this is pure religion. Man, these guys crack me up...) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057107#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...