Tech

20130213

Managing The CLASSPATH

The classpath in java and during Runtime, searches for classes and other zip type resources files to load into JVM memory to make the program run. classpath simply maps locations of classes to be use (load) as needed during application's life cycle; There's different ways of setting a java classpath:

  • Use the -classpath or -cp to set your classpath;
  • Use environment commands to set the classpath;
  • Using the class-path tag, on the application's manifest;

Examples:
  1. sdktool -[classpath,cp] class1[;|:]class2
    * ';' is use for Windows, ':' Unix like. sdktool is java, javac, jhat, etc..
  2. set classpath="class1;class2"

You can only add the following file types '.jar', '.zip' or '.class' into a classpath; Directories or the wildcard '*' can be used to add resources that eventually will be mapped during runtime. Compress files like '.jar' and '.zip' must contains '.class' files, other wise will be ignored.
While using the wildcard '*', the order of files loaded to the JVM vary from platform to platform and also from moment to moment on the same HW machine. Supposedly a well build application does not actually depend on a particular order, but if needed you must explicitly order files into the classpath. In which reads from left to write, and the first file is the one that will be use in case of similar jars with same full class name.
Classpath also can be set on the application's Manifest, using the class-path tag, but this tag does not honour the wildcard. While setting directories, java will load files in the order they appear in the path variables;

WLS

Uses delegation model when loading class, and to improve performance do the following steps:
  1. Checks its class load cache (to improve performance);
  2. While loading, search for the parent class; therefore goes reading from top to bottom on the family tree of the class, in case does not find the parent it does not attempt to load the class;
  3. If both child and parent exist, the parent is loaded first;

Weblogic comes with some feature such as hot-deployment and hot-redeployment. Allows to deploy and changes to newer versions of application module while server is running state, in which helps on avoiding downtime. On the java classloather do not support any standard for hot-deployment nor hot-redeployment; In this case you would need to restart the entire server in case of adding new libs or modifying your application.
Each application deployed on Weblogic Server has a separate hierarchy of classloaders from the system classloader; Also with the bool prefer-web-inf-classes child of container-descriptor tag on the weblogic.xml allow applications to use different libs, base on versioning details description. This is very useful when installing thirdparty libs or upgrading them, by default this tag is set to false.
Ex:
<?xml version="1.0" encoding="UTF-8"?>

<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">
  <container-descriptor>
    <prefer-web-inf-classes>true</prefer-web-inf-classes>
    <prefer-application-packages>
      <package-name>javax.faces.*</package-name>
      <package-name>com.sun.faces.*</package-name>
      <package-name>com.bea.faces.*</package-name>
    </prefer-application-packages>

    <prefer-application-resources>
      <resource-name>javax.faces.*</resource-name>
      <resource-name>com.sun.faces.*</resource-name>
      <resource-name>com.bea.faces.*</resource-name>
      <resource-name>META-INF/services/javax.servlet.ServletContainerInitializer</resource-name>
      </prefer-application-resources>
  </container-descriptor>
</weblogic-web-app>


  As you may notice you need to inform which packages or resource to be loaded, therefore we use the list prefer-application-packages and prefer-application-resources tags; There is no need to use both at the same time.   ref: