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时，我立即收到错误。我们可以排除几秒钟后得到的Timeout错误。

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

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

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

在你的情况下，检查一下JBoss＆＃39; classloader允许你这样做：也许它可以让你微调它并优先于其他JAR之上的Mule JAR。或者，您需要构建一个async-http-client的分支，其中将使用Mule版本的HttpTransactionContext。您还可以在自己的项目中引入此类的Mule版本，该版本应优先于JAR中的版本。

当从JBoss发出http请求时，Mule会出错

1 个答案: