Uploaded image for project: 'Wicket'
  1. Wicket
  2. WICKET-6133

Failing test SpringBeanWithGenericsTest in SNAPSHOT



    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 7.2.0
    • Fix Version/s: 7.3.0, 8.0.0-M1
    • Component/s: wicket-spring
    • Labels:
    • Environment:


      I try to build from source, but there's at least the
      following failing test. Skipping the tests builds OK and the results
      seem to work.

      Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.398 sec - in org.apache.wicket.spring.injection.annot.SpringBeanTest
      Running org.apache.wicket.spring.injection.annot.SpringBeanWithGenericsTest
      Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.557 sec <<< FAILURE! - in org.apache.wicket.spring.injection.annot.SpringBeanWithGenericsTestlistField(org.apache.wicket.spring.injection.annot.SpringBeanWithGenericsTest)
      Time elapsed: 0.072 sec  <<< FAILURE!
      java.lang.AssertionError: expected:<3> but was:<1>
              at org.junit.Assert.fail(Assert.java:88)
              at org.junit.Assert.failNotEquals(Assert.java:834)
              at org.junit.Assert.assertEquals(Assert.java:645)
              at org.junit.Assert.assertEquals(Assert.java:631)
              at org.apache.wicket.spring.injection.annot.SpringBeanWithGenericsTest.listField(SpringBeanWithGenericsTest.java:143)

      The mentioned line is the last one of the following quote:

              public void listField() throws Exception
                      AnnotatedListField page =
                              tester.startPage(new AnnotatedListField());
                      assertEquals(3, page.getStringsList().size());

      I've tested different versions of Maven, with and without a .m2 folder and even with changes to the source code of the test and my feeling is that the error I see is somewhat non deterministic. Without an available .m2 folder the test seems to PASS very often, but only during the first execution, directly afterwards with the same commands the test FAILs most of the time. I executed the test the whole morning today and it failed always, only to succeed some minutes ago before writing this report between lots of failing executions.

      I think the problem is with creating the test data properly and found the following commit, which introduced "getStringsList":


      The interesting part for me about that commit is that
      "ConfigContextWithGenerics.getStrings" in the same file was NOT
      changed as well. So I renamed to .stringsList and that did have an
      effect, now another test is failing instead:

      Failed tests:
      Expected: is <3>
           but: was <1>

      Looking at the other methods of ConfigContextWithGenerics, I'm pretty sure that "strings" is wrongly named, because all other methods are named after annotated fields. So I guess there's some magic in the background able to ignore the names and map using method signatur or such. And that might fail in most of my executions.

      Having a closer look at the error message, it says that 1 element is found where 3 were expected. The only 1 element list in the class is "myList", so I guess that is used most of times in my executions for whatever reason.

      I had a closer look at SpringComponentInjector and AnnotProxyFieldValueFactory, which e.g. contains getBeanNameOfClass, which resolves beans without any name.

      So in my opinion there's definitely something wrong with this test, at least ConfigContextWithGenerics.getStrings is wrongly named, but changing only that doesn't resolve the issue for me. There are still invocations failing with the 3 expected, 1 recognized error.

      This was discussed on the users list as well:



        1. SpringBeanWithGenericsTest.java.patch
          0.4 kB
          Thorsten Schöning

          Issue Links



              • Assignee:
                bitstorm Andrea Del Bene
                tschoening Thorsten Schöning
              • Votes:
                0 Vote for this issue
                4 Start watching this issue


                • Created: