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工作室以及作为独立的Java应用程序运行Mule时可以使用。但是，当我将它作为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 classloader以避免为你的Mule应用程序提供这个类的不兼容版本。

编辑：感谢OP的评论，问题的确是由于Mule HTTP Module嵌入了不同版本的HttpTransactionContext。其中一个差异是关于使公众getAsyncHandler公开，所以可以从任何地方调用它（参见original和Mule's fork）。

由于the way Mule loads classes with its system classloader，这适用于骡子独立：优先给予lib/mule的JAR优于lib/opt。 HTTP模块JAR位于前者中，而async-http-client位于后者中。因此预期版本的HttpTransactionContext被加载。

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

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