Maven Surefire

Integration test using Jetty and JSP 2.1 fails after update to maven-surefire-plugin 2.4

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.4, 2.4.1
  • Fix Version/s: 2.4.3
  • Component/s: classloading, Maven Surefire Plugin
  • Labels:
    None
  • Environment:
    Maven 2.0.8, Windows XP
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

We have an integration test running in a Struts 2 sample application, and after the maven-surefire-plugin was updated from 2.3 to 2.4, the test is failing. There's an issue registered in the Struts 2 JIRA explaining the error: https://issues.apache.org/struts/browse/WW-2494

I have no idea what's causing the error, but I suspect it has something to do witn classloader configuration, as aparently no tld files are found inside the jar files on the classpath.

It should be pretty easy to reproduce. Just checkout the Struts 2 code and run 'mvn test' on the portlet example application.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dan Fabulich added a comment -

Rather than just grabbing the current latest (which might be broken for some other reason), could you give me a specific SVN URL and revision number to pull down?

Prior to knowing anything else about your failing test, I might suggest that you take a look at SUREFIRE-453 and try configuring 2.4 with useSystemClassLoader=false.

Show
Dan Fabulich added a comment - Rather than just grabbing the current latest (which might be broken for some other reason), could you give me a specific SVN URL and revision number to pull down? Prior to knowing anything else about your failing test, I might suggest that you take a look at SUREFIRE-453 and try configuring 2.4 with useSystemClassLoader=false.
Hide
Permalink
Nils-Helge Garli added a comment -

Sorry for not beeing more specific. Anyway, it appears that this has been resolved in the 2.4.2-SNAPSHOT. I will re-test it when 2.4.2 is released to make sure it's still ok.

Show
Nils-Helge Garli added a comment - Sorry for not beeing more specific. Anyway, it appears that this has been resolved in the 2.4.2-SNAPSHOT. I will re-test it when 2.4.2 is released to make sure it's still ok.
Hide
Permalink
Dan Fabulich added a comment -

Marking Fixed

Show
Dan Fabulich added a comment - Marking Fixed
Hide
Permalink
Dan Fabulich added a comment -

We just found a repro case for this at Redfin. I'll attach a sample that repro's the problem.

Show
Dan Fabulich added a comment - We just found a repro case for this at Redfin. I'll attach a sample that repro's the problem.
Hide
Permalink
Dan Fabulich added a comment -

Fixed in revision 642046. By default forkMode=once and useSystemclassloader=true, which causes us to launch the tests using a a manifest-only jar; this confuses Jetty when it uses the system property "java.class.path" to javac to compile JSPs.

Fixed by deliberately "faking out" the java.class.path, setting it to what the classpath would have been if we'd launched the app in a conventional way. This also has the benefit of more generally insulating our users from the manifest-only jar; java.class.path will look "normal" now.

In the short term, there is an easy workaround for this, which is to set useSystemClassLoader=false. (My initial guess was correct.)

Show
Dan Fabulich added a comment - Fixed in revision 642046. By default forkMode=once and useSystemclassloader=true, which causes us to launch the tests using a a manifest-only jar; this confuses Jetty when it uses the system property "java.class.path" to javac to compile JSPs. Fixed by deliberately "faking out" the java.class.path, setting it to what the classpath would have been if we'd launched the app in a conventional way. This also has the benefit of more generally insulating our users from the manifest-only jar; java.class.path will look "normal" now. In the short term, there is an easy workaround for this, which is to set useSystemClassLoader=false. (My initial guess was correct.)
Hide
Permalink
Chris Beams added a comment - - edited

It appears that I've just reproduced this bug against 2.4.3. I've tried the 'useSystemClassLoader=false' workaround, and it exposes a different problem. Unfortunately this issue is 'closed' and so cannot be re-opened. Shall I create a new issue?

At any rate, here are the repro steps:

1) Check out, build and test Spring JavaConfig's petclinic sample:

svn co -r 789 https://src.springframework.org/svn/spring-javaconfig/trunk/samples/org.springframework.config.java.samples.petclinic petclinic
cd petclinic
mvn clean test

2) Notice that there are two test failures:

Tests in error:
testIndex(test.web.InContainerTests)
testFindOwners(test.web.InContainerTests)

The cause of both these issues is the following:

Error 500 /WEB-INF/jsp/includes.jsp(1,70) PWC6188: The absolute uri: http://www.springframework.org/tags cannot be resolved in either web.xml or the jar files deployed with this application

As mentioned above, downgrading to 2.3 does work - the tests pass once I do this. (See revision 790 of the above to confirm).

Show
Chris Beams added a comment - - edited It appears that I've just reproduced this bug against 2.4.3. I've tried the 'useSystemClassLoader=false' workaround, and it exposes a different problem. Unfortunately this issue is 'closed' and so cannot be re-opened. Shall I create a new issue? At any rate, here are the repro steps: 1) Check out, build and test Spring JavaConfig's petclinic sample: svn co -r 789 https://src.springframework.org/svn/spring-javaconfig/trunk/samples/org.springframework.config.java.samples.petclinic petclinic cd petclinic mvn clean test 2) Notice that there are two test failures: Tests in error: testIndex(test.web.InContainerTests) testFindOwners(test.web.InContainerTests) The cause of both these issues is the following: Error 500 /WEB-INF/jsp/includes.jsp(1,70) PWC6188: The absolute uri: http://www.springframework.org/tags cannot be resolved in either web.xml or the jar files deployed with this application As mentioned above, downgrading to 2.3 does work - the tests pass once I do this. (See revision 790 of the above to confirm).
Hide
Permalink
Dan Fabulich added a comment -

Yes, file a separate issue. But before you do, be sure to read this: http://maven.apache.org/plugins/maven-surefire-plugin/examples/class-loading.html

Show
Dan Fabulich added a comment - Yes, file a separate issue. But before you do, be sure to read this: http://maven.apache.org/plugins/maven-surefire-plugin/examples/class-loading.html

People

  • Assignee:
    Dan Fabulich
    Reporter:
    Nils-Helge Garli
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: