Ok, let me try to explain this one...
I have a Pull Tool which is added to the Context for each request (ie: new
instance each time). Calling the method in the Pull Tool looks like this:
$createdUser = $scarabR.getUser($attribute.CreatedBy)
The method signatures in the two classes looks like this:
public ScarabUser getUser(String id)
throws Exception
public int getCreatedBy()
Now, this is failing in Velocity and it isn't apparent exactly why other
than the signatures don't match up (return an int expect a String).
I would have "hoped" that Velocity would have been a bit more smart about
this an simply cast to a String via new Integer(int).toString() and then
passed that to the getUser(String) method instead of simply giving up with a
method not found.
So, in order to experiment a bit further, what I did was create another set
of getUser() methods to see which one was actually being called:
1. public ScarabUser getUser(int id)
throws Exception
2. public ScarabUser getUser(Integer id)
throws Exception
It turns out that the one with Integer in it (#2) is the one that is
actually being called. Now, to complicate things even further, in my code,
if I do this:
$createdUser = $scarabR.getUser("$attribute.CreatedBy")
Now, things work properly and the getUser(String) method is called.
One more puzzling bit was that there seems to be a bit of method caching in
Velocity which was causing the above to work if I put it in "" for a request
and then reloaded the template without the "" and it would still continue to
work.
So, Geir, I guess what I'm requesting here is the ability to have Velocity
be a bit more smart about the method lookup. For example, if something
returns an int don't just stop with matching that up to a method with an
Integer. It should also look for a method with a String as well.
thanks,
-jon
