Forum Discussion

DavidV's avatar
DavidV
New Contributor
9 years ago

Groovy version error with war file in ReadyAPI v1.3

I have been using ReadyAPI to generate a war file that includes a Script dispatch method. The war file is deployed as a service in tomcat 8.0.20.

 

In ReadyAPI v1.2.2, the war file works fine.

Using the war file generated in v1.3, whenever the script is invoked, I get an exception with the following error message:

"groovy-all is loaded in version 2.1.7 and you are trying to load version 2.4.1"

(See below for full exception trace from tomcat's localhost.log)

 

I am using the exact same soapui project file with both versions.

 

Is this a known issue? It looks like I need to update the version of groovy somewhere. Can you please assist?

 

05-May-2015 12:20:00.259 SEVERE [http-apr-10000-exec-4] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [SoapUIMockServlet] in context with path [] threw exception [Servlet execution threw an exception] with root cause
 groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-all is loaded in version 2.1.7 and you are trying to load version 2.4.1
	at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl$DefaultModuleListener.onModule(MetaClassRegistryImpl.java:509)
	at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanExtensionModuleFromProperties(ExtensionModuleScanner.java:78)
	at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanExtensionModuleFromMetaInf(ExtensionModuleScanner.java:72)
	at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanClasspathModules(ExtensionModuleScanner.java:54)
	at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:110)
	at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:71)
	at groovy.lang.GroovySystem.<clinit>(GroovySystem.java:33)
	at org.codehaus.groovy.runtime.InvokerHelper.<clinit>(InvokerHelper.java:62)
	at groovy.lang.GroovyObjectSupport.<init>(GroovyObjectSupport.java:32)
	at groovy.lang.Binding.<init>(Binding.java:33)
	at com.eviware.soapui.support.scripting.groovy.SoapUIGroovyScriptEngine.<init>(SoapUIGroovyScriptEngine.java:47)
	at com.eviware.soapui.support.scripting.groovy.GroovyScriptEngineFactory.createScriptEngine(GroovyScriptEngineFactory.java:38)
	at com.eviware.soapui.support.scripting.SoapUIScriptEngineRegistry.create(SoapUIScriptEngineRegistry.java:52)
	at com.eviware.soapui.support.scripting.ScriptEnginePool.getScriptEngine(ScriptEnginePool.java:60)
	at com.eviware.soapui.impl.wsdl.mock.dispatch.ScriptMockOperationDispatcher.selectMockResponse(ScriptMockOperationDispatcher.java:72)
	at com.eviware.soapui.impl.rest.mock.RestMockAction.dispatchRequest(RestMockAction.java:156)
	at com.eviware.soapui.impl.rest.mock.RestMockDispatcher.getMockResult(RestMockDispatcher.java:77)
	at com.eviware.soapui.impl.rest.mock.RestMockDispatcher.dispatchRequest(RestMockDispatcher.java:49)
	at com.eviware.soapui.impl.wsdl.mock.WsdlMockRunner.dispatchRequest(WsdlMockRunner.java:155)
	at com.eviware.soapui.mockaswar.MockAsWarServlet$MockServletSoapUICore.dispatchRequest(MockAsWarServlet.java:233)
	at com.eviware.soapui.mockaswar.MockAsWarServlet.service(MockAsWarServlet.java:168)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
	at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1086)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659)
	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:285)
	at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2439)
	at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2428)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.lang.Thread.run(Unknown Source)

4 Replies

  • 05ten's avatar
    05ten
    Contributor

    Hello! 

     

    I'm terribly sorry to hear you are having trouble with the 'exporting as war' feature in ReadyAPI 1.3. 

    An upgrade to Groovy has been long due in ReadyAPI and was made for 1.3 so it is expected that some trouble might appear. 

     

    We tried reproducing this with a _very_ spartan Rest Virt sporting a script dispatcher and performing some scripted operations on response and deployed two war files, side-by-side, to a tomcat7 and tomcat8. It seemed to work flawlessly and the virts were performing their respective operations, so the trouble you are encountering at least doesn't seem to be an entirely broken feature at least. 

     

    With that said, we'd very much like to track down what exactly is going on in your project. 

    To continue investigating this we'd need the complete stacktrace you got in your tomcat from the war-file and if possible your project-file alternatively a dummy-project where you have verified that the same problem occurs.

    Just attach them to your post. 

    • DavidV's avatar
      DavidV
      New Contributor

      Hi Osten,

       

      The good news is I am no longer able to reproduce the problem. I tried re-creating the war twice using 1.3 and it is running perfectly.

       

      Still, I have attached the full expection trace for reference, as suggested.

       

      From my point of view, this is resolved.

       

      Cheers,

      /David