Nathan Bubna wrote:
On Wed, Jan 21, 2009 at 2:51 PM, Steve Cohen <[email protected]> wrote:
Thanks much, Tim, but in this case
1) tn is not null, but tn.USFormattedTn is null (perhaps because some
dependent object failed in the background).
cannot be the case - the function merely applies formatting to the single
data element within the tn object (in this case the "1-"). Since the log
entry shows a value for tn, there is no possibility of null here.
2) There are multiple calls to $tn.USFormattedTn, and the happy path
cases work fine, but edge cases are misspelled:
there is only one path in this particular template
3) Someone accidentally calls the .vm directly and not through the
controller (robots can do this in some cases, or bad links).
impossible. There is only one path into the templates from my code. there is
no "back door"
4) The value of $tn goes null between the controller debug statement and
the forward to the .vm.
I investigated this and found it "impossible" - no code does it anyway,
although if we are talking about machine glitches, of course, nothing is
impossible.
So, are we talking about machine glitches, then?
i doubt it, those are rare. has this happened only once? this does
sound like it'll be very difficult to find, especially without more
info than a few log messages. Velocity version? How are you filling
the context? Context class? Are you sure there isn't a race
condition involved? that's always my first suspicion in such
mysterious errors. Under the covers, most standard Velocity Context
implementations use HashMaps. i doubt those are simply losing track
of a key/value pair.
Only once that I know of.
Yes, probably very difficult to find, possibly not worth the effort
unless I catch it happening again.
Using 1.6.1.
Context is constructed from Properties objects (a Properties is-a Map)
that my code passes around. Only right before it is passed to Velocity
is the context constructed, using the VelocityContext(Map) constructor.
I have checked the pass-around path and I see no way that this
properties object could have gotten corrupted between the time it was
logged and the time velocity looked at it. It's a linear path between
putting the object in the properties and passing the properties to my
Velocity wrapper for conversion to a Context and passage to Velocity for
merger with the template. There are no threading issues here - all this
happens in one thread so I don't see a race condition.
I fully expected, when I saw this, to find an error in my code or
template, but surprisingly to me, I cannot.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
