In-container testing in OpenEJB == Amazing

I'm really jazzed right now. With surprising ease, I have configured JUnit to test the persistence behaviors of my entity beans from the CORM project by running OpenEJB embedded directly in JUnit. It was so simple, I couldn't believe it. You can definitely expect an article with a clear tutorial about how to accomplish this in the near future. Here's the convo I had with David over the matter:

[11:20pm] dblevins: saintx: here

[11:20pm] saintx: dblevins: howdy

[11:21pm] dblevins: hiya!

[11:21pm] saintx: dblevins: I figured out the problem from earlier, I think.

[11:21pm] saintx: It was dependencies of openejb-core. They are legion.

[11:21pm] saintx:

[11:21pm] saintx: So, I had to switch my corm project structure to m2

[11:21pm] saintx: Which I've been putting off ... for a long time now.

[11:21pm] saintx: =-)

[11:22pm] dblevins: what were you using?

[11:22pm] saintx: maven 1.x

[11:22pm] saintx: yeah, yeah I know.

[11:22pm] saintx: don't say it.

[11:22pm] dblevins: ahh

[11:22pm] • saintx grins

[11:22pm] dblevins: well we have Ant and Maven2 scripts in there

[11:22pm] dblevins: but yea, no maven1

[11:22pm] saintx: Yeah, but then I'd have to install ant. Meh.

[11:23pm] dblevins: aren't you on osx?

[11:23pm] dblevins: should be in there already (i think)

[11:23pm] saintx: Running the example is one thing--getting the same thing in my project and getting out of servlet hell is the real goal, though

[11:23pm] dblevins: well the examples are designed as starter projects

[11:23pm] saintx: dblevins: I am in OS X. I hadn't considered that ant'd be built in, but now that you mention it, I wouldn't be surprised.

[11:23pm] saintx: Yep.

[11:23pm] dblevins: i.e. you find one thats close and go from there

[11:24pm] saintx: I just finished the upgrade to m2, so that's all behind me now.

[11:24pm] saintx: Haven't eaten in about 12 hours, though.

[11:25pm] dblevins: anyway you've inspired me to add error messages that list the required jars

[11:25pm] saintx: Cool--hopefully it isn't too much work.

[11:25pm] dblevins: mostly finished with a maven plugin that spits a text file into the META-INF dir of the jar

[11:26pm] saintx: I am totally amped to get the in-container tests running now. Once that's going smooth, I think I'll have come full cycle.

[11:26pm] dblevins: once you have working in-container setup, it's all good

[11:26pm] saintx: I'm trying something a tad tricky--I'm going to make the test directory the client with the persistence.xml file defined in a META-INF of the /target/test-classes directory. Do you think it'll work?

[11:27pm] dblevins: no

[11:27pm] dblevins: well

[11:27pm] dblevins: yes and no

[11:27pm] saintx: *whew* glad I asked.

[11:27pm] dblevins: *generally* you must keep your assets together ...

[11:27pm] saintx: If not, then I have a second idea to run past you.

[11:28pm] dblevins: i.e. if they're typically packaged in the same jar, they must go in the same directory (no spreading them around)

[11:28pm] dblevins: but... the persistence.xml is one of those things that can be anywhere in the classpath

[11:29pm] saintx: The jars in my component library don't have persistence.xml files at present, and in this case I only need the persistence.xml file for testing.

[11:29pm] saintx: My client application that I presently use in Tomcat provides its own persistence.xml file, as you might recall.

[11:29pm] dblevins: i.e., if you tried to do the same with an ejb-jar.xml, openejb-jar.xml, application-client.xml, you'd make a mess

[11:29pm] saintx: I see.

[11:31pm] saintx: Does the persistence.xml in my client WAR override the persistence.xml files in my WEB-INF/lib component jars?

[11:31pm] saintx: (just trying to understand the rules here)

[11:31pm] dblevins: no overriding. you'd just have more persistence units available

[11:31pm] saintx: Nope, can't do that.

[11:32pm] dblevins: and if they had the same name then you'd have to specify teh path to the jar or directory containing the persistence.xml of the unit you wanted

