< Zurück | Inhalt | Weiter >

23.4.2 XDoclet

XDoclet is an important tool to help with the automation of EJB-related tasks. Working in conjunction with Ant, it uses the Javadoc mechanism of Java to


3. http://www.javalinuxbook.com/

automate the building of many of the EJB files and deployment descriptors. Recall that Java comments can include special Javadoc tags, such as @author and @param. Javadoc uses these tags to generate HTML files that are the docu- mentation of your Java classes and methods based on the text associated with these tags. XDoclet takes this a step further and defines tags like @ejb.bean and a few dozen more. Then, using the Javadoc mechanism, it can generate all the various pieces required for an EJB. Used this way, you can write a single source file for your EJB, and have XDoclet generate the various home, remote, and local interfaces as well as the deployment descriptors.

So why aren’t we all using XDoclet? It has been around for a few years and is gaining a following in the development community. We may be moving in that direction, but it will take some time. It adds yet another layer to what is needed to build an EJB application, albeit a layer that brings some simplifica- tion. Later releases of EJB specifications from Sun may subsume its EJB func- tionality. However, it is still very important to understand the pieces that go together to make an EJB application. One of the favorite quotes from XDoclet in Action by Craig Walls and Norman Richards says it well: “Don’t generate what you don’t understand.”


One of the best uses of J2EE technology, particularly the EJB technology, is to provide a single common interface to heterogenous systems. If an application provides any sort of file, data, pipe, or network access to its data, you can wrap an EJB interface around it and make it available to an entire distributed net- work. This can be a powerful way to leverage investments in legacy systems with modern multitier architectures.

While it is commonplace for EJB applications to interface directly to a re- lational database back end, there is no requirement that such a system be the back end. IBM, for example, provides Java interfaces to their mainframe legacy data systems, such as CICS.


We’ve looked at the contents of an EAR file—not that you’ll need to be digging inside them or even building them by hand, but you’ll want to know what’s inside so as to understand what it takes to put one together. We took a look at


23.8 Resources 519

Ant and CVS and how they can be used together to make building and deployment easier. We even mentioned XDoclet, another tool worth knowing something about.


JBoss has an IDE plug-in for Eclipse which uses XDoclet to provide an integrat- ed development environment for writing EJBs. If you are working with Eclipse and are going to be doing a lot of EJB development, you should definitely explore this option.

The EJB 3.0 specification, due out within a year, promises to change all this, at least somewhat. With support for metadata in Java 1.5 there will be a standardized mechanism available for use in EJB class construction and deployment. Look for some significant improvements in usability.


• Visit http://geronimo.apache.org for the latest information on Geronimo.

• Visit http://www.jboss.org for the latest information on JBoss.

For more information about all the tags that can be put into the various XML configuration files, look at the DTD files which define them, for example:




XDoclet in Action by Craig Walls and Norman Richards (Manning Publi- cations, ISBN 1932394052) covers the Open Source XDoclet tool for automat- ing the generation of Java code and related files (e.g., deployment descriptors).