As we know, Mule is a java-based platform. And external java package might be needed for a mule project. For latest Anypoint Studio with runtime v3.6.2, there are two packages are included in the system level:
httpcore-4.3.5.jar and httpclient-4.2.jar

In my MuleSoft development project with maven, I need to send out http request via groovy script which will need some classes in htttpclient and httpcore. The problem is that the classes in httpclient(4.3.5) need to work with classe org.apache.http.util.Args coming from httpcore with the version over 4.3.

To solve this, the http packages with the higher version would be added as dependencies in pom.xml. In my project, I choose the version 4.4, and httpclient-4.4.jar and httpcore-4.4.jar are imported. Actually, you can choose to use any version after 4.2.

Then MuleSoft developers need to let Mule know that certain packages must be loaded from child path(the imported packages) other than from the system level (included by Mule).
A simple setting in mule-deploy.properties would be inserted:

loader.override=-org.apache.http

Two questions might be raised:
1. Why not just import httpcore (over 4.3) and override the specific class like the following:
loader.override=-org.apache.http.util.Args
2. Why to import two packages (httpclient and httpcore)

The truth is that when only the class Args is overridden, Mule would still call the classes from httpclient from the system level and it will search the references at the same level. So we need to import both httpclient and httpcore with the same version, and all the classes from those two packages would be overridden. In this way, all the classes would come from the child path.

The control of the class loader introduces a new way to solve the conflict between different versions of packages in Mule.

Read Next
Top 5 Browser Add-Ons for Quality Assurance

Top 5 Browser Add-Ons for Quality Assurance

09 September, 2015|3 min