Architectural Considerations with Connectors and the Mule Container

You have advanced understanding of the architecture of the Mule ESB and the Mule container.

Mule uses classloaders to find and load classes for execution, so there’s no need to package most common dependencies of Mule connectors with your connector. However, when designing your connector you must plan to include compatible classes because your connector shares the classloader with Mule.

For example, if your connector uses CXF, you will need to take into account that Mule (as of version 3.4.1) employs CXF 2.5.9. Using the wrong class version will result in conflicts, such as Java NoSuchMethod exceptions.

Wherever possible, use DevKit-provided versions of any dependencies where there might be a conflict. If you prefer that Mule not automatically find and load classes, you can use the Classloader Override (the loader.override parameter) to override default classloading. You can also use this same parameter for class blocking (i.e. block the loading of a class so that class lookup is performed by the application and not by Mule).

For details on Mule class loading, including class overrides and blocking, see Classloader Control in Mule.