Maven Surefire
  1. Maven Surefire
  2. SUREFIRE-459

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
    • 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

        Hide
        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
        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
        Dan Fabulich added a comment -

        Marking Fixed

        Show
        Dan Fabulich added a comment - Marking Fixed
        Hide
        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
        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
        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
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: