ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Using Ant and WebLogic EJBs

by Jesse E. Tilly
06/25/2001

EJBs are complex in both design and implementation. The steps required just to deploy them for the numerous application servers make matters worse. However, for developers using BEA's WebLogic family of application servers, life is made easier thanks to Ant.

Ant is an open-source tool for building Java-based applications and is a part of the Apache Jakarta project. Using XML as a build description language, Ant groups build results into targets with finite resolution states; a target fails or succeeds. We, the developer or build manager, define the build properties, the tasks needed to build targets, and the dependencies between those targets in the antfile. For more information, an overview of Ant, written by David Thomson, is available on the ONJava.com site.

The developers of Ant provide a set of tasks that can build deployable EJBs that are useable in WebLogic 4.5, 5.1, and 6.0, and can also create generic EJB bundles for processing in other application servers. When properly set up, a project's antfile, using the <ejbjar> task and <weblogic> element, can build hundreds of EJBs, defined by the same five to eight lines of XML.

This article covers builds of EJBs for WebLogic 5.1. However, developers and build managers working with other application servers can take heart that the design used to create these EJB and WebLogic tasks is extensible. These users should remain alert for the next Ant release (1.4), which will include supported EJB tasks for iPlanet, Borland Application Server and jBoss. Unsupported forms of these are available either in some nightly builds of Ant's optional tasks or from other developers. Curious users are encouraged to search the Ant-user mailing lists for messages pertaining to EJBs and iPlanet, etc. From there, they can find the module that meets their needs.

This article is divided into four parts. The first part describes how to configure a project for use with the <ejbjar> task and <weblogic> element. The second part shows an example of how to build series of EJBs for a project. The third part teaches you how to write a target that builds only one EJB. Finally, the fourth part covers some of the more useful optional functions, as well as some tips and tricks.


O'Reilly Open Source Convention

Learn more about Java open source projects during the Java sesssions at the O'Reilly Open Source Convention in San Diego, CA, July 23-27, 2001. Rub elbows with open source leaders while relaxing on the beautiful Sheraton San Diego Hotel and Marina waterfront. For more information, visit our conference home page.


 

Comment on this articleWhat are your experiences with Ant and WebLogic Application Server EJBs?
Post your comments

Ant's requirements cause conflicts with other EJB toolsets, since they may have naming conventions of their own. This article provides solutions to some of the known conflicts. However, the more of these tools a development shop uses, the higher the likelihood of having an unresolved conflict. Read the Ant documentation for more details of how Ant works with IDEs.

Naming Schemes

WebLogic EJB developers that want to use Ant need to jump through a few hoops to get the full power of the <ejbjar> task. The actual amount of antfile code involved is small, maybe about seven or eight lines (not including property configurations, etc.). Developers just beginning their projects will have the easiest time; those developers who are months, or even years, into a project may find incorporating Ant to be a more daunting task. For the latter unlucky folks, this article is meant to be enlightening enough to have them reconsider their project configurations and possibly refactor them. Even if it their project will not be using Ant, a well designed project configuration helps everyone in the long run.

Due to the precedent set by EJB examples and books (notably Monson-Haefel's EJB books), it is fairly common for developers to use the following convention when naming classes and Java modules:

  • Implementation -- <Bean Name>Bean.java
  • Home interface -- <Bean Name>Home.java
  • Remote interface -- <Bean Name>Java
  • Primary key -- <Bean Name>PK.java

Because of these same examples, it is not common to find the deployment descriptors following any naming convention or proper organization. Partly, this is because of the constraints that the containers place on descriptor names, but this can be solved with scripts or smart EJB building programs. Ant's EJB tasks require some good organizational guidelines for all of the EJB files. Without some standard organization, EJB projects become troublesome to maintain as, over time, descriptors become scattered throughout the file system. Ant's scheme provides structure to the typically structureless aspect of many Java projects.

To begin, here is the set of project organization rules <ejbjar> uses:

All EJB classes should follow the de-facto class naming standard, using the bean name prefix.
While technically possible with the flexibility of the descriptor files, the EJB implementation class, for example, should not be named IThumbMyNoseAtNamingConventions.java. <Bean Name>Bean.java, while boring, works best.

All EJB descriptors should follow the class naming convention, using the bean name prefix before the descriptor type.
This descriptor convention is not as demanding as it may sound. All descriptors start with the <Bean Name> (e.g. Account-ejb-jar.xml). In the WebLogic deployment descriptor, the CMP descriptor is explicitly named. This does not need to be changed. Only the filename on the file system must follow the convention. We visit the potential conflicts of such a naming convention in the "work-around' section.

Descriptors get their own directory, per bean, using the bean name.
This rule is not as much of a requirement as the first two, but it makes life easier over the long haul.

These rules are not requirements.
Large and complex applications may have special needs unsatisfied by the task's current level of functionality or other needs that are satisfied but not covered in this article. For these projects, the naming schemes and project layout may not apply. Any project can be built using <ejbjar> with enough effort; using the rules makes <ejbjar> easier.

The Layout

Project layout is important for effective code and build management. Creating modular file-system organizations makes for easy bundling or removal of code. Java's packaging system is an example of this design concept. Concept diagrams during project whiteboarding sessions benefit from good layout. Managing the code in CVS or any other version control system is made easier.

External benefits aside, without conventions, the <ejbjar> task becomes like any other Ant task. The projects that closely follow the rules require the least amount of antfile code. Straying from the rules, the antfile writer may have to describe and define how to build each EJB. With conventions applied, the <ejbjar> task becomes quite powerful, with only little work.

The following is an example project layout:

bigproject/
  Java/
      ...
          com/duffbrew/Account.java
          com/duffbrew/AccountHome.java
          com/duffbrew/AccountBean.java
                 descriptor/
             ...
                 Account/
                   Account-ejb-jar.xml
                   Account-weblogic-ejb-jar.xml
                   Account-weblogic-cmp-rdbms-jar.xml
          build/
            ...
                deploy/
                   Account/
                      Account.jar
          doc/
          lib/

The project structure follows all the rules mentioned. The Account EJB code modules are named appropriately. The descriptor files are in their own directory, and they too share the code-module naming scheme.

Pages: 1, 2

Next Pagearrow