[11:32pm] saintx: For container-driven testing (@EntityManager injection) do I need to supply the ejb-jar.xml?

[11:32pm] saintx: I saw the one in the example was completely empty.

[11:33pm] dblevins: there's a comment in the pom.xml that explains a bit

[11:34pm] dblevins: wait, looks like it's not in that one

[11:36pm] saintx: Yeah, the comment about scope made it into most of the poms in my project

[11:36pm] saintx: Good artists borrow, great artists steal. And your pom's are worth stealing david.

[11:37pm] saintx: s/pom's/poms

[11:37pm] dblevins: hehe

[11:37pm] dblevins: here's the doc about the empty ejb-jar.xml
http://openejb.apache.org/3.0/application-discovery-via-the-classpath.html

[11:37pm] saintx: I'll look at it after I eat something. bbi10m

[11:37pm] saintx: tnx, btw

[11:38pm] dblevins: np

[12:13am] saintx: Dude, it worked.

[12:13am] saintx: HAHAAAH! Sweet.

[12:13am] dblevins: awesome!

[12:13am] saintx: I'm. so. jazzed. right. now.

[12:13am] saintx: This is great.

[12:13am] dblevins:

[12:14am] saintx: Essentially, it means that I can test my project libraries and keep on developing them my way, without interference from the persistence layer.

[12:14am] dblevins: sounds like a good quip for a short "this is cool" blog entry

[12:15am] saintx: Yeah, I think you're right.

[12:15am] saintx: I just wrote one, so what's another? It's been a "this is cool" sort of evening.

[12:15am] dblevins: and right, that's exactly what we're offering... the ability to develop ejb applications like you would any other application

[12:16am] saintx: EXACTLY.

[12:16am] saintx: Every time I asked about some funky weird thing that wasn't mentioned explicitly in the specs, first I got "umm . . . we're not sure", but then, sure enough, it . . . just . . . worked.

[12:17am] saintx: It's so cool.

[12:17am] saintx: I mean it, man. Thank you.

[12:17am] saintx: OpenJPA guys get heaps of cred, too.

[12:18am] dblevins: help us spread the word, that's thanks enough

[12:18am] dblevins: i'm quite proud that you can embedd openejb in really anything

[12:18am] saintx: Well, let's get a venue lined up then. Where's the biggest spot for java readers these days? Is it still TheServerSide, or did Java.net ever catch up?

[12:19am] dblevins: we don't need a special plugin for every environment you may wish to develop ini

[12:19am] dblevins: s/ini/in/

[12:19am] saintx: Yeah, it really is awesome.

[12:19am] dblevins: you don't need a maven plugin

[12:19am] dblevins: you don't need special ant tasks

[12:19am] dblevins: you don't need an eclipse plugin

[12:19am] dblevins: you don't need an intellij plugin

[12:20am] dblevins: you don't need to treat us any differently than any other library you'd use

[12:20am] saintx: This allows me to break down my component library like I would normally do, and configure the persistence units from my client jars, WARs, or even target/test-classes directory in the project build.

[12:21am] saintx: Which, ultimately means I give NO GROUND to EJB3 in my architecture. It's very compliant.

[12:22am] saintx: And the in-container testing (container-driven testing?) is so ultra simple. I didn't even run your example, by the way--just ported it over to my app.

[12:23am] saintx: Dain's idea to make hsqldb run completely in memory is a good one.

[12:23am] saintx: Especially for testing.

[12:24am] dblevins: yea, the example you didn't run does that

[12:25am] saintx: This one might too--I just changed the name of the entity, wrote my own persistence manager as a stateful bean.

[12:25am] saintx: Basically a complete analog to the example.

[12:26am] saintx: I can't seem to find the hsqldb files kicking around here, anywhere...

[12:27am] dblevins: do you have something like this in your test case?

[12:27am] dblevins: p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb");

[12:27am] saintx: hep.

[12:27am] saintx: s/hep/yep

[12:27am] saintx: Oh, sure.

[12:27am] saintx: mem

[12:27am] saintx: One more free feature.