Hi, David; thanks for the tips.
Two things of note:
1. Something I just discovered: SureFire forking doesn't actually fork
per test, even if you tell it to. That is, in JUnit 4, a test is any method
annotated with @Test. It appears to be the case that SureFire will fork
once *per test class*, but that isn't the same thing. If you only have
one @Test method per class, then obviously this doesn't matter, but in my
case I have several. So SureFire forking on its own can't solve my problem,
unless I move to a test architecture where I have one test method per
class. For various reasons I can't do that.
2. The undocumented property called out in the article you referenced
works great--but I don't think it causes the connection pool to close. That
is, the context does in fact close, and the container system is destroyed,
and classpath.ear is undeployed. But when the context is reinitialized, the
DDL generation doesn't run again (and the H2 database is not zapped). I'm
using a way of opening an H2 database so that when the last connection to
the database is closed, the database is destroyed. The fact that the
database is still present for the second test run tells me that the
connection pool is not also being destroyed as part of the context shutdown.
In case it helps, here's how I'm building my context:
final Properties properties = new Properties();
properties.putAll(System.getProperties()); // allow for -D properties to
affect context construction
properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
LocalInitialContextFactory.class.getName());
properties.setProperty("openejb.jndiname.format",
"{interfaceType.annotationName}/{deploymentId}/{interfaceClass}");
// See
http://blog.jonasbandi.net/2009/06/restarting-embedded-openejb-container.html
properties.setProperty("openejb.embedded.initialcontext.close",
"destroy");
final String testDatabaseConnectionURL =
properties.getProperty("testDatabaseConnectionURL"); // passed in via -D
if (testDatabaseConnectionURL != null) {
properties.setProperty("test", "new://Resource?type=DataSource"); //
create a DataSource
System.out.println("Using JdbcUrl: " + testDatabaseConnectionURL);
properties.setProperty("test.JdbcUrl", testDatabaseConnectionURL);
properties.setProperty("test.JdbcDriver",
properties.getProperty("testDatabaseDriverClass"));
properties.setProperty("test.Username",
properties.getProperty("testDatabaseUser"));
properties.setProperty("test.Password",
properties.getProperty("testDatabasePassword"));
}
System.out.println("Initializing context");
this.context = new InitialContext(properties);
Now the DataSource I create in line 9 above I am presuming causes the
allocation of some connections to whatever database I've specified in my
testDatabaseConnectionURL (usually jdbc:h2:mem:test).
When I close the context, via this.context.close(), I see this in the
output:
INFO - Destroying container system
INFO - Undeploying app: classpath.ear
I don't see anything to indicate that the DataSource Resource I created in
line 9 is destroyed, and, as I said, once I reinitialize the context--using
the same code I've got above--I do NOT see the DDL regenerated (which
indicates to me there is still a connection to the H2 database somewhere).
Any ideas on how to work around this?
Thanks,
Laird
On Fri, Aug 14, 2009 at 8:35 PM, David Blevins <[email protected]>wrote:
> We have a feature which might help:
>
> https://blogs.apache.org/openejb/entry/user_blog_restarting_the_embedded
>
> We don't always control all the third-party libraries which is why
> internally we use the Surefire Forking approach to ensure we have an
> absolutely clean environment to test against, but definitely let us know if
> you run into issues with the close() approach. We'll definitely do what we
> can to fix them even if they are third-party related.
>
> -David
>
>
>
> On Aug 13, 2009, at 1:07 PM, Laird Nelson wrote:
>
> I have a scenario that I have to assume is fairly commonplace.
>>
>> Following the instructions on the OpenEJB site, I've got a local OpenEJB
>> server running for my unit tests. I park the thing on top of an in-memory
>> H2 database. All fine and good.
>>
>> What I'd like to do is this:
>>
>> - Wipe the database entirely between tests
>> - Cause the embedded OpenJPA to redo any configured DDL generation before
>> each test
>>
>> Note that I'm not looking for what DBUnit does, namely resetting the
>> database for you. I want the JPA provider to take care of the DDL
>> generation for me.
>>
>> Is there any way to do this? H2 helps, somewhat, in that you can open up
>> an
>> in-memory only database that will disappear when the last connection to it
>> is closed. If I could get my grubby paws on the container-supplied entity
>> manager factory at some sort of global level and tell it to reinitialize
>> itself, then I could put that code at the beginning of each JUnit test.
>> This should close all the connections in the OpenJPA connection pool, I'd
>> think, thus wiping the H2 database; and would also, by virtue of
>> reinitializing the EntityManagerFactory, cause the DDL generation to fire
>> again. The net result is that all my EJBs under test would be initialized
>> with a blank database in between tests.
>>
>> I hope I'm making sense. Does anyone have a recipe for doing this?
>>
>> Thanks,
>> Laird
>>
>
>
