In this chapter we've looked at packagingJ2EE apps and the issues involved in deploying apps to an app server. We've seen that the most complex issues in app packaging relate to class loading when we use EJB. J2EE servers use multiple class loaders. Many app servers use a separate class loader for EJBs and web app classes, meaning that we may face problems with classes used in both EJB JARs and WARs. Differences in class loading behavior between app servers mean that deployment units are not always portable. We've examined class loading behavior as defined by J2SE and the J2EE specifications. We've also considered class loading behavior in several app servers. We've seen several practical options for app packaging, and concluded that the best approach is usually to use the J2SE 1.3 manifest classpath mechanism to enable JAR-format files such as EJB JAR files to declare dependencies on other, library, JAR files. We've illustrated this by looking at the packaging of the sample app, and how the infrastructure classes discussed in previous chapters can be packaged into four JAR files referenced by app deployment units. We've also looked at the server configuration required to underpin any J2EE deployment, such as the definition of RDBMS data sources and JMS destinations. We've seen how we typically need proprietary, server-specific deployment descriptors to map resources referenced in the standard deployment descriptors onto resources defined in server configuration. Finally, we've taken a practical look at deployment through the process of deploying the sample app on JBoss 3.0. We've seen how the Ant build tool can be used to automate and simplify all aspects of app packaging and deployment.


The J2EE Deployment API Specification ( may make app deployment more consistent between app servers, but does not address packaging issues or standardize the definition of resources such as DataSources.