[ http://issues.apache.org/jira/browse/VELOCITY-389?page=comments#action_12329966 ]
Will Glass-Husain commented on VELOCITY-389: -------------------------------------------- You're right. Changed. We'll hit this for v1.5. > IllegalArgumentException while calling an overloaded method > ----------------------------------------------------------- > > Key: VELOCITY-389 > URL: http://issues.apache.org/jira/browse/VELOCITY-389 > Project: Velocity > Type: Bug > Components: Source > Versions: 1.4 > Environment: Operating System: All > Platform: All > Reporter: mike > Fix For: 1.5 > > 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 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
