[Unit Testing Framework] Exception when trying to run the Unit Testing Framework

[Unit Testing Framework] Exception when trying to run the Unit Testing Framework

  
Forge Component
(21)
Published on 5 Apr by Paulo Ramos
21 votes
Published on 5 Apr by Paulo Ramos
First many thanks for providing this UT framework! Necessary & useful!

We are trying your UT component (Java stack), but it did not detect the test we prepared.
When drilling down (debugger) it appeared that a Java exception "Illegal type in constant pool" is thrown during detection of unit tests to run.

When googling on this type of error, it seems a JVM issue which micht be related to different Java versions (runtime Java version vs. compiler Java version); see http://bugs.java.com/view_bug.do?bug_id=8037385; other sites also link this exception to compiler / JVM issues on running a provided .class file (rather than compiling a .java file yourself).
  • Do we need a specific Java version?
  • Or could this be solved when the java class is compiled with another compiler?
  • Or can we get the original java code so that we can compile it in our own environment?
Below an excerpt of the stack trace; attached the complete error page.

Thanks in advance for your help, we would really like to use this framework.

(class: org/codehaus/groovy/runtime/ArrayUtil, method: createArray signature: ()[Ljava/lang/Object;) Illegal type in constant pool
java.lang.VerifyError: (class: org/codehaus/groovy/runtime/ArrayUtil, method: createArray signature: ()[Ljava/lang/Object;) Illegal type in constant pool
   at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
   at com.predic8.soamodel.AbstractParser.<init>(AbstractParser.groovy:25)
   at com.predic8.wsdl.WSDLParser.<init>(WSDLParser.groovy)
   at outsystems.nosutf_integration.actions.ActScanWsdlForUnitTestMethods.mosScanWsdlForUnitTestMethods(Unknown Source)
Hi Jan,

I've just fresh installed on a server running the Platform Version 9.0.1.4 and which has Java 1.6.0_45-b06 and could successfully scan and run the tests.

I'm not aware of any restriction on the java version but I only tested it on 1.6.0 and with JBOSS 7.1.1.

The libary is not SOA Model open source (http://www.membrane-soa.org/downloads/) so it is not possible to recompile on your version.

Whats your java version and jboss version?

Cheers,
Guilherme
Hi Guilherme,
We have left this issue for a while, but now we are retrying again, but without success.

We have exactly the same Java version (1.6.0_45-b06), and the same JBoss version (7.1.1).
OutSystems platform is 9.0.1.15.

We have tried to install groovy (.jar) as this was mentioned in the error message, but this didn't help.

In your answer you mention http://www.membrane-soa.org/downloads, I suppose you use one of the 3 Membrane products in the Unit Test Framewerk? Probably the Membrane Service Proxy?
What is the reason you mention this URL?

Regards, Jan-Hendrik
Hi Jan,

The UTF ues the Membrane SOA Model - Java API for WSDL and XML Schema.
The reason I mentioned it is because you asked for the code so you can contact the provider of the library and see if they can help you get the code for you to compile with your own configuration.

Thanks
Guilherme
Hi Guilherme, thanks for your quick reply.
As we use the exact same Java versions, this does not seem to be the clue. I am diving in the error message again, and found quite a number of posts with this issue, but most without solution.

Anyhow, it seems to be either a compiler / low level byte code issue, or a wrong Class type parameter in a call to Reflection-like stuff.
I will ask my die-hard Java colleagues if they have any idea to work around this, and let you know of course.
My expert Java colleague suggests that the groovy runtime was compiled for a Java version that is incompatible with our Java runtime.
So we might try to download the groovy runtime java code (instead of using the .class) and compile that in our environment.
Yet he could not explain why it did not hit this error in your environment with exactly the same Java version.

If we are actually going to do this (not sure yet), I will inform you whether this cured the problem.