Introducing fine grained classloading in Micorcontainer's IoC, better aspect integration, new Chapter 9, VFS Configuration and Usage and Chapter 10, Deployers module projects, it was all set to also redo the whole classloding layer for the new Kernel and transitively JBoss5 application server. Whole new Classloder module was created to somehow fix the old API mistakes and to allow clean and plugable way for existing extensions of default classloading. This extensions range from old concepts of Servlet classloading, runtime AOP weaving, and all the way to new Chapter 13, OSGi module.

When designing new API for Classloading, we wanted to expose as little as possible. The concept there was to hide all the "nitty gritty" details and reduce the amount of API users need to apply in order to get required behaviour. When you were normally dealing with concrete ClassLoader classes, we reduced the implementation detail to only needing to implement your own ClassLoaderPolicy. This includes things like what packages you export, what you import, how to get resources and other things related to defining classes. We'll show the example of the policy later on.

Additionally, the idea of a LoaderRepository is replaced with a ClassLoaderDomain and a ClassLoaderSystem acting as a factory and a repository of domains. Each ClassLoaderSystem has a "default domain".

      ClassLoaderSystem system = ClassLoaderSystem.getInstance();

      // Define classloader policy
      MyClassLoaderPolicy myPolicy = ...

      // Register with the default domain,
      // there are other methods to create
      // and register with different domains
      ClassLoader cl = system.registerClassLoaderPolicy(myPolicy);
   

This is a simple example of what it falls down to, to create your own Classloader instance that will behave accordingly to the classloader policy.