Devbits

WebLogic Server introduced the concept of filtering class loader with release 9.2. Filtering class loader is used to filter class loading requests by application. It is configured using prefer-application-packages element in weblogic-application.xml. This configuration also modifies resource loading behavior to some extent. It has been explained in resource loading order section of the documentation.

With release 10.3.1, filtering class loader now supports a more fine grained control over resource loading behavior. A new element prefer-application-resources may be used to configure a resource pattern to filter. If this pattern is configured, any resource lookup whose URI matches the pattern will only be looked up in the application.

Consider an application flight.ear that has a jar file in it's APP-INF/lib directory and assume that this jar file contains META-INF/foo.xml. Further consider another jar file in the system class path that too has META-INF/foo.xml. If the application code uses ClassLoader.getResource(String) or ClassLoader.getResources(String) it'll see the resource from the system class path. But if the application were configured using prefer-application-resources element in weblogic-application.xml, the above resource lookup requests wouldn't find any resource from the system class path:

<prefer-application-resources>
  <resource-name>META-INF/foo.xml</resource-name>
</prefer-application-resources>

getResource with no filtering configuration
Resource from system class path

getResources with no filtering configuration
Resource from system class path
Resource from the application

getResource with above filtering configuration
Resource from application

getResources with above filtering configuration
Resource from application

Please note that resource-name element supports “*” wild card pattern. So we could have used something like “META-INF/*” as resource name as well.

In case the resource being looked up does not match the pattern configured using prefer-application-resources, the look up behavior reverts to the default resource loading behavior of filtering class loader, as described here. If prefer-application-packages is not declared, then resource loading behavior would revert to java default.

(Picture licensed from Roshnii under creative commons)

After a user issues a deployment command, the application is whisked away by the deployment sub-system across the cluster to the appropriate managed server for deployment. We have often been asked questions about the fate of application file beyond this point and most of these questions are the in context of security manager configuration. Here is a brief overview of temporary files that are used during deployment of applications.

After handling the staging, the deployment sub-system hands over the file to containers for deployment. The containers assume the file to be available on the same machine and deal with it accordingly.

Archived applications are exploded in a sever-specific temporary directory and only the temporary location is looked at by the class loader. Exploded application directories are not copied to temporary directory. So the class loader for such an application directly looks up the original location. If such an exploded application has some archived modules (say web module), then they are exploded in a temporary directory as described earlier.

Jar files need not be exploded and are directly used by the class loader. But, for Windows, they are copied to a temporary directory and the class loader looks up the jar from the temporary location. This special treatment is done for usability as it lets users overwrite jar files.