Mule在从JBoss发出http请求时出错

我有一个Mule流，它试图发出outboud 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>

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

---

类路径上似乎存在冲突版本的

异步http客户端

，或者更准确地说，类加载的

com.ning.http.client.providers.grizzly.HttpTransactionContext

版本不是Mule的http模块所期望的版本（因此已使用不同版本编译）

Mule

3.7

期望

1.9.21

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

编辑：感谢OP的评论，问题确实是由于Mule HTTP模块嵌入了不同版本的

HttpTransactionContext

。其中一个区别是将

getAsyncHandler

公开，以便可以从任何地方调用它（请参阅和）

这在Mule Standalone中起作用，因为：

lib/Mule

中的JAR优先于

lib/opt

。HTTP模块JAR位于前者，而

async HTTP client

位于后者。因此，

HttpTransactionContext

的预期版本被加载

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

---

在您的例子中，检查JBoss的类加载器允许您做什么：也许它可以允许您对它进行微调，并使Mule jar优先于其他jar。或者，您需要构建一个

asynchttpclient

分支，其中将使用

HttpTransactionContext

的Mule版本。您还可以在自己的项目中引入此类的Mule版本，该版本应优先于JARs中的版本。

JBoss7不包含

HttpTransactionContext

类。然而，我的项目有两个位置：1）async-http-client-1.9.27.jar和2）mule-module-http-3.7.2.jar。这两个类都在完全相同的包中。如果我试图从我的项目中排除异步http客户端，那么我会得到

java.lang.ClassNotFoundException:com.ning.http.client.AsyncHandler

exception。我不明白为什么Mule JAR包含来自其他公共库的类，同时对同一库具有Maven依赖性。In通过将HttpTransactionContext.java的源代码从Mule模块http复制到优先于WEB-INF/lib目录内容的src/main/java，进行了本地修复。这个问题已经被报告给了Mulesoft，它引出了一个问题：“Mulesoft的谁认为这是个好主意？”？显然是一个讨厌开发人员的人。如果有人在Heroku上遇到这个问题，我可以通过在procfile中首先强制加载mule module http-{version}.jar来解决它，如下所示：web:java-cp target/dependency/mule-module-http-3.8.0.jar:target/dependency/*：target/classes:target/lib/*{Launcher Class}{Port}我知道这是2016年的问题，但我对CE 3.8.1有同样的问题，我无法解决：c

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]