0 Replies Latest reply on Jan 5, 2012 11:38 AM by rcoe67

    Javassist-3.16.0-GA LocalVariableTable invalid length exception

    rcoe67

      I'm using PowerMock's @PrepareForTest annotation, specifying my own class, DbUtil's QueryRunner.class, DbUtil's ResultSetHandler.class and DataSource.class.  Both my own class and QueryRunner.class cause javassist to throw an Invalid Length in LocalVariable Table.

       

      I built from svn trunk the 3.16-GA library, because I saw the same behaviour with 3.15-GA.

       

      java.lang.ClassFormatError: Invalid length 124 in LocalVariableTable in class file org/apache/commons/dbutils/QueryRunner

      java.lang.ClassFormatError: Invalid length 1000 in LocalVariableTable in class file com/***/***/query/RemanenceSummaryQuery

       

      The stack trace I receive is dependent on the order in which the clases are declared in the annotation list, i.e. if QueryRunner is before my Query, then I get the QueryRunner exception.

       

      My declaration looks like:

      @RunWith( PowerMockRunner.class )

      @PrepareForTest( value = { RemanenceSummaryQuery.class, DataSource.class, QueryRunner.class,

                                ResultSetHandler.class } )

      public class RemanenceSummaryQueryTest

       

      If desired, I can upload the profile for my class but not sure how to generate one for QueryRunner.

       

      MORE INFO****

      This line is the culprit to the exception in my query class:

      LogMF.debug( logger, "Returned {0} rows for query: {1}", new Object[]{ results.size(),

                      this.toString() } );

       

      Likewise, when that line is commented out, my abstract base class throws the same exception with using StringBuilder to build up an expression.  Take that line out and it throws yet another exception when logging:

      LogMF.error( logger, "( {0} ) {1}", new Object[]{ this.getClass().getCanonicalName(),

                          e.getMessage() } );

       

      Take that line out and it throws yet another exception of the same type.

       

      This behaviour is consistent when compiling with Sun jdk7 to 1.7 and 1.6 compliancy, and openjdk 1.6