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

The Enterprise JavaBeans development cycle—build, deploy, and test—is time consuming, partly because EJB components run inside an EJB container, which, in turn, depends on various resources like datasources and a JNDI (Java Naming and Directory Interface) provider. The traditional development cycle can vary anywhere from a few minutes to 30 minutes, depending on your application's complexity, the number of beans, and the EJB container's features. Some EJB containers provide hot-deployment such that any change in the application results in an automatic redeployment. Based on my experience, hot-deployment does not always function properly as a cache cleaner—server restart and redeployment is often needed.

Another challenge with EJB development is using the EJB container's debugger tool. Since the test and the container system run in different JVMs, you must set up a remote debugging environment, which itself may become complex.

Unit testing (with JUnit) EJB components is also not easy. Firstly, the beans must be deployed to the container, which itself is time-consuming. Secondly, you have two options with JUnit tests that are both complex and time-consuming:

1. The tests run within the container, which requires the tests to be deployed to the container
2. The tests run in different JVMs and act as a client against a remote EJB container

To address the above challenges, the J2EE community has come up with several good solutions to shorten the EJB development cycle. However, many challenges remain, mostly because of the numerous technologies (EJB, Servlet/JavaServer Pages, Java Message Service, and Java Database Connectivity) a J2EE application relies on. In addition, many competing and complementary solutions are available, and it's difficult to know which one to choose.

As for EJB development, there are varying solutions. One solution is to test the application when it is deployed to an EJB container. Another solution is to test the application on a simulated (mock) EJB container. In the latter solution, when other EJB components or resources (e.g., a datasource) are needed, an external EJB container is called. Nevertheless, these solutions have their complexities and shortcomings.

In this article, I introduce you to a combination of tools that significantly simplify and shorten the EJB development cycle. To give you an idea of the time saved, only three seconds pass from the time some code has changed until the time the test results appear on the screen, using a laptop with a 2.2 GHz Mobile Intel Pentium 4 Processor.

This article is based on my experience with an on-going development project. The project consists of roughly 300 Java classes and 10 EJB components. Throughout the article, I refer to the tools used in the project: XStream, OpenEJB, Eclipse, and Oracle OC4J.

Macroscopic view

Instead of running your test inside a container, run the container inside your test. In this article, we use a lightweight embeddable EJB container inside our tests, as shown in Figure 1.