javaee 6 与junit冲突 - weijiguang/OA GitHub Wiki
以”java.lang.ClassFormatError: Absent Code attribute in method”为关键字检索，最终找到一篇文章，说是J2ee6 api包和Junit冲突。很是怪异。解决办法是使用J2ee5或者在pom中删掉J2ee6 api包的依赖声明。作者给出的原因分析是转自国外以网站的，如下：
What’s the cause of this exception:java.lang.ClassFormatError: Absent Code?
版本 6
创建于:2010-3-21 上午12:57作者 Dan Allen - 最后修改: 2010-6-11 上午10:46 作者 Dan Allen
When running a test suite that includes Arquillian test cases,you may be encountering the following exception:
java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file [Fully-qualified class name] at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:621) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
This problem is likely the result of having the javax:javeee-api(or javax:javaee-web-api) library on your test classpath. If you have a Mavenproject, you likely have the following dependency in your POM file:
javax javaee-api 6.0
This dependency provides you with the Java EE APIs, not theimplementations. While this dependency works for compiling, it cannot be usedfor executing code (that includes tests).
Background
When these artifacts were published to the Maven repository, Sunstripped out the code from classes that are classified as”implementations”. So all the interfaces are code complete, yet anyabstract class or implementation class has no code in it. Any attempt to usethat class will likely blow up. That’s why Arquillian is failing.
Here’s an excerpt from the argument as to why Sun did this:
When one compiles, they want to run as well. By the way, we havebeen promoting full set of Java EE APIs which can only be used for compilation- they are stripped off method details. That way, user can’t take thoseartifacts and try to use it in runtime.
The workaround is to not use javax.javaee-api but rather use theindividual, “real” artifacts that you need. Unfortunately, there isno Maven scope available that will exclude a dependency from the testclasspath.
There are two solutions to this problem.
Solution #1: Maven profiles
If you writing tests for an embedded Java EE container, then thecontainer is going to be on your test classpath. That container will have allthe APIs you need to compile. Therefore, you use the Java EE API for yourdefault profile, but then replace it with the target container JAR in theprofile you are using to run the tests. You can see an example of this setup inthe JUnit or TestNG Arquilian example POMs.
Solution #2: JBoss Java EE Spec Artifact
The other solution, which actually applies in both cases, is touse the Java EE spec artifact provided by JBoss, which does not reference anystripped classes.
org.jboss.spec
jboss-javaee-6.0
1.0.0.Beta4
pom
provided