|ClassLoaders in Java operate on a parent-child scheme, which is analogous to Object Oriented concepts as follows:
Children "inherit" from their parents, but parents cannot use the functionality of their childen.
At the top is the JVM's own default, basic System Classloader, which looks in various places for classes.
Places such as:
The JVM's main classpath as defined by the
The JVM's boot classpath, JARs in it's extensions folder, or JARs in its endorsed folder.
These are specified by the following JVM system properties (respectively):
sun.boot.class.path (C:\j2sdk1.4.2_04\jre\lib\rt.jar;C:\j2sdk1.4.2_04\jre\lib\i18n.jar;... for example)
java.ext.dirs (C:\j2sdk1.4.2_04\jre\lib\ext for example)
java.endorsed.dirs (C:\j2sdk1.4.2_04\jre\lib\endorsed for example)
Code that's loaded into the JVM by the System classloader can be written to create it's own custom classloader(s),
which can be written to look for class files in other places.
This is what SE does to support Java Servlet Web Applications and JSPs running inside those web applications.
Here is a graphic representation of Classloaders in SE:
System Classloader (provided by the JVM)
app app classloader
JSP JSP classloader
Each webapp gets its own custom application classloader which will be used to find classes in the following order:
If the custom application classloader still can't find the class, it will ask its parent classloader
(i.e. the Java System Classloader) to find the class.
.class files in WEB-INF/classes
.jar files in WEB-INF/lib
Any classes that reside in any external libraries that have been setup for the webapp
Each webapp also gets its own custom JSP classloader which will be used to find classes in that webapp's pagecompile folder.
A child classloader can ask it's parent to find (and thus load) a class, but the reverse is not true.
If you have a class 'b' that is visible to a higher-level classloader, and that class implements or extends some other class 'a', then class 'a' must also be visible to that higher-level classloader.
Otherwise the JVM won't be able to load class 'b', because when it tries to do so, it will see that 'b' extends or implements 'a' and won't be able to find 'a'.
You'd likely get a NoClassDefFoundError which mentions class 'a'.
Class 'a' would need to be visible to the same classloader as is class 'b' (or visible to a higher-level classloader).
Example: placing a Servlet class file (which neccessarily extends javax.servlet.http.HttpServlet) into the JVM's extension folder, but not placing servlet.jar (which contains javax.servlet.http.HttpServlet.class) there as well.