velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Bubna <>
Subject Re: Template lose track of variable?
Date Wed, 21 Jan 2009 23:47:02 GMT
On Wed, Jan 21, 2009 at 3:27 PM, Steve Cohen <> wrote:
> Nathan Bubna wrote:
>> On Wed, Jan 21, 2009 at 2:51 PM, Steve Cohen <>
>> 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.

in case you didn't already know, that constructor will use that
Properties object as it's internal context store.  it doesn't copy
things over.  so, if the whole lifecycle of your Properties object or
VelocityContext is not completely contained within a single thread,
then you have thread-safety issues.

> 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.

they're usually awfully hard to see, that's why i always suspect them
when i can't see a problem that only rarely happens.  once i (or my
boss) decides such a bug needs squashing, i just start trying to
replicate it.  until i can make it happen at will, there's no way for
me to know if i have really found and/or fixed it.  anything and
everything else is just speculation until the bug can be replicated.

> I fully expected, when I saw this, to find an error in my code or template,
> but surprisingly to me, I cannot.

ah, but the nasty bugs are never the visible ones.  such things
stopped surprising me years ago, though they never fail to irritate me

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message