Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Build, deploy, and test EJB components in just a few seconds

OpenEJB simplifies Enterprise JavaBeans development

By Nader Aeinehchi, JavaWorld.com, 06/13/05

Page 2 of 6

The figure on the left shows traditional EJB development, where the application and the test are deployed to a running EJB container. The figure on the right shows that the application and the EJB container can start and terminate inside the test.

Most EJB containers have a footprint too large to be embedded in an application. However, OpenEJB was designed to be embedded and has a small footprint. I found OpenEJB to be a perfect choice for EJB development.

As an embedded EJB container, OpenEJB starts in a just a couple of seconds (on a laptop with a 2.2 GHz Mobile Intel Pentium 4 Processor). When running, OpenEJB is like any other full-featured EJB container.

But what if your project has already chosen a particular EJB container? Can you still benefit from OpenEJB? Can your tests be carried both in OpenEJB and your choice of EJB container? If yes, do you have to make many adjustments? How much effort is required to embed OpenEJB? As an answer to the above questions, let me assert that it takes only a few minutes to set up OpenEJB, and your tests can run unmodified both on OpenEJB and your choice of EJB container.

Tools

Let's first review the tools we need:

• Mandatory tools:
  • J2SE: For compiling and running the tests
  • OpenEJB (0.9.2): As the embedded container
  • JUnit: For writing and automating tests
• Optional tools:
  • XStream: For mocking (simulating) input data
  • Eclipse: For the IDE
  • A J2EE server: Your choice of application server for production purposes

In the development project I participate in, we use Eclipse as the IDE and Oracle OC4J as the EJB container for production. Furthermore, we use XStream to persist Java objects to XML files. These XML files are used for simulating input data for our tests.

Getting started

Below is a summary of the steps you should take in testing your EJB components:

1. As input data, feed your tests with XML files (mocks). This will save you from typing the same input over and over. Here, I recommend using XStream, a tiny but a powerful library that maps XML to and from Java. Instead of XML, you could use hard-coded Java objects as input, but this would pollute your code—not to mention how much time it would take to create and maintain such code. This step is optional.
   
   

   

   Figure 2. A JUnit test can be fed with hard-coded Java objects, or XStream can dynamically create Java objects from XML and feed the JUnit test

2. Write your tests with JUnit or some other unit-test framework. JUnit benefits from a large developer community, and the tool has many extensions.
3. Install OpenEJB (I detail those steps later).
4. Deploy your application jar files to OpenEJB only once. This step does not need to be repeated as long as you do not add or remove EJB components or modify the configuration (see below). The deployment process typically takes a couple of minutes.
5. When you modify a piece of code, you can run the tests with an embedded OpenEJB container. You will probably repeat this step often.
6. When you are satisfied with the quality of the code in Step 5, run the same tests on the application server you have chosen for production. The purpose of this step is to discover possible incompatibilities between OpenEJB and your production application server.

The following sequence diagram illustrates how the JUnit test gets a reference to a bean by embedding OpenEJB as the EJB container.