Converting spring-web-mvc testcase for annotation-based config?

After a very lengthy thread that departed from the original subject, I've decided to post my latest question in a new thread.

I've got a servlet-3.0-style webapp running in Resin 4.0.33 with absolutely no XML configuration files. The last thing I need to address is my use of spring-web-mvc, wherein my test class was declared like this:

Code:

---

@RunWith(org.springframework.test.context.junit4.SpringJUnit4ClassRunner.class)
@WebAppConfiguration("file:target/build")
@ContextConfiguration({
    "file:target/build/WEB-INF/config/springContext.xml",
    "file:target/build/WEB-INF/config/springWebDispatcherConfig.xml"
})
public
class
TestServiceController
{
    ...testcases...
}

---

Since web.xml no longer exists under target/build/WEB-INF and since springContext.xml and springWebDispatcherConfig.xml no longer exist, I need to make some changes. I've tried a few things but can't seem to get them right.

My webapp config depends on the container automatically instantiating my AbstractAnnotationConfigDispatcherServletInitializ er, which then handles registering my @Configuration classes. I tried referencing those in the @ContextConfiguration(classes={}) annotation, but that didn't work. I also can't tell if @WebAppConfiguration knows how to initialize a servlet-3.0 webapp.

Google has been less than forthcoming with this; I guess not many people are using servlet 3.0 yet. Any help would be most welcome. Thanks!

Oh, I may have spoken too soon. I just found an example. I'll post again if I can't figure it out from there.

spring-test-mvc/src/test/java/org/springframework/test/web/servlet/samples/context/JavaConfigTests.java

I tried changing my test class declaration to this:

Code:

---

@RunWith(org.springframework.test.context.junit4.SpringJUnit4ClassRunner.class)
@WebAppConfiguration("file:target/build")
@ContextConfiguration(classes={com.foo.bar.web.WebappInitializer.WebConfig.class})
public
class
TestServiceController
{
    ...test cases...
}

---

But when I run, I get this:

Code:

---

    [junit] java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/servlet/ServletException
    [junit]        at java.lang.ClassLoader.defineClass1(Native Method)
    ...
    [junit]        at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.determineCandidateConstructors(AutowiredAnnotationBeanPostProcessor.java:230)
    ...
    [junit]        at org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:148)
    [junit]        at org.springframework.test.context.web.ServletTestExecutionListener.setUpRequestContextIfNecessary(ServletTestExecutionListener.java:105)

---

My guess is that you are using the following dependency

Code:

---

<dependency>
        <groupId>javax</groupId>
        <artifactId>javaee-api</artifactId>
        <version>6.0</version>
        <scope>provided</scope>
</dependency>

---

This jar is only usable for compilation as it is only the API it contains nothing more (not sure how they managed to create such a crappy jar file but alas).

Use the glassfish or jboss one instead..

JBoss

Code:

---

<dependency>
        <groupId>org.jboss.spec</groupId>
        <artifactId>jboss-javaee-6.0</artifactId>
        <version>3.0.1.Final</version>
        <scope>provided</scope>
</dependency>

---

Glassfish

Code:

---

        <dependency>
            <groupId>org.glassfish.extras</groupId>
            <artifactId>glassfish-embedded-all</artifactId>
            <version>3.1.1</version>
            <scope>provided</scope>
        </dependency>

---

Thanks, Marten. I'm using ant to build (with the maven ant task), and yes, I'm using that dependency. I'm not using JBoss or Glassfish, but rather Resin. It runs fine.

The problem is with the Spring-test-mvc-based test. This worked fine with exactly that dependency and XML-based configuration. But with Java configuration (which I suspect is still broken), it doesn't work.

It doesn't matter which implementation you use as long as you use an implementation and not the crappy jar... Trust me.. (We had the same issue and the issue is well documented on the internet).

Quote:

---

Originally Posted by Marten Deinum

It doesn't matter which implementation you use as long as you use an implementation and not the crappy jar... Trust me.. (We had the same issue and the issue is well documented on the internet).

---

Sorry, I don't understand. It worked perfectly fine with XML-based config. How is it not working now? I haven't changed the JARs that I use. I've always used the "crappy" jar.

Ordering of the jars might have changed due to updated dependencies/versions of spring or whatever... But the fact is that it is a problem. You have to make sure that that dependency comes last (and when running in eclipse it might always be a problem).

Quote:

---

Originally Posted by Marten Deinum

Ordering of the jars might have changed due to updated dependencies/versions of spring or whatever... But the fact is that it is a problem. You have to make sure that that dependency comes last (and when running in eclipse it might always be a problem).

---

Interesting. Just so I understand: what you're saying suggests that there's a JAR file somewhere in my build that implements these things, and in the previous configuration, it came first, but now it's coming after the javaee JAR, and thus the implementation isn't being loaded? I can't imagine what JAR that would be…

Well, I can't find the JBoss one anywhere, and all the glassfish repos are giving me 502 errors.