Understanding WebLogic Server Application Classloading 8-5
8.2.1 Overview of WebLogic Server Application Classloading
WebLogic Server classloading is centered on the concept of an application. An application is normally packaged in an Enterprise Archive EAR file containing
application classes. Everything within an EAR file is considered part of the same application. The following may be part of an EAR or can be loaded as standalone
applications:
■
An Enterprise JavaBean EJB JAR file
■
A Web application WAR file
■
A resource adapter RAR file
If you deploy an EJB and a Web application separately, they are considered two applications. If they are deployed together within an EAR file, they are one
application. You deploy modules together in an EAR file for them to be considered part of the same application.
Every application receives its own classloader hierarchy; the parent of this hierarchy is the system classpath classloader. This isolates applications so that application A
cannot see the classloaders or classes of application B. In hierarchy classloaders, no sibling or friend concepts exist. Application code only has visibility to classes loaded
by the classloader associated with the application or module and classes that are loaded by classloaders that are ancestors of the application or module classloader.
This allows WebLogic Server to host multiple isolated applications within the same JVM.
8.2.2 Application Classloader Hierarchy
WebLogic Server automatically creates a hierarchy of classloaders when an application is deployed. The root classloader in this hierarchy loads any EJB JAR files in the
application. A child classloader is created for each Web application WAR file.
Because it is common for Web applications to call EJBs, the WebLogic Server application classloader architecture allows JavaServer Page JSP files and servlets to
see the EJB interfaces in their parent classloader. This architecture also allows Web applications to be redeployed without redeploying the EJB tier. In practice, it is more
common to change JSP files and servlets than to change the EJB tier.
The following graphic illustrates this WebLogic Server application classloading concept.
Note: See the following sections for more information:
■
For information on Resource Adapters and classloading, see Section 8.3.1,
About Resource Adapter Classes .
■
For information on overriding generic application files while classloading, see Generic File Loading Overrides in Deploying Applications to Oracle
WebLogic Server.
8-6 Developing Applications for Oracle WebLogic Server
Figure 8–1 WebLogic Server Classloading
If your application includes servlets and JSPs that use EJBs:
■
Package the servlets and JSPs in a WAR file
■
Package the Enterprise JavaBeans in an EJB JAR file
■
Package the WAR and JAR files in an EAR file
■
Deploy the EAR file Although you could deploy the WAR and JAR files separately, deploying them
together in an EAR file produces a classloader arrangement that allows the servlets and JSPs to find the EJB classes. If you deploy the WAR and JAR files separately,
WebLogic Server creates sibling classloaders for them. This means that you must include the EJB home and remote interfaces in the WAR file, and WebLogic Server
must use the RMI stub and skeleton classes for EJB calls, just as it does when EJB clients and implementation classes are in different JVMs. This concept is discussed in
more detail in the next section
Section 8.2.7, Application Classloading and Pass-by-Value or Reference
.
8.2.3 Custom Module Classloader Hierarchies
Kategori