alma.acs.classloading.AcsSystemClassLoader Class Reference

Inherits java::net::URLClassLoader.

List of all members.

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

---

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

)

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 alma.acs.makesupport.AcsFileFinder.getAllFiles(), alma.acs.classloading.AcsSystemClassLoader.PROPERTY_CLASSLOADERVERBOSE, alma.acs.classloading.AcsSystemClassLoader.PROPERTY_JARDIRS, and alma.acs.classloading.AcsSystemClassLoader.PROPERTY_TOPJARSONLY.

---

Member Function Documentation

Class<?> alma.acs.classloading.AcsSystemClassLoader.findClass

(

String

name

)

throws ClassNotFoundException [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().

Referenced by alma.acs.classloading.AcsSystemClassLoader.loadClass().

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

References alma.acs.classloading.AcsSystemClassLoader.findClass().

---

Member Data Documentation

final String alma.acs.classloading.AcsSystemClassLoader.PROPERTY_CLASSLOADERVERBOSE = "acs.system.classloader.verbose" [static]

Referenced by alma.acs.classloading.AcsSystemClassLoader.AcsSystemClassLoader().

final String alma.acs.classloading.AcsSystemClassLoader.PROPERTY_JARDIRS = "acs.system.classpath.jardirs" [static]

Referenced by alma.acs.classloading.AcsSystemClassLoader.AcsSystemClassLoader().

final String alma.acs.classloading.AcsSystemClassLoader.PROPERTY_TOPJARSONLY = "acs.system.classpath.topjarsonly" [static]

Referenced by alma.acs.classloading.AcsSystemClassLoader.AcsSystemClassLoader().

---

The documentation for this class was generated from the following file:

• AcsSystemClassLoader.java