Mule 从 JBoss 发出 http 请求时出错

Question

我有一个 Mule 流，它试图发出出站 HTTP 请求。

    <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>

这适用于 Mule 工作室以及将 Mule 作为独立 Java 应用程序运行时。但是，当我将它作为 webapp 带到 JBoss7 时，我会立即收到错误消息。我们可以排除几秒钟后我得到的超时错误。

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] 

有谁知道这是否是一个已知问题？我可以看到其他人在 MuleSoft 论坛上发布了相同的问题，但没有任何回应

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

Answer 1

看起来类路径上的 async-http-client 版本存在冲突，或者更准确地说，已被类加载的 com.ning.http.client.providers.grizzly.HttpTransactionContext 版本不是 Mule 的 HTTP 模块所期望的版本（因此已使用不同的版本）。

Mule 3.7 期望 1.9.21：您的 Mule 应用程序中打包了不同的版本吗？还是 JBoss 在父类加载器中加载不同的版本？如果是前者，请检查您的应用程序的 POM 以确保打包正确的版本，如果是后者，请配置 JBoss 类加载器以避免向您的 Mule 应用程序提供此类的不兼容版本。

编辑：感谢 OP 的评论，问题确实是由于 Mule HTTP 模块嵌入了不同版本的HttpTransactionContext。不同之处之一是将getAsyncHandler 设为公开，以便可以从任何地方调用它（请参阅original 和Mule's fork）。

这在 Mule Standalone 中有效，因为 the way Mule loads classes with its system classloader：lib/mule 中的 JAR 优先于 lib/opt。 HTTP 模块 JAR 在前者中，而 async-http-client 在后者中。因此，HttpTransactionContext 的预期版本被加载。

这真的很不幸，因为它使得在 Mule Standalone 之外运行 Mule 应用程序非常困难，如果不是不可能的话。

在您的情况下，检查 JBoss 的类加载器允许您做什么：也许它可以让您对其进行微调，并将 Mule JAR 优先于其他 JAR。或者，您需要构建 async-http-client 的分支，其中将使用 HttpTransactionContext 的 Mule 版本。你也可以在你自己的项目中引入这个类的 Mule 版本，它应该优先于 JAR 中的版本。