On Jun 4, 2010, at 12:42 AM, Bruno Dusausoy wrote: > On Thu, 03 Jun 2010 15:44:09 +0200, Bruno Dusausoy <[email protected]> > wrote: > > [...] > > Ok, so I'm thinking of this sequence of initialization : > > - Declaring a DBCP DataSource within Spring (may be not needed since > OpenEJB also uses DBCP); > - Creating an EntityManager with LocalContainerEntityManagerFactoryBean, > so I can tweak the creation of the former; > - Launching OpenEJB; > - Getting the transaction manager from OpenEJB and link it to Spring's > JtaTransactionManager thanks to its reference; > - Declaring <tx:annotation-driven/> so I can use @Transactional > annotations in my classes; > - Injecting the DataSource declared above into OpenEJB (is it needed since > the EntityManager will have a reference to it ?); > - Injecting the EntityManager into the EJB's who need it; > > Would this work, and as asked before, will the whole transaction process > be coherent ?
Sorry for responses on the list being a bit slow, we're working quite heavily on EJB 3.1 at the moment. Maybe if you could share some of the motivation why you need Spring to hand so much of the transactional work. Does the application that runs in Glassfish use Spring created EntityManagers and DataSources rather than the ones created by Glassfish? If the goal is simply to do things just as would be done in Glassfish and be able to write transactional tests, then maybe check out this example: http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/transaction-rollback/ Maybe also this one as it uses the same persistence provider as Glassfish uses: http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/jpa-eclipselink/ As well it is possible to supply an entirely different persistence.xml for just testing purposes: http://openejb.apache.org/3.0/alternate-descriptors.html Hope some of this helps! -David
