Axis2 Class loading

Axis2 let users to deploy services and modules as separate archive files. These files can contain normal java classes or .jar files. Therefore at the deployment time Axis2 has to read those java classes and .jar files and create class loaders for services and modules. These are the places it looks for load those classes.
When axis2 deployed as web application using the axis2 war distribution, Axis2 uses the web application class loader (this contains WEB-INF/classes and WEB-INF/lib jars) as the top most parent.

For service deployment it creates a service class loader using jars under the services/lib (this folder has to create by the users if needed) folder and using web application class loader as the parent. Then for each service it creates a separate class loader (which contains archive class files and lib jar files) using the service class loader as the parent.

Similar thing happens for modules. The module class loader can uses the modules/lib folder to load the jar files and it use as the parent class loader for other modules. This forms the following parent child relationship for class loaders.

Web class loader
services class loader modules class loader
other service class loaders other service class loaders

Child First (parent last) class loading
By default Axis2 uses the parent first class loading. Child first class loading can be switch by setting EnableChildFirstClassLoading parameter.
<parameter name="EnableChildFirstClassLoading">true</parameter>

Thread Context class loading
Some libraries uses the Thread context class loading. By default axis2 sets the service class loader as the thread context class loader before invoking a service. This can be changed by setting the context class loader to composite.

I.e adding this parameter to service
<parameter name="ServiceTCCL">composite</parameter>

when this parameter is set it creates the context class loader by using both existing thread context class loader and service class loader.