application server's /lib directory. These are all the libraries the application server is re-
quired to provide—libraries such as the Java EE API itself.
The EAR module class loader is extended from the application server class loader. This
class loader loads the classes that are deployed at an EAR level. By default, they're the
classes packaged inside JARs in the /lib directory of the EAR, but the default /lib directory
can be overridden by the library-directory element in the application.xml deploy-
The EJB class loader is extended from the EAR module. Even though an EAR may contain
multiple EJB-JAR modules, there's typically only a single EJB class loader that loads all
the EJB-JAR modules. Finally, the WAR class loader is extended from the EJB class load-
er. By extending the EJB class loader, the WAR gains access to all EJBs deployed as part
of the EAR. Each WAR will get its own class loader.
This gives you an idea of how EE servers typically implement class loading for their Enter-
prise applications. Why EE servers use this implementation is driven by the EE standards
for the visibility and sharing of classes between different modules within an EAR. We'll
look at these standards next.
13.2.3. Dependencies between Java EE modules
The Java EE specification defines the requirements for the visibility of classes for each EE
module. For example, the specification defines what classes are visible to a WAR module
but doesn't define how the EE server class loaders provide that visibility. We have an ex-
planation in section 13.2.2 of how EE servers typically implement class loaders.
Suppose listing 13.2 describes what is deployed to your EE server. We'll use the example
EE server deployment of this listing to explore the most common requirements for the vis-
ibility of classes for the EJB-JAR and WAR modules. For more visibility requirements, or
visibility requirements of other modules, refer to the Java EE platform specification.