Enterprise Application Projects

1. Enterprise Application Project Model

MyEclipse provides an Enterprise Application project model, i.e., EAR project model, and management tools for the creation of Java EE enterprise applications. An EAR project, identified by the  icon, is a logical container of Web, Application Client, Connector, and EJB projects, which results in a single, server-side deployment unit known as a Java EE Enterprise Archive (EAR). No subprojects are physically located within an EAR project’s folder structure, but rather the EAR project maintains references to its component modules.

The Java EE Specification defines the runtime structure of an enterprise application as a collection of Java EE modules and basic file resources required by the modules.

The most common types of Java EE modules are:

• Web module – typically represented as a Web Archive (WAR)
• EJB module – typically represented as an EJB JAR archive

An EAR project must include at least one module project. Therefore, during EAR project development, module projects can be added and removed as needed as long as one module project is included. When deploying an enterprise project, referenced module projects are packaged in their respective archive forms and deployed as modules of the enterprise archive.

Typically a web module provides web user-interface services and user access to the business services provided by one or more EJB modules. The Java EE specification defines the EAR as THE standard Java EE deployment unit. Additionally, the Specification allows for, but does not require, application server vendors to support other deployment forms such as stand-alone WAR and EJB JARs.

MyEclipse project model architecture

The MyEclipse project model parallels the Java EE Enterprise Application model in the following manner:

• MyEclipse Web Module project – Design-time equivalent of a Java EE Web module. A Web Module project is identical to a basic MyEclipse Web project with the addition of internal metadata and optional project dependencies.
• MyEclipse EJB Module project –  Design-time equivalent of a Java EE EJB module. An EJB Module project is identical to a basic MyEclipse EJB project with the addition of internal metadata and optional project dependencies.
• MyEclipse Enterprise project – Design-time equivalent of a Java EE enterprise application. Does not contain any Web or EJB project code, but rather maintains associations to module projects.

All EAR projects using JavaEE version less than 5.0 are created with a META-INF root folder and an empty META-INF/application.xml deployment descriptor. For projects using Java EE 5 or higher, this file is not required and you have the option to have this file generated for you. You can modify the application.xml file as needed.

Note: For Java EE versions requiring the application.xml file, do not move or rename this file or the META-INF folder. Doing so results in deployment failures. All resources other than the project’s meta-data files are considered part of the deployment.

MyEclipse perspective view of an Enterprise Application project

The image below depicts the Resource perspective view of a MyEclipse web project. This view reveals deployment information for the project. Project deployment can be customized using the project’s Deployment Assembly property. See MyEclipse Deployment Assembly for more information.

Resource perspective view of an Enterprise Application project

2. Project Organization, Dependencies, and Class Resolution

The Java EE Specification defines a hierarchical Java class resolution strategy for enterprise applications. This bottom-up search strategy is depicted in in the illustration below. When any module references a Java class, its local classloader first searches that module’s code base for the class. If the class is not found local to the module, then the module makes a search request to the classloader at the next level above it. This process continues until either the class is found or the top-level Java boot classloader is reached (not shown in the illustration).

Classloader hierarchy

It’s important to understand the Java EE enterprise application classloader strategy: The classloading strategy affects how you choose to distribute classes between web and EJB module projects. For example, if you have one or more business data objects that are passed between the user-interface elements of a web module and the services of an EJB module, by locating the data objects in the EJB module, they become visible to both the web module and the EJB module.

Two common project organization mistakes that cause classloading problems are:

• Placing data object classes in the web module which results in runtime ClassNotFoundExceptions
• Copying shared classes to both web and EJB module projects. The approach typically results in hard to diagnose serialization and class incompatibility related errors, which makes the practice even more difficult than the first point.

MyEclipse Java EE projects emulate this hierarchical classloader strategy to provide you accurate build-time insight into the classloader visibility of your MyEclipse Enterprise project and its constituent Web and EJB module projects. This is accomplished using Eclipse project dependencies as shown in the illustration below. When a web or EJB project is added to a MyEclipse EAR project, the project dependencies are set accordingly. Do not manually modify these project dependencies. Doing so will likely introduce unnecessary compilation problems.

Note: The MyEclipse development team felt it was a paramount requirement that the classloader emulation be supported to help developers identify hard to resolve runtime errors caused by classloader visibility problems. This is one of the reasons why MyEclipse does not support physical embedding of module code within an EAR project. Instead, an EAR project maintains associations to individual web and EJB projects as modules.

Project dependencies to emulate Java EE EAR classloader behaviors