I'm looking at packaging jmock 2.5.1. Package is here:
http://www.cora.nwra.com/~orion/fedora/jmock-2.5.1-1.fc15.src.rpm
Build log:
http://www.cora.nwra.com/~orion/fedora/rpmbuild.log
Error is during the tests:
[junit] Testcase: testCanMockTypesFromADynamicClassLoader(org.jmock.test.unit.lib.JavaReflectionImposteriserTests): Caused an ERROR [junit] Invalid superclass index 0 in class file $UniqueTypeName$ [junit] java.lang.ClassFormatError: Invalid superclass index 0 in class file $UniqueTypeName$ [junit] at java.lang.ClassLoader.defineClass1(Native Method) [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:634) [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:480) [junit] at org.jmock.test.unit.support.SyntheticEmptyInterfaceClassLoader.synthesiseInterface(SyntheticEmptyInterfaceClassLoader.java:43) [junit] at org.jmock.test.unit.support.SyntheticEmptyInterfaceClassLoader.findClass(SyntheticEmptyInterfaceClassLoader.java:25) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:321) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:266) [junit] at org.jmock.test.unit.lib.JavaReflectionImposteriserTests.testCanMockTypesFromADynamicClassLoader(JavaReflectionImposteriserTests.java:38)
I have no idea about this. I've applied two patches. One to use objectweb classes directly rather than from cglib, and one derived from the 2.6.0-RC2 release to support java 1.6.
Any help would be appreciated.
On 08:49:36 AM Wednesday, May 11, 2011 Orion Poplawski wrote:
I'm looking at packaging jmock 2.5.1. Package is here:
http://www.cora.nwra.com/~orion/fedora/jmock-2.5.1-1.fc15.src.rpm
Build log:
http://www.cora.nwra.com/~orion/fedora/rpmbuild.log
Error is during the tests:
[junit] Testcase:
testCanMockTypesFromADynamicClassLoader(org.jmock.test.unit.lib.JavaReflect ionImposteriserTests): Caused an ERROR [junit] Invalid superclass index 0 in class file $UniqueTypeName$ [junit] java.lang.ClassFormatError: Invalid superclass index 0 in class file $UniqueTypeName$ [junit] at java.lang.ClassLoader.defineClass1(Native Method) [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:634) [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:480) [junit] at org.jmock.test.unit.support.SyntheticEmptyInterfaceClassLoader.synthesiseIn terface(SyntheticEmptyInterfaceClassLoader.java:43) [junit] at org.jmock.test.unit.support.SyntheticEmptyInterfaceClassLoader.findClass(Sy ntheticEmptyInterfaceClassLoader.java:25) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:321) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:266) [junit] at org.jmock.test.unit.lib.JavaReflectionImposteriserTests.testCanMockTypesFro mADynamicClassLoader(JavaReflectionImposteriserTests.java:38)
I have no idea about this. I've applied two patches. One to use objectweb classes directly rather than from cglib, and one derived from the 2.6.0-RC2 release to support java 1.6.
It looks like the given test case doesn't support the class format used. Could it be that your java 1.6 patch missed some test cases? As jmock hasn't been in Fedora before I would have chosen 2.6.0-RC2 if it is supposed to handle java 1.6 classes
Alex
Any help would be appreciated.
On 08:49:36 AM Wednesday, May 11, 2011 Orion Poplawski wrote:
Error is during the tests:
[junit] Testcase: testCanMockTypesFromADynamicClassLoader(org.jmock.test.unit.lib.JavaReflect ionImposteriserTests): Caused an ERROR [junit] Invalid superclass index 0 in class file $UniqueTypeName$ [junit] java.lang.ClassFormatError: Invalid superclass index 0 in class file $UniqueTypeName$ [junit] at java.lang.ClassLoader.defineClass1(Native Method) [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:634) [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:480) [junit] at org.jmock.test.unit.support.SyntheticEmptyInterfaceClassLoader.synthesiseIn terface(SyntheticEmptyInterfaceClassLoader.java:43) [junit] at org.jmock.test.unit.support.SyntheticEmptyInterfaceClassLoader.findClass(Sy ntheticEmptyInterfaceClassLoader.java:25) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:321) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:266) [junit] at org.jmock.test.unit.lib.JavaReflectionImposteriserTests.testCanMockTypesFro mADynamicClassLoader(JavaReflectionImposteriserTests.java:38)
I have no idea about this. I've applied two patches. One to use objectweb classes directly rather than from cglib, and one derived from the 2.6.0-RC2 release to support java 1.6.
I think the problem depends on the version of asm you are using; the error is thrown on a call to a cglib method which your patch reroutes directly to asm.
On 05/11/2011 06:00 AM, Guido Grazioli wrote:
On 08:49:36 AM Wednesday, May 11, 2011 Orion Poplawski wrote:
Error is during the tests:
[junit] Testcase:
testCanMockTypesFromADynamicClassLoader(org.jmock.test.unit.lib.JavaReflect ionImposteriserTests): Caused an ERROR [junit] Invalid superclass index 0 in class file $UniqueTypeName$ [junit] java.lang.ClassFormatError: Invalid superclass index 0 in class file $UniqueTypeName$ [junit] at java.lang.ClassLoader.defineClass1(Native Method) [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:634) [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:480) [junit] at org.jmock.test.unit.support.SyntheticEmptyInterfaceClassLoader.synthesiseIn terface(SyntheticEmptyInterfaceClassLoader.java:43) [junit] at org.jmock.test.unit.support.SyntheticEmptyInterfaceClassLoader.findClass(Sy ntheticEmptyInterfaceClassLoader.java:25) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:321) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:266) [junit] at org.jmock.test.unit.lib.JavaReflectionImposteriserTests.testCanMockTypesFro mADynamicClassLoader(JavaReflectionImposteriserTests.java:38)
I have no idea about this. I've applied two patches. One to use objectweb classes directly rather than from cglib, and one derived from the 2.6.0-RC2 release to support java 1.6.
I think the problem depends on the version of asm you are using; the error is thrown on a call to a cglib method which your patch reroutes directly to asm.
Probably. It appears that cglib out in the wild simply rebundles asm (via jarjar I think). On Fedora it dosn't, hence the need to use the original objectweb-asm namespace. 2.5.1 use cglib 2.1_3. F15 has cglib 2.2.
java-devel@lists.fedoraproject.org