After some back-and-forthing with David (thanks, David!) and some external links, I'm to a point where I need to request more help from the OpenEJB team.
The background: I am invoking OpenEJB through the Maven SureFire plugin and running it as part of my JUnit 4.6 unit tests. I'm using H2 for my database. I need to wipe out the H2 database between each @Test run. Here's where I am: - SureFire, no matter how you configure it, will not fork a new JVM for each @Test method. It *will* fork a new JVM for each test *class*, but that isn't good enough for what I'm doing. So simply using the Surefire forkMode set to "always" isn't going to work. - To preserve test isolation, I need to make sure that the OpenEJB local InitialContext is actually destroyed when it is closed. For this I am using the excellent tip in http://blog.jonasbandi.net/2009/06/restarting-embedded-openejb-container.html. However, this solution--while it restarts the context just fine (huzzah!)--does not appear to nuke the H2 database, nor does it cause the creation of a new EntityManagerFactory under the covers. This last part is a supposition on my part--the symptom I'm seeing is that the automatic DDL generation I have configured only runs once, where I want it instead to run before each @Test. The net result is that I get primary key violations because data inserted as part of test method 1 is seen by test method 2, which expects an empty database. - H2 keeps an in-memory database open and populated as long as there is at least one connection hooked up to it. I can state with certainty that the fact that the database is still up and populated when test method #2 runs is evidence of the fact that at least one connection to the H2 database survives a container restart. What I need is a way to not just restart the OpenEJB container but the OpenJPA instance it controls as well. As far as I can tell, this is not restarted when the context is closed/destroyed. I see three fundamental approaches here: 1. Treat the fact that the JPA subsystem is not restarted as a bug, and "fix" it so that when you specify that the context should be destroyed the whole shooting match goes down. 2. Invoke some unknown-by-me method that will restart the JPA internals. 3. Hack on Surefire or JUnit in some way to provide an option for forking a VM for each test method and ignore the fact that OpenEJB for whatever reason doesn't cause the OpenJPA internals to restart. Any further tips here are welcomed and appreciated. It also occurs to me this is a conversation for the dev list, but I figured that enough users out there are doing this sort of thing that someone may have solved this problem. Best, Laird
