A single EJB A home interface A remote interface An XML deployment descriptor in Java

Encoding Data Matrix ECC200 in Java A single EJB A home interface A remote interface An XML deployment descriptor

JBoss (jboss.org) isn t J2EE certified because it doesn't have access to the tests; HP Application Server (http: //www.hpmiddleware.com) is J2EE certified, but you don t get the source. Both seem good value for money.

Figure 14.1 Typical EJB scenario with home and remote interfaces accessed from the client through RMI

With the simplest possible EJB JAR file containing four pieces, the build process of a large EJB project can get quite complex. Luckily, there are Ant-based tools to make the job a bit easier. 14.1.3 Vendor-specific situations The cause of many headaches when using EJB is the vendor-specific nature of EJB deployment. Most application servers have their own specific additional deployment descriptors. Often vendor-specific processes, such as the generation of support classes, need to occur. For example, IBM WebSphere requires several metadata files: Schema.dbxmi, Map.mapxmi, ibm-ejb-jar-bnd.xmi, and ibm-ejb-jar-ext.xmi. Such vendor-specific files are often generated from vendor supplied tools, or can be built using XDoclet or other code-generation techniques.

The most rudimentary way to build an EJB JAR file is to create all the necessary Java code and a deployment descriptor yourself, compile the code, and then use the <jar> task to bundle it all. If your project has only one or a small number of fixed EJB JAR files, this is the best solution. It is simple, but it does not scale. Listing 14.1 provides an example.

<target name="compile" depends="init"> <javac destdir="${build.classes.dir}" debug="${build.debug}" srcdir="${src.dir}"> <classpath refid="compile.classpath"/> <include name="**/*.java"/> </javac> </target>

<target name="jar" depends="compile"> <jar destfile="${dist.dir}/${ejbjar.name}" basedir="${build.classes.dir}"> <metainf dir="metadata" includes="ejb-jar.xml"/> </jar> </target>

The code in listing 14.1 compiles all the Java source code and builds an EJB JAR file with the metadata/ejb-jar.xml file built into the META-INF directory. The main difference in the code shown here and the <jar> usage shown in section 6.3.2 is the inclusion of the deployment descriptor in the META-INF directory.

Ant includes a handful of EJB-related tasks, most of which are vendor specific. The vendor-specific tasks are now showing their age, though, and may not be applicable to the latest versions of the application servers. Check the Ant documentation for the specific version information. WebLogic WebLogic is the most well represented J2EE application server in terms of EJB tasks. The tasks include: <wlrun> and <wlstop> to start and stop the WebLogic server. You can use <wlrun> inside the <parallel> task in order to allow other tasks to execute against the running server. <ddcreator> to create ejb-jar.xml deployment descriptors from text-based descriptor files. <ejbc> to compile WebLogic-specific support classes including the RMI stubs and skeletons. This task is for an older version of WebLogic; it is more likely that the nested <weblogic> element of <ejbjar> would be used instead. <serverdeploy>, new in Ant 1.5, using a nested <weblogic> subelement, to hot-deploy an EAR, WAR, or JAR to WebLogic servers. iPlanet Application Server There is an <iplanet-ejbc> task to build the EJB stubs and skeletons for the iPlanet Application Server. The <ejbjar> task has a nested <iplanet> element that you should probably use instead. Borland Application Server Specific to the Borland Application Server, but needed in a more general sense, is the <blgenclient> task. It creates the client EJB JAR from the server EJB JAR file.

In projects where the use of EJB is more sophisticated than what the simple <jar> capabilities can handle, use <ejbjar>. The <ejbjar> task provides two services. It can introspect ejb-jar.xml-compliant files and build EJB JAR files with the classes specified and their dependencies. It also provides vendor-specific deployment build tools as nested elements inside the task. The <ejbjar> task scans a directory structure for deployment descriptors and uses the matched descriptors to build an EJB JAR for each deployment descriptor that it processes. This allows it to generate any number of EJB JAR files in one sweep as opposed to having to do them individually with their own <jar> tasks. Another great advantage of <ejbjar> is that it pulls in dependencies for the classes named in the deployment descriptors it processes. In particular, it automatically locates superclasses and incorporates them into the resultant JAR. There are many bells and whistles to the <ejbjar> task, but we only touch upon a few of them in the examples provided. The documentation provided with the Ant distribution is the best source for detailed information on the many attributes and options.