8-12 Developing Applications for Oracle WebLogic Server
WebLogic Server includes an optimization to improve the performance of Remote Method Interface RMI calls within the server. Rather than using pass by value and
the RMI subsystems marshalling and unmarshalling facilities, the server makes a direct Java method call using pass by reference. This mechanism greatly improves
performance and is also used for EJB 2.0 local interfaces.
RMI call optimization and call by reference can only be used when the caller and callee are within the same application. As usual, this is related to classloaders. Because
applications have their own classloader hierarchy, any application class has a definition in both classloaders and receives a ClassCastException error if you try to
assign between applications. To work around this, WebLogic Server uses call-by-value between applications, even if they are within the same JVM.
8.2.8 Using a Filtering Classloader
In WebLogic Server, any JAR file present in the system classpath is loaded by the WebLogic Server system classloader. All applications running within a server instance
are loaded in application classloaders which are children of the system classloader. In this implementation of the system classloader, applications cannot use different
versions of third-party JARs which are already present in the system classloader. Every child classloader asks the parent the system classloader for a particular class and
cannot load classes which are seen by the parent.
For example, if a class called com.foo.Baz exists in both CLASSPATH as well as the application EAR, then the class from the CLASSPATH is loaded and not the one from
the EAR. Since weblogic.jar is in the CLASSPATH, applications can not override any WebLogic Server classes.
The following sections define and describe how to use a filtering classloader:
■
Section 8.2.9, What is a Filtering ClassLoader
■
Section 8.2.10, Configuring a FilteringClassLoader
■
Section 8.2.11, Resource Loading Order
8.2.9 What is a Filtering ClassLoader
The FilteringClassLoader provides a mechanism for you to configure deployment descriptors to explicitly specify that certain packages should always be
loaded from the application, rather than being loaded by the system classloader. This allows you to use alternate versions of applications such as Xerces and Ant. Though
the FilteringClassLoader lets you bundle and use 3rd party JARs in your application, it is not recommended that you filter out API classes, like classes in javax
packages or weblogic packages.
The FilteringClassLoader sits between the application classloader and the system classloader. It is a child of the system classloader and the parent of the
application classloader. The FilteringClassLoader intercepts the loadClassString className method and compares the className with a list
of packages specified in weblogic-application.xml file. If the package matches the className, the FilteringClassLoader throws a
ClassNotFoundException. This exception notifies the application classloader to load this class from the application.
Note: Calls between applications are slower than calls within the same
application. Deploy modules together as an EAR file to enable fast RMI calls and use of the EJB 2.0 local interfaces.
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
