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

advertisement

AddThis Social Bookmark Button EJB 2

EJB 2 and J2EE Packaging

06/26/2001

Have you noticed the number of different types of JAR files that you have to deal with lately in J2EE?! JAR files do not just hold EJBs anymore. Rather, JAR files are being used to store utility classes, web applications, enterprise applications, and Java Connector Architecture (JCA) resource adapters. Additionally, in some scenarios, some JAR files are composed of other JAR files.

Now that most major application servers are supporting dynamic class (un)loading with custom classloaders, what are the issues J2EE developers face when working with all of these packaging technologies? This article discusses some of the nuances associated with J2EE packaging and provides some hints to make you more productive.

The First Issue: EAR Support for Limited Components

Currently, the J2EE 1.3 specification defines an enterprise application packaging unit to be a JAR file with an .ear extension. EAR files can contain one or more:

  • EJB modules (.jar extension)
  • Web application modules (.war extension)
  • JCA resource adapter modules (.rar extension)
  • Application client modules (.jar extension)

Since most web-based J2EE applications are composed of web and EJB applications, the EAR file meets the basic requirements for packaging an application. However, it is lacking in capability for packaging complicated J2EE applications. For example, the following components are often used in a J2EE application, but cannot be declared in an EAR file:

  • Some JMS consumers that run within an application server, such as a MessageConsumer that runs as part of a ServerSession
  • JDBC DataSource objects
  • JMS ConnectionFactory and Destination objects
  • JMX MBeans
  • Startup and shutdown classes (admittedly, a propriety extension provided by vendors, but generally unilaterally supplied by all vendors)

Currently, all of these components of an application have to be manually configured and deployed through a vendor's administration interface. As the usage of the items listed above increases over time, it will become more important for EAR files to natively support packaging of these components to achieve true J2EE application portability.

The Second Issue: Utility and Support Classes

Comment on this articleGive your questions to Tyler Jewell.
Post your comments

Also in EJB 2:

Unlocking the True Power of Entity EJBs

Stateful Session EJBs: Beasts of Burden

EJB 2 and J2EE Packaging, Part II

EJB 2.0 Specification Release Review

Sorting Out the EJB 2.0 Rumors

The most frequent question raised about J2EE packaging is in regards to utility and support classes. When packaging a web application or an EJB application, where should you place these libraries?! If you place these classes into the standard CLASSPATH of your application server, they will likely lose any unloading ability that Web/EJB applications have that are driven by special classloaders used to load them at deployment. If your Web/EJB applications need to change the version of the libraries that they use, then the dependent library will need to be re-deployed when the Web/EJB application is re-deployed. In this scenario, storing utility classes on the standard CLASSPATH is not a feasible option, since the entire application server would have to be restarted for each deployment of a Web/EJB application. (Yuck!)

Given the standard definition of J2EE, where are you supposed to place libraries so that they can be re-deployed with an application at runtime? I've seen some creative, yet undesirable, solutions:

  • Utility classes and JAR files can be placed in the WEB-INF\lib directory of a Web application. Generally, the WEB-INF\lib directory should primarily be used for the storage of servlet classes, but servlets/JSPs will look for classes in this directory when loading new ones. If the utility library that you are using is only needed by your servlets/JSPs, then this solution will meet all of your needs. However, if the same libraries are also needed by your EJBs, JMS consumers, or startup/shutdown classes, then this option will not work since the WEB-INF\lib directory is not visible to these items.

  • A complete copy of all of the utility libraries is placed in each EJB JAR file in addition to the WEB-INF\lib directory. When an EJB is deployed, an EJB classloader will only look within its own JAR file for any utility classes that are referenced. It will not look within the JAR files of other EJB applications that have been deployed or in the WEB-INF\lib directory. If all of your EJB applications require the use of the same library, then placing a copy of each of that library's classes in each JAR file will meet your needs. The utility classes will be re-deployable along with the EJB.

The second solution is admittedly gross:

  • The purpose of having multiple JAR files for packaging is to promote modularity of applications. Placing the same class in multiple JAR files destroys modularity.
  • Your applications will be unnecessarily bloated in the byte size of your classes.
  • You will have an added build hassle, since every JAR file will have to be rebuilt if you want to change a single library.

Pages: 1, 2

Next Pagearrow