Understanding WebLogic Server Application Classloading 8-13
8.2.10 Configuring a FilteringClassLoader
To configure the FilteringClassLoader to specify that a certain package is loaded from an application, add a prefer-application-packages descriptor element to
weblogic-application.xml which details the list of packages to be loaded from the application. The following example specifies that org.apache.log4j. and
antlr. packages are loaded from the application, not the system classloader:
prefer-application-packages package-nameorg.apache.log4j.package-name
package-nameantlr.package-name prefer-application-packages
For aid in configuring filtering classloaders, see Section 8.4, Using the Classloader
Analysis Tool CAT.
8.2.11 Resource Loading Order
The resource loading order is the order in which java.lang.ClassLoader methods getResourceand getResources return resources. When filtering is enabled,
this order is slightly different from the case when filtering is disabled. Filtering is enabled implies that there are one or more package patterns in the
FilteringClassLoader. Without any filtering default, the resources are collected in the top-down order of the classloader tree. For instance, if Web 1 requests
resources, the resources are grouped in the following order: Sys 3, App 2 and Web1. See
Example 8–7 .
Example 8–7 Using the System Classloader
System 3 |
App 2 |
Web 1
To be more explicit, given a resource META-INFfoo.xml which exists in all the classloaders, would return the following list of URLs:
META-INFfoo.xml - from the System ClassLoader 3 META-INFfoo.xml - from the App ClassLoader 2
META-INFfoo.xml - from the Web ClassLoader 1
When filtering is enabled, the resources from the child of the FilteringClassLoader an application classloader down to the calling classloader
are returned before the ones from the system classloader. In Example 8–8
, if the same resource existed in all the classloaders D, B and A one would get them in the
following order if requested by the Web classloader: META-INFfoo.xml - from the App ClassLoader B
META-INFfoo.xml - from the Web ClassLoader A META-INFfoo.xml - from the System ClassLoader D
Note: The resources are returned in the default Java EE delegation model
beneath the FilteringClassLoader. Only the resources from the parent of the FilteringClassLoader are appended to the end of the enumeration
being returned.
8-14 Developing Applications for Oracle WebLogic Server
Example 8–8 Using a Filtering Classloading Implementation
System D |
FilteringClassLoader filterList := x.y. C |
App B |
Web A
If the application classloader requested the same resource, the following order would be obtained.
META-INFfoo.xml - from the App ClassLoader B META-INFfoo.xml - from the System ClassLoader D
For getResource, only the first descriptor is returned and getResourceAsStream returns the inputStream of the first resource.
8.3 Resolving Class References Between Modules and Applications
Your applications may use many different Java classes, including Enterprise Beans, servlets and JavaServer Pages, utility classes, and third-party packages. WebLogic
Server deploys applications in separate classloaders to maintain independence and to facilitate dynamic redeployment and undeployment. Because of this, you need to
package your application classes in such a way that each module has access to the classes it depends on. In some cases, you may have to include a set of classes in more
than one application or module. This section describes how WebLogic Server uses multiple classloaders so that you can stage your applications successfully.
For more information about analyzing and resolving classloading issues, see Section 8.4, Using the Classloader Analysis Tool CAT.
8.3.1 About Resource Adapter Classes
Each resource adapter now uses its own classloader to load classes similar to Web applications. As a result, modules like Web applications and EJBs that are packaged
along with a resource adapter in an application archive EAR file do not have visibility into the resource adapters classes. If such visibility is required, you must
place the resource adapter classes in APP-INFclasses. You can also archive these classes using the JAR utility and place them in the APP-INFlib of the application
archive.
Make sure that no resource-adapter specific classes exist in your WebLogic Server system classpath. If you need to use resource adapter-specific classes with Web
modules for example, an EJB or Web application, you must bundle these classes in the corresponding modules archive file for example, the JAR file for EJBs or the WAR
file for Web applications.
8.3.2 Packaging Shared Utility Classes
WebLogic Server provides a location within an EAR file where you can store shared utility classes. Place utility JAR files in the APP-INFlib directory and individual
classes in the APP-INFclasses directory. Do not place JAR files in the classes directory or classes in the lib directory. These classes are loaded into the root
classloader for the application.
This feature obviates the need to place utility classes in the system classpath or place classes in an EJB JAR file which depends on the standard WebLogic Server classloader
Kategori