alma::acs::classloading::AcsSystemClassLoader Class Reference

Inheritance diagram for alma::acs::classloading::AcsSystemClassLoader:

Collaboration diagram for alma::acs::classloading::AcsSystemClassLoader:

Public Member Functions
	AcsSystemClassLoader (ClassLoader parent)
Static Public Attributes
static final String	PROPERTY_JARDIRS = "acs.system.classpath.jardirs"
static final String	PROPERTY_TOPJARSONLY = "acs.system.classpath.topjarsonly"
static final String	PROPERTY_CLASSLOADERVERBOSE = "acs.system.classloader.verbose"
Protected Member Functions
synchronized Class<?>	loadClass (String name, boolean resolve) throws ClassNotFoundException
Class<?>	findClass (String name) throws ClassNotFoundException
Private Member Functions
File[]	parseJarDirs (String jarDirPath)
void	prependCLASSPATHJars (List< File > jarFileList)
void	appendToClassPathForInstrumentation (String jarPathName)
Private Attributes
boolean	verbose
final JarOrderOptimizer	optimizer
final URLClassLoader	appClassLoader

Detailed Description

Custom class loader which correctly handles multiple occurences of identical jar files in "overlayed" directories. These directories would typically be ../lib, INTROOT/lib, ACSROOT/lib and ORB dirs.

The main purpose is to cut down the very long classpath produced otherwise by the ACS start scripts. Only the jar file that contains this class loader must be supplied to the JVM using the "-classpath" option. The JVM must be started with property definitions similar to:

-Djava.system.class.loader=alma.acs.classloading.AcsSystemClassLoader.
-Dacs.system.classpath.jardirs=../lib/:$INTROOT/lib:$ACSROOT/lib. If an operating system has a native style path separator different from "<code>:</code>", it can optionally be used instead.

Notes on the classloader hierarchies:

Don't confuse the inheritance hierarchy and the delegation hierarchy. Both this CL as well as its delegation-parent inherit from URLClassLoader.
This classloader is meant to be registered with the JVM using the property java.system.class.loader.
Instead of using the real system classloader (sun.misc.Launcher$AppClassLoader) as the parent, since ACS 6.0 this CL takes over the functionality of the direct parent, and uses the original grandparent CL for parent-delegation. Circumventing the original parent CL after copying its CLASSPATH entries, removes the distinction between the CLASSPATH entries and the jar files from the acs.system.classpath.jardirs directories.
- The effect is that we can add jar files to the CLASSPATH, which use classes from the normal pool of jar files. One use case for this is testing component implementation classes outside of containers: the jar files under ../lib/ACScomponents are not picked up by the classloader unless we add them to the CLASSPATH, e.g. using acsStartJava -addToClasspath.
- The CL hierarchy becomes (1) Bootstrap CL, (2) Extention CL, (3) AcsSystemClassLoader, [(4) optional component CL etc]
The method java.lang.ClassLoader#getSystemClassLoader() "tricks" the caller and returns this class loader, even though it thinks that the real system CL is our circumvented sibling, the sun.misc.Launcher$AppClassLoader. This allows JUnit tests run, since the JUnit framework sets up their own classloader to be a child of the system classloader, shortcutting any "regular" child class loaders in between.

Author:: hsommer created Sep 13, 2004 6:31:32 PM

Constructor & Destructor Documentation

alma::acs::classloading::AcsSystemClassLoader::AcsSystemClassLoader ( ClassLoader parent ) [inline]

Constructor will be called by the JVM. The standard system class loader (instance of sun.misc.Launcher$AppClassLoader is expected to be the parent parameter, although no such assumption is made in the code.

In the ctor, the directories given in acs.system.classpath.jardirs are searched for JAR files, which are fed as URLs into the classpath maintained by the URLClassLoader base class.

See also:: AcsJarFileFinder

References appClassLoader, alma::acs::makesupport::AcsFileFinder::getAllFiles(), optimizer, parseJarDirs(), prependCLASSPATHJars(), PROPERTY_CLASSLOADERVERBOSE, PROPERTY_JARDIRS, PROPERTY_TOPJARSONLY, and verbose.

Member Function Documentation

void alma::acs::classloading::AcsSystemClassLoader::appendToClassPathForInstrumentation ( String jarPathName ) [inline, private]

This method, even though private, allows jconsole and possibly similar profilers and other tools to add their required jar files, see java.lang.instrument.Instrumentation::appendToSystemClassLoaderSearch(java.util.jar.JarFile)}.

For example, jconsole would currently call this method with argument /usr/java/jdk1.6.0_02/jre/lib/management-agent.jar .

Since:: ACS 7.0

Class<?> alma::acs::classloading::AcsSystemClassLoader::findClass ( String name ) throws ClassNotFoundException [inline, protected]

Delegates to base class implementation.

Discards requests to load classes from certain sub-packages of sun. or com.sun. by throwing a ClassNotFoundException. The JDK libs try to search (e.g. during ACS container startup) for some optional system classes such as sun.text.resources.DateFormatZoneData_en_US or sun.util.logging.resources.logging_en. We know that ALMA jar files do not contain any classes in those packages, and can thus speed up the applications, in cases where those classes have already been searched unsuccessfully by any parent class loaders, which as the last step desparately would ask this class loader, which would cause a search through all jar files. sun.awt.resources. com.sun.swing.internal.plaf.

References alma::acs::classloading::JarOrderOptimizer::isClassKnownToBeUnavailable(), optimizer, and verbose.

Referenced by loadClass().

synchronized Class<?> alma::acs::classloading::AcsSystemClassLoader::loadClass	(	String	name,
		boolean	resolve
	)			throws ClassNotFoundException `[inline, protected]`

References findClass(), and verbose.

File [] alma::acs::classloading::AcsSystemClassLoader::parseJarDirs ( String jarDirPath ) [inline, private]

Referenced by AcsSystemClassLoader().

void alma::acs::classloading::AcsSystemClassLoader::prependCLASSPATHJars ( List< File > jarFileList ) [inline, private]

Extracts the CLASSPATH jar files (or directories) from the parent class loader and adds them at the beginning of the given list.

It is assumed that thanks to the java.system.class.loader property, this AcsSystemClassLoader is a direct child of the application system class loader which normally would handle the CLASSPATH.

References appClassLoader, and verbose.

Referenced by AcsSystemClassLoader().