当从JBoss发出http请求时，Mule给出了错误 [英] Mule gives error when making http request from JBoss

问题描述

我有一个Mule流正在尝试发出outboud HTTP请求.

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>

这在Mule Studio以及作为独立Java应用程序运行Mule时均可使用.但是，当我以webapp的形式将它带到JBoss7时，我立即收到错误消息.我们可以排除几秒钟后收到的超时错误.

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] 

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

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

推荐答案

看来类路径上的async-http-client版本有冲突，或者更确切地说，已经加载了类的com.ning.http.client.providers.grizzly.HttpTransactionContext版本没有Mule的HTTP模块期望的版本(因此已经使用其他版本进行了编译).

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预期为1.9.21:您的Mule应用程序中打包了其他版本吗?还是JBoss在父类加载器中加载了其他版本?如果是前者，请检查应用程序的POM以确保打包了正确的版本；如果是后者，则配置JBoss类加载器，以避免为您的Mule应用程序提供此类的不兼容版本.

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.

编辑:由于OP的评论，该问题确实是由于Mule HTTP模块嵌入了HttpTransactionContext的其他版本而引起的.区别之一是使getAsyncHandler公开，因此可以在任何地方调用它(请参见

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

由于 Mule使用其系统类加载器加载类的方式:与lib/opt相比，lib/mule中的JAR优先级更高. HTTP模块JAR位于前者中，而async-http-client位于后者中.因此，将加载HttpTransactionContext的预期版本.

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.

这真的很不幸，因为这使Mule Standalone之外的Mule应用程序运行非常困难，即使不是不可能.

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

在您的情况下，请检查JBoss的类加载器允许您执行的操作:也许可以让您对其进行微调，并将Mule JAR优先于其他JAR.或者，您需要构建async-http-client的fork，在其中将使用HttpTransactionContext的Mule版本.您也可以将此类的Mule版本带入您自己的项目中，该版本应优先于JAR中的版本.

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.

这篇关于当从JBoss发出http请求时，Mule给出了错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！