> problem is or else your getLogin() method is returning null. can you assurespecialist33 said:
I'm getting an incomprehensible "is not a valid ref" error. I've spent some hours trying to solve it, but I'm not being helped by the fact that I cannot seem to find a way of getting velocity to tell me what WOULD be a valid reference or WHY this is not a valid ref.
summary == [it's a public method in a public class, and i'm doing the VTL syntax properly, but still getting error messages. help!]
...
ok, i agree. you've got the public, public, public thing down, and you're getting most of your references right, so i either don't have a clue what the
> us that the latter is not the case?
It was sometimes returning null, so I made it forced return something (in this case the string "unquoted3" (quotes only there to illustrate, as the name suggests the value had no quotes ;)). That produced the following log statements:
[INFO]-I just put currentAccount = [EMAIL PROTECTED] into the context with getLogin = unquoted3
[INFO]-ResourceManager : found testcookie with loader org.apache.velocity.runtime.resource.loader.FileResourceLoader
[WARN]-org.apache.velocity.runtime.exception.ReferenceException: reference : template = testcookie [line 9,column 52] : $account.getLogin is not a valid reference.
(note that "testcookie" is the literal name of the template file being used here).
> problem is or else your getLogin() method is returning null. can you assure
! This possibility entirely passed me by (its probably in the docs and I just didn't notice it, but it's very counter-intuitive), and sounds like a serious problem in it's own right. If a null return value produces this error message too, then the error message is horribly unfair to the standard non-velocity java programmer... Java as a language has a fundamental philosophy of explicitly catching and outputting an error message on null's, leading to "NullPointerException" being one of the most frequently encountered for novice/intermediate programmers (and maybe it shouldn't, but the fact is it does, and people kind of expect java systems to honour that philosophy).
That error message ought at least to make explicit mention of null as a possible cause, since null is OFTEN a valid return value for applications - there is nothing wrong with logic that returns a null value in a java app, but velocity silently kills it. I can see the argument that in a templating engine perhaps null should never be returned - but that assumes this templating engine will never be attached to another system, and AFAICS velocity is proving extremely popular for attaching to other systems?
I'm guessing an even better approach would be two separate messages, one for the "couldn't find a method" and another for "found a method but it returned null", and in both cases it ought to say what the method name it found (or tried to find) was. That would shortcut the debugging process considerably, and probably reduce the number of people in my situation who even needed to come to the list to ask for help :).
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
