1. <dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
</dependency>
由于在pom文件中添加了上面的内容导致一个异常: 删除这个依赖之后, 问题就没有了
java.lang.ClassFormatError: Absent Codeattribute in method that is not native or abstract in class filejavax/servlet/ServletInputStream
atjava.lang.ClassLoader.defineClass1(Native Method)
atjava.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
atjava.lang.ClassLoader.defineClass(ClassLoader.java:616)
atjava.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
atjava.net.URLClassLoader.defineClass(URLClassLoader.java:283)
atjava.net.URLClassLoader.access$000(URLClassLoader.java:58)
atjava.net.URLClassLoader$1.run(URLClassLoader.java:197)
atjava.security.AccessController.doPrivileged(Native Method)
atjava.net.URLClassLoader.findClass(URLClassLoader.java:190)
atjava.lang.ClassLoader.loadClass(ClassLoader.java:307)
atsun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
atjava.lang.ClassLoader.loadClass(ClassLoader.java:248)
at
atorg.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240)
下面是我在网络找到的一篇分析这个异常的文章:
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:
<dependency> <groupId>javax</groupId> <artifactId>javaee-api</artifactId> <version>6.0</version></dependency>
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.
<dependency> <groupId>org.jboss.spec</groupId> <artifactId>jboss-javaee-6.0</artifactId> <version>1.0.0.Beta4</version> <type>pom</type> <scope>provided</scope></dependency>