Understanding Classloader

Classes in a Java virtual machine are constrained to the scope of their class loader environment. A class loader can spawn multiple child class loaders, in effect this will create a class loader
hierarchy. There are two basic rules:

1. The class visibility rule: a child class loader can "see" up the hierarchy, just like children can use their parent's money, but not the other way around. This is known as the "Visibility Contstraints" rule.
2. The class resolving rule: a child class loader will ask the parent class loader to load a particular class. Only when the parent' can't, then the child will attempt to load the needed class. This is known as "Delegate Load Request" rule.

A class loader can have siblings, but can't share classes that are loaded. Usage of such a shared class will result in

ClassCastException.

So the challenging is how to share a class across siblings given the above constraints. First we must understand the class loader boundaries and then use a strategy that works within these boundaries:

1. System level class loader: load J2SE and J2EE classes
2. EAR level: load every jar and war file in an enterprise application. Classes loaded at this level can access one another.
3. WAR level: load classes from /WEB-INF/classes and WEB-INF/lib directory. Classes at this level can access classes at EAR and System level.