java.lang.Object
java.lang.ClassLoader
java.security.SecureClassLoader
java.net.URLClassLoader
com.simscomputing.testbed.FileSystemClassLoader
- public class FileSystemClassLoader
- extends java.net.URLClassLoader
This class is almost a trivial subclass of URLClassLoader.
The one thing that I'm baffled by is that if I overload loadClass(),
then newly loaded classes have their class loader set to this class.
If I don't, then new classes have their class loader set to the
primordial class loader.
I've no idea why this behaves this way. I've tested it under Linux JDK 1.2
and Windows JDK 1.3 beta.
I need newly loaded classes to have their class loader set to
FileSystemClassLoader so that can be reloaded when the user clicks
"Re-Exercise".
Why not just find the class file in the file system and call
defineClass() like almost all other custom class loaders do? Because
it gets real tricky when you're trying to load classes from signed jar
files and the like. I figured that since URLClassLoader has already
gone to all the trouble to do these things for me, why not use it?
The only downside so far is that classes loaded from the CLASSPATH,
and not the TestClassPath, have their class loader set to the
primordial one, which means they can't be re-exercised properly. This
is why we have the concept of the TestClassPath.
But even with this problem, the benefits outweigh the drawbacks. I get
to reuse a lot of JDK code which works properly even under tricky
security situations.
Please let me know if you have some insight into this
situation. david@simscomputing.com
- Version:
- $Revision: 1.1.1.1 $ $Date: 2000/02/21 21:22:33 $
| Nested classes inherited from class java.lang.ClassLoader |
|
| Methods inherited from class java.lang.ClassLoader |
clearAssertionStatus, defineClass, defineClass, defineClass, defineClass, definePackage, findLibrary, findLoadedClass, findSystemClass, getPackage, getPackages, getParent, getResource, getResourceAsStream, getResources, getSystemClassLoader, getSystemResource, getSystemResourceAsStream, getSystemResources, loadClass, resolveClass, setClassAssertionStatus, setDefaultAssertionStatus, setPackageAssertionStatus, setSigners |
classPath
private java.lang.String classPath
storageUnits
private java.util.ArrayList storageUnits
debug
private boolean debug
exemptClassLoader
private java.lang.ClassLoader exemptClassLoader
exemptPackagePrefixList
private java.util.ArrayList exemptPackagePrefixList
second
private boolean second
FileSystemClassLoader
public FileSystemClassLoader(java.net.URL[] urls,
java.lang.ClassLoader exemptClassLoader)
loadClass
public java.lang.Class loadClass(java.io.File file)
throws java.lang.ClassNotFoundException
toString
public java.lang.String toString()
- Description copied from class:
java.net.URLClassLoader
- Returns a String representation of this URLClassLoader giving the
actual Class name, the URLs that are searched and the parent
ClassLoader.
loadClass
public java.lang.Class loadClass(java.lang.String name,
boolean resolve)
throws java.lang.ClassNotFoundException
- According the JDK source, loadClass is supposed to be declared as synchronzied.
For reasons unknown, if this method is commented out, all classes loaded by
this class loader will have their class loader set to primordial class loader,
NOT this class (FileSystemClassLoader).