I just though I would send out a quick overview of exactly what is in the persistence module at the moment: Transactions: It provides a SeamUserTransaction object that extends the JTA UserTransaction (this means a dependency on the jta API). Three default implementations will be provided - The default EE version that either looks up UserTransaction in JNDI or retrieves it from the EJBContext if a CMT is active - An implementation that uses EntityTransaction, this is retrieved from the SMPC - An implementation that uses hibernate's transaction API (to be done) It does not use the CDI's ability to inject the UserTransaction for a number of reason: - It is not available in all environments - It is not available in EJB's that use CMT It provides a transaction interceptor, this allows you to use @TransactionAttribute on managed beans the same way you would on EJB's. It provides @Transactional and @SeamApplicationException for environments where these API's are not available. Managed Persistence Contexts - Defined as follows: @SeamManaged @Produces @ConversationScoped @PersistenceUnit("myPu") EntityManagerFactory enf; - This will work even in environments where @PersistenceUnit injection is not directly supported, as seam-persistence will bootstrap it for you. - The SMPC provides the following: - Automatic transaction enlistment - Ability to use EL in queries - Automatic hibernate search integration, if available - Ability to set manual flush mode if required - Event is fired when the SMPC is created, to allow for additional configuration such as adding hibernate filters. It also provides @TransactionScoped for transaction scoped beans (forgot to put this in the reference guide, oops) There are currently tests for jboss-as, jetty, and jetty+openjpa (with no hibernate classes present on the classpath). I am planning on also adding glassfish, glassfish+hibernate, and probably a few more as well. I have also added seam managed transactions to the faces module, this is similar to seam 2, however it has two notable improvements: - It can be controlled on per view basis (including using wildcards) - it can be enabled only for the RENDER_RESPONSE, so you have manual transaction control in your business logic, and then seam opens a transaction for you when rendering to prevent LIE's (this also can be configured on a per view basis). I think that just about covers it. If anyone has any questions or comments fire away. Stuart