Spring Framework
  1. Spring Framework
  2. SPR-7989

Using -enableassertions and AspectJ >= 1.6.10 may cause AssertionError in org.aspectj.weaver.UnresolvedType

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 3.0.5
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      When launching unit tests with maven surefire plugin, JVM assertions are enables by default.

      An assertion error occurs when loading jdbc:script with aspectj 1.6.10 and spring framework 3.0.5.

      This error appears when accessing method "private static String nameToSignature(String name)" of class org.aspectj.weaver.UnresolvedType line 726 during this assert execution : "assert name.charAt(0) != '[';"

      In debug mode, name value is "[org.springframework.core.io.Resource@xxxx".

      I guess this tab contains jdbc scripts as spring ressources from context xml config :

       
      <jdbc:embedded-database id="myTestDB" type="H2">
        <jdbc:script location="classpath:referentiel/sql/01-referentiel-create-tables.sql" />
        <jdbc:script location="classpath:referentiel-domaine/sql/01-referentiel-domaine-create-tables.sql" />
        <jdbc:script location="classpath:referentiel-domaine/sql/02-referentiel-domaine-insert-tr-tables.sql" />
      </jdbc:embedded-database> 
      

      So Application context canot be load due to assertion error.

        Issue Links

          Activity

          Hide
          Cédric Gillet added a comment -

          Thanks Jean-François FOURMOND for helping me in debugging this issue.

          Show
          Cédric Gillet added a comment - Thanks Jean-François FOURMOND for helping me in debugging this issue.
          Hide
          Taras Tielkes added a comment -

          I'm seeing this issue too, but in a different context.
          A bean in the current context file has a method returning type String[].

          Spring AOP using @AspectJ aspects is used.
          During test execution this exception is thrown from AspectJ every time.

          After updating to Spring 3.0.5 this is now preventing us from upgrading to AspectJ 1.6.10 (which we want to do because of other AspectJ bugs).

          Show
          Taras Tielkes added a comment - I'm seeing this issue too, but in a different context. A bean in the current context file has a method returning type String[]. Spring AOP using @AspectJ aspects is used. During test execution this exception is thrown from AspectJ every time. After updating to Spring 3.0.5 this is now preventing us from upgrading to AspectJ 1.6.10 (which we want to do because of other AspectJ bugs).
          Hide
          Magne Rasmussen added a comment -

          I'm also seeing this issue, with AspectJ 1.6.10+ and Spring 3.1.1

          Show
          Magne Rasmussen added a comment - I'm also seeing this issue, with AspectJ 1.6.10+ and Spring 3.1.1
          Hide
          Chris Beams added a comment -

          Added @aclement as a watcher. Andy, can you provide any commentary about this assertion in AJ 1.6.10?

          @Cedric, @Taras, @Magne, could one of you put together a very simple reproduction project per the instructions at https://github.com/SpringSource/spring-framework-issues#readme? This will help Andy and I track things down and come to a resolution for this issue.

          Thanks!

          Show
          Chris Beams added a comment - Added @aclement as a watcher. Andy, can you provide any commentary about this assertion in AJ 1.6.10? @Cedric, @Taras, @Magne, could one of you put together a very simple reproduction project per the instructions at https://github.com/SpringSource/spring-framework-issues#readme? This will help Andy and I track things down and come to a resolution for this issue. Thanks!
          Hide
          Chris Beams added a comment -

          Disregard my previous request for a reproduction project. The following steps reproduce this issue clearly:

          1. clone spring-framework
          2. git checkout 963b4e49a98e85e70989427c3e8faec2e408ba5d
          3. ./gradle :spring-context:test -Dtest.single=AtAspectJAnnotationBindingTests; notice that tests pass
          4. edit build.gradle, change all AJ 1.6.8 versions to 1.6.10 (or higher)
          5. ./gradle :spring-context:test -Dtest.single=AtAspectJAnnotationBindingTests; notice that tests fail, due to assertion failure at UnresolvedType:749 as reported above
          Show
          Chris Beams added a comment - Disregard my previous request for a reproduction project. The following steps reproduce this issue clearly: clone spring-framework git checkout 963b4e49a98e85e70989427c3e8faec2e408ba5d ./gradle :spring-context:test -Dtest.single=AtAspectJAnnotationBindingTests ; notice that tests pass edit build.gradle, change all AJ 1.6.8 versions to 1.6.10 (or higher) ./gradle :spring-context:test -Dtest.single=AtAspectJAnnotationBindingTests ; notice that tests fail, due to assertion failure at UnresolvedType:749 as reported above
          Hide
          Chris Beams added a comment -

          This is not actually a bug in Spring, but rather something that the AspectJ team needs to review. I've pinged them (Andy Clement) to take a look.

          In the meantime, here's the commit comment from SPR-9272, which explains the workaround we used when upgrading Spring itself to AspectJ 1.6.12:

          commit 0ab9e9a0c64a252fb8d8590bc302e82b8c8926c6
          Author: Chris Beams <cbeams@vmware.com>
          Date:   Sat Apr 14 19:05:20 2012 +0300
          
              Upgrade AspectJ from 1.6.8 to 1.6.12
              
               - Spring remains compatible against AJ version 1.6.8, but is now
                 compiling and testing against 1.6.12
              
               - Encountered what appears to be an AJ bug introduced in 1.6.10: an
                 assertion in org.aspectj.weaver.UnresolvedType causes a false
                 negative failure when encountering org.springframework.io.Resource
                 arrays, e.g. "[org.springframework.io.Resource@xxx". This problem
                 has been reported to the AJ team and in the meantime, the recommended
                 workaround is to disable assertions either completely, or at least
                 selectively with
              
                     -disableassertions:org.aspectj.weaver.UnresolvedType
              
              Issue: SPR-7989, SPR-9272
          
          Show
          Chris Beams added a comment - This is not actually a bug in Spring, but rather something that the AspectJ team needs to review. I've pinged them (Andy Clement) to take a look. In the meantime, here's the commit comment from SPR-9272 , which explains the workaround we used when upgrading Spring itself to AspectJ 1.6.12: commit 0ab9e9a0c64a252fb8d8590bc302e82b8c8926c6 Author: Chris Beams <cbeams@vmware.com> Date: Sat Apr 14 19:05:20 2012 +0300 Upgrade AspectJ from 1.6.8 to 1.6.12 - Spring remains compatible against AJ version 1.6.8, but is now compiling and testing against 1.6.12 - Encountered what appears to be an AJ bug introduced in 1.6.10: an assertion in org.aspectj.weaver.UnresolvedType causes a false negative failure when encountering org.springframework.io.Resource arrays, e.g. "[org.springframework.io.Resource@xxx". This problem has been reported to the AJ team and in the meantime, the recommended workaround is to disable assertions either completely, or at least selectively with -disableassertions:org.aspectj.weaver.UnresolvedType Issue: SPR-7989, SPR-9272
          Hide
          Andy Clement added a comment -

          I had a dig around as the assert you mentioned reminded me of something. It actually got removed recently (last few weeks) but that doesn't really help here as there is no 1.6.X release with the change in. However, the testcase you created does show me that there is an AspectJ issue here. The method is expecting this style name for an array related entity: 'com.foo.Bar[]' and not this style: '[Lcom.foo.Bar;'. I think the usual AspectJ compilation/weaving mechanism doesn't use nameToSignature because name processing is expensive (it tries to work only in signatures), that is one reason why this hasn't come up on the AJ bugzilla. Spring comes in via a slightly different route. Anyway, I've fixed it up and added some AspectJ tests under https://bugs.eclipse.org/bugs/show_bug.cgi?id=376918. This will be in the AspectJ 1.7.0 release, there are no new 1.6 releases planned.

          Show
          Andy Clement added a comment - I had a dig around as the assert you mentioned reminded me of something. It actually got removed recently (last few weeks) but that doesn't really help here as there is no 1.6.X release with the change in. However, the testcase you created does show me that there is an AspectJ issue here. The method is expecting this style name for an array related entity: 'com.foo.Bar[]' and not this style: '[Lcom.foo.Bar;'. I think the usual AspectJ compilation/weaving mechanism doesn't use nameToSignature because name processing is expensive (it tries to work only in signatures), that is one reason why this hasn't come up on the AJ bugzilla. Spring comes in via a slightly different route. Anyway, I've fixed it up and added some AspectJ tests under https://bugs.eclipse.org/bugs/show_bug.cgi?id=376918 . This will be in the AspectJ 1.7.0 release, there are no new 1.6 releases planned.
          Hide
          Chris Beams added a comment -

          Thanks, Andy. So for posterity's sake, the official workaround here is to (selectively) disable assertions when working against AspectJ versions 1.6.10 through 1.6.12, and when possible, to update to 1.7.0+, where the problematic assertion no longer exists.

          Show
          Chris Beams added a comment - Thanks, Andy. So for posterity's sake, the official workaround here is to (selectively) disable assertions when working against AspectJ versions 1.6.10 through 1.6.12, and when possible, to update to 1.7.0+, where the problematic assertion no longer exists.

            People

            • Assignee:
              Chris Beams
              Reporter:
              Cédric Gillet
              Last updater:
              Trevor Marshall
            • Votes:
              3 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                2 years, 1 week, 1 day ago