Uploaded image for project: 'Velocity'
  1. Velocity
  2. VELOCITY-389

IllegalArgumentException while calling an overloaded method

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Invalid
    • 1.4
    • 1.5
    • Engine
    • None
    • Operating System: All
      Platform: All
    • 35625

    Description

      If there are two methods with the same name and different parameters like:
      public class myClass
      {
      public String foo ( Integer intObj );
      public String foo ( String str );
      }

      and a velocity template like this

      $myObj.foo( $someObj.getNull() )
      $myObj.foo( $str )

      while $someObj.getNull() returns null and $str is a java.lang.String object
      with a String like 'test'. Because velocity caches the first method with the
      Integer argument on calling with the parameter null (which isn't of course of
      any type/class) the call fails with the String argument, because velocity tries
      to call the foo( Integer intObj )!

      In the velocity log appears a IllegalArgumentException which is right, but
      velocity should call the right method!

      the bug appears only, if the call of foo is in a file
      which is included by #parse.

      You can reproduce the bug with following files:

      main template file:
      #set ( $param = $someobj.getNull() )
      #parse ( "includecall.vm" )<br>
      #set ( $param = "a string" )
      #parse ( "includecall.vm" )

      includecall.vm:
      $testobj.foo( $param )

      class with the name someobj in the context:

      public class VelocityCachingBug
      {
      public VelocityCachingBug()
      {
      }

      public String foo ( Integer s )

      { return "Integer"; }

      public String foo ( String i )

      { return "String"; }

      public Object getNull()

      { return null; }

      }

      if you render the main template, the second call can't be found by velocity
      because the parsed file is cached only once (as one single node).

      I don't think the solution to this is to cache every call in a parsed file (if
      it's parsed more than once), because that can lead to much more memory use if
      you have many parsed files (like we have...), which are mostly the same.

      mike

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              mypost05@mysign.ch mike
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: