Classloader Control in Mule

Mule defines a hierarchy of classloaders to find and load classes for execution. This hierarchy uses a "parent first" model by default, this means that each classloader will attempt to load a class using his parent classloader before attempted to do it itself.

Although this classloading architecture meets most classloading needs, there are times when you might need to override the default classloading scheme. For example, suppose an application requires a third-party library that is bundled with it. This might conflict with a library version that the domain classloader would load (that is, a version of the library already bundled with Mule). How do you ensure that the required version of the library is used with the application? To address requirements such as these, Mule supports fine-grained class loading control that enables you to override default classloading.

The classloader hierarchy for the different artifacts consists of:

The Mule classloader order is illustrated in the following diagram:

Mule EE provides a plugin framework to add plugins at Mule server level.

When a Mule EE server contains Mule Plugins, the classloading model is a bit different than the previously described hierarchy. The main difference is that applications can access resources exported by Mule Plugins.

To support that scenario, each Mule plugin has a classloader supportingfine grain classloading. These classloaders are created using the Mule system classloader as the parent. Mule Plugins can contain many classes, libraries and resources, but only some of them should be accessed from the application. To avoid exporting unnecessary resources, from a Mule plugin, a class loader filter is used. Then the classloader used in the Mule Application will be a Composite ClassLoader that contains a list of classloaders. The first classloader in that list will be a Mule Application classloader as the one described before and the following elements will be the classloaders filters for each installed Mule Plugin.