Mule gives error when making http request from JBo

Question

I have a Mule flow which is trying to make outboud HTTP request.

    <http:request config-ref="APP_OUT" path="#[message.inboundProperties.'http.request.path']" method="#[message.inboundProperties.'http.method']" doc:name="OUT"  sendBodyMode="ALWAYS" parseResponse="false"  followRedirects="false">
        <http:request-builder>
            <http:header headerName="HOST" value="#[message.inboundProperties.'host']"/>
        </http:request-builder>
    </http:request>

This works from Mule studio as well as when running Mule as a standalone Java application. However, when I take this to JBoss7 as webapp, I get error immediately. We can rule out the Timeout errors which I get after few seconds.

16:56:27,393 SEVERE [org.glassfish.grizzly.nio.SelectorRunner] ([myapp].http.requester.APP_OUT(1) SelectorRunner) doSelect exception: java.lang.IllegalAccessError: tried to access method com.ning.http.client.providers.grizzly.HttpTransactionContext.getAsyncHandler()Lcom/ning/http/client/AsyncHandler; from class org.mule.module.http.internal.request.grizzly.FlowWorkManagerIOStrategy
    at org.mule.module.http.internal.request.grizzly.FlowWorkManagerIOStrategy.getWorkManager(FlowWorkManagerIOStrategy.java:119) [mule-module-http-3.7.2.jar:3.7.2]
    at org.mule.module.http.internal.request.grizzly.FlowWorkManagerIOStrategy.getThreadPoolFor(FlowWorkManagerIOStrategy.java:90) [mule-module-http-3.7.2.jar:3.7.2]
    at org.mule.module.http.internal.request.grizzly.FlowWorkManagerIOStrategy.executeIoEvent(FlowWorkManagerIOStrategy.java:69) [mule-module-http-3.7.2.jar:3.7.2]
    at org.glassfish.grizzly.strategies.AbstractIOStrategy.executeIoEvent(AbstractIOStrategy.java:89) [grizzly-framework-2.3.21.jar:2.3.21]
    at org.glassfish.grizzly.nio.SelectorRunner.iterateKeyEvents(SelectorRunner.java:414) [grizzly-framework-2.3.21.jar:2.3.21]
    at org.glassfish.grizzly.nio.SelectorRunner.iterateKeys(SelectorRunner.java:383) [grizzly-framework-2.3.21.jar:2.3.21]
    at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:347) [grizzly-framework-2.3.21.jar:2.3.21]
    at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278) [grizzly-framework-2.3.21.jar:2.3.21]
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591) [grizzly-framework-2.3.21.jar:2.3.21]
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571) [grizzly-framework-2.3.21.jar:2.3.21]
    at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67] 

Does anyone know if this is a known issue? I can see someone else has posted same question on MuleSoft forum with no response

http://forums.mulesoft.com/questions/30322/mule-372-issue-when-using-httprequest-and-running-1.html

Answer 1

It looks like there are conflicting versions of async-http-client on the classpath, or more precisely that the version of com.ning.http.client.providers.grizzly.HttpTransactionContext that has been class-loaded is not version expected by Mule's HTTP Module (which has thus been compiled with a different version).

Mule 3.7 expects 1.9.21: do you have a different version packaged in your Mule application? Or does JBoss load in a parent classloader a different version? If the former, review your app's POM to make sure the proper version gets packaged, if the latter, configure JBoss classloader to avoid providing an incompatible version of this class to your Mule application.

EDIT: Thanks to the OP's comment, the problem is indeed due to the fact the Mule HTTP Module embeds a different version of HttpTransactionContext. One of the difference is about making getAsyncHandler public so it can be called from anywhere (see original and Mule's fork).

This works in Mule Standalone because of the way Mule loads classes with its system classloader: precedence is given to JARs in lib/mule over lib/opt. The HTTP Module JAR is in the former while async-http-client is in the latter. Thus the expected version of HttpTransactionContext gets loaded.

This is really unfortunate as it makes running Mule applications outside of Mule Standalone very difficult, if not impossible.

In your case, check what JBoss' classloader allows you to do: maybe it can allow you to fine tune it and give precedence to the Mule JARs above the other JARs. Alternatively, you'd need to build a fork of async-http-client where the Mule version of HttpTransactionContext would be used instead. You could also bring the Mule version of this class in your own project, which should take precedence over the versions in JARs.