# Classloader module

Introducing fine grained classloading in Micorcontainer's IoC, better aspect integration, new vfs and deployers projects, it was all set to also redo the whole classloding layer for the new Kernel and transitively JBoss5 application server. A whole new Classloder module was created to somehow fix the old API mistakes and to allow a clean and plugable way for existing extensions of default classloading. These extensions range from old concepts of Servlet classloading, runtime AOP weaving, and all the way to new osgi.

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 the 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 comes down to, to create your own Classloader instance that will behave accordingly to the classloader policy.