You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Steve Cohen <sc...@javactivity.org> on 2009/01/21 21:49:03 UTC
Template lose track of variable?
Velocity has been a rock-solid winner for our company's use which has
been in effect for less than a month.
Now, however, I see a glitch that I can't explain:
Our templates are all very simple. Most use no macros, just straight
variables which are relatively simple POJOs for the most part and the
template page we are discussing indeed uses no macros, just text and a
couple of variables.
This page has template text something like this:
Your telephone number is <b>$tn.USFormattedTn</b>
where tn is an object of class TelephoneNumber
and class TelephoneNumber has a method String getUSFormattedTn().
We had a complaint of one instance in which this rendered as
Your telephone number is $tn.USFormattedTn
instead of
Your telephone number is 1-203-999-9999
which is how it should have rendered.
I can see from my logs that the context passed to this template in this
instance had the tn variable and that it wasn't found by Velocity:
2009-01-20 16:58:15,902 [robo/AIM:jrelay/2701] TRACE
velocity.VelociWrapper - {tn=203-999-9999, lang=English}
2009-01-20 16:58:15,910 [robo/AIM:jrelay/2701] DEBUG Velocity -
ResourceManager : found /resources/en_US/number/ExitComplete.vm with
loader org.apache.velocity.tools.view.servlet.WebappLoader
2009-01-20 16:58:15,911 [robo/AIM:jrelay/2701] DEBUG Velocity - Null
reference [template '/resources/en_US/number/ExitComplete.vm', line 6,
column 56] : $tn.USFormattedTn cannot be resolved.
The first log line is my wrapper which shows that tn is in the context
passed to velocity
The second log line shows that my template was found.
The third shows that Velocity could not resolve my reference
I can find many other instances in my logs where the USFormattedTn
property is successfully rendered on other
velocity pages and I have never seen this behavior before. I have been
all over my code verifying that the tn object was placed in the context,
that nothing removed it from the context, checked all capitalization,
etc. and I cannot see that I have done anything wrong to produce this
result.
What might account for this glitch?
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Template lose track of variable?
Posted by Byron Foster <by...@base2.cc>.
In Velocity 1.6 there is strict mode, property:
runtime.references.strict = true (There's info in the docs about it)
When this is set, if $tn is null, or is not in the context, then
velocity will throw an exception when you call USFormattedTn. As it
stands you can't tell if the error is occurring because $tn is non
existent or null, or if USFormattedTn is null.
Also, this error may be happening more then you think, but because
there is no real consequence for it, it's not getting reported very
often.
On Jan 21, 2009, at 13:49 , Steve Cohen wrote:
> 2009-01-20 16:58:15,902 [robo/AIM:jrelay/2701] TRACE
> velocity.VelociWrapper - {tn=203-999-9999, lang=English}
> 2009-01-20 16:58:15,910 [robo/AIM:jrelay/2701] DEBUG Velocity -
> ResourceManager : found /resources/en_US/number/ExitComplete.vm with
> loader org.apache.velocity.tools.view.servlet.WebappLoader
> 2009-01-20 16:58:15,911 [robo/AIM:jrelay/2701] DEBUG Velocity - Null
> reference [template '/resources/en_US/number/ExitComplete.vm', line
> 6, column 56] : $tn.USFormattedTn cannot be resolved.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Template lose track of variable?
Posted by Byron Foster <by...@base2.cc>.
On Jan 22, 2009, at 2:45 , Stellina99 wrote:
> Thanks for the information.I would like to know more about it.
If you're responding to me then:
Hmm, the anchor on the docs isn't working for some reason.. but got to
this page
and look at "Strict References Setting"
http://velocity.apache.org/engine/releases/velocity-1.6.1/user-guide.html#strictreferences
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Template lose track of variable?
Posted by Stellina99 <st...@gmail.com>.
Hi,
Thanks for the information.I would like to know more about it.
Stellina
http://business.bizoppjunction.com Home Based Business
--
View this message in context: http://www.nabble.com/Template-lose-track-of-variable--tp21591909p21600616.html
Sent from the Velocity - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Template lose track of variable?
Posted by Nathan Bubna <nb...@gmail.com>.
On Wed, Jan 21, 2009 at 3:27 PM, Steve Cohen <sc...@javactivity.org> wrote:
> Nathan Bubna wrote:
>>
>> On Wed, Jan 21, 2009 at 2:51 PM, Steve Cohen <sc...@javactivity.org>
>> 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.
agreed.
> 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
immensely.
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Template lose track of variable?
Posted by Steve Cohen <sc...@javactivity.org>.
Nathan Bubna wrote:
> On Wed, Jan 21, 2009 at 2:51 PM, Steve Cohen <sc...@javactivity.org> 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: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Template lose track of variable?
Posted by Nathan Bubna <nb...@gmail.com>.
On Wed, Jan 21, 2009 at 2:51 PM, Steve Cohen <sc...@javactivity.org> 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.
> White, Tim wrote:
>
>>> I can see from my logs that the context passed to this template in
>>>
>>
>> this
>>>
>>> instance had the tn variable and that it wasn't found by Velocity:
>>>
>>
>>
>>>
>>> 2009-01-20 16:58:15,902 [robo/AIM:jrelay/2701] TRACE
>>> velocity.VelociWrapper - {tn=203-999-9999, lang=English}
>>> 2009-01-20 16:58:15,910 [robo/AIM:jrelay/2701] DEBUG Velocity -
>>> ResourceManager : found /resources/en_US/number/ExitComplete.vm with loader
>>> org.apache.velocity.tools.view.servlet.WebappLoader
>>> 2009-01-20 16:58:15,911 [robo/AIM:jrelay/2701] DEBUG Velocity - Null
>>> reference [template '/resources/en_US/number/ExitComplete.vm', line 6,
>>>
>>
>>
>>>
>>> column 56] : $tn.USFormattedTn cannot be resolved.
>>>
>>
>>
>>
>> When I've had problems like these in the past, here are some things that
>> it's turned out to be (using your variable as an example):
>>
>> 1) tn is not null, but tn.USFormattedTn is null (perhaps because some
>> dependent object failed in the background).
>>
>> 2) There are multiple calls to $tn.USFormattedTn, and the happy path
>> cases work fine, but edge cases are misspelled:
>>
>> #if ($allisgood)
>> Your TN is: $tn.USFormattedTn
>> #else
>> Your TN is: $tn.usformattedtn
>> #end
>>
>> 3) Someone accidentally calls the .vm directly and not through the
>> controller (robots can do this in some cases, or bad links).
>>
>> 4) The value of $tn goes null between the controller debug statement and
>> the forward to the .vm.
>>
>>
>> Just some ideas of the kinds of things that this has been for me in the
>> past - I hope you can figure it out!
>>
>> Tim
>>
>>
>>
>> This communication is the property of Qwest and may contain confidential
>> or
>> privileged information. Unauthorized use of this communication is strictly
>> prohibited and may be unlawful. If you have received this communication in
>> error, please immediately notify the sender by reply e-mail and destroy all
>> copies of the communication and any attachments.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Template lose track of variable?
Posted by Steve Cohen <sc...@javactivity.org>.
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?
White, Tim wrote:
>> I can see from my logs that the context passed to this template in
>>
> this
>
>> instance had the tn variable and that it wasn't found by Velocity:
>>
>
>
>> 2009-01-20 16:58:15,902 [robo/AIM:jrelay/2701] TRACE
>> velocity.VelociWrapper - {tn=203-999-9999, lang=English}
>> 2009-01-20 16:58:15,910 [robo/AIM:jrelay/2701] DEBUG Velocity -
>> ResourceManager : found /resources/en_US/number/ExitComplete.vm with
>> loader org.apache.velocity.tools.view.servlet.WebappLoader
>> 2009-01-20 16:58:15,911 [robo/AIM:jrelay/2701] DEBUG Velocity - Null
>> reference [template '/resources/en_US/number/ExitComplete.vm', line 6,
>>
>
>
>> column 56] : $tn.USFormattedTn cannot be resolved.
>>
>
>
>
> When I've had problems like these in the past, here are some things that
> it's turned out to be (using your variable as an example):
>
> 1) tn is not null, but tn.USFormattedTn is null (perhaps because some
> dependent object failed in the background).
>
> 2) There are multiple calls to $tn.USFormattedTn, and the happy path
> cases work fine, but edge cases are misspelled:
>
> #if ($allisgood)
> Your TN is: $tn.USFormattedTn
> #else
> Your TN is: $tn.usformattedtn
> #end
>
> 3) Someone accidentally calls the .vm directly and not through the
> controller (robots can do this in some cases, or bad links).
>
> 4) The value of $tn goes null between the controller debug statement and
> the forward to the .vm.
>
>
> Just some ideas of the kinds of things that this has been for me in the
> past - I hope you can figure it out!
>
> Tim
>
>
>
> This communication is the property of Qwest and may contain confidential or
> privileged information. Unauthorized use of this communication is strictly
> prohibited and may be unlawful. If you have received this communication
> in error, please immediately notify the sender by reply e-mail and destroy
> all copies of the communication and any attachments.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
RE: Template lose track of variable?
Posted by "White, Tim" <Ti...@qwest.com>.
> I can see from my logs that the context passed to this template in
this
> instance had the tn variable and that it wasn't found by Velocity:
> 2009-01-20 16:58:15,902 [robo/AIM:jrelay/2701] TRACE
> velocity.VelociWrapper - {tn=203-999-9999, lang=English}
> 2009-01-20 16:58:15,910 [robo/AIM:jrelay/2701] DEBUG Velocity -
> ResourceManager : found /resources/en_US/number/ExitComplete.vm with
> loader org.apache.velocity.tools.view.servlet.WebappLoader
> 2009-01-20 16:58:15,911 [robo/AIM:jrelay/2701] DEBUG Velocity - Null
> reference [template '/resources/en_US/number/ExitComplete.vm', line 6,
> column 56] : $tn.USFormattedTn cannot be resolved.
When I've had problems like these in the past, here are some things that
it's turned out to be (using your variable as an example):
1) tn is not null, but tn.USFormattedTn is null (perhaps because some
dependent object failed in the background).
2) There are multiple calls to $tn.USFormattedTn, and the happy path
cases work fine, but edge cases are misspelled:
#if ($allisgood)
Your TN is: $tn.USFormattedTn
#else
Your TN is: $tn.usformattedtn
#end
3) Someone accidentally calls the .vm directly and not through the
controller (robots can do this in some cases, or bad links).
4) The value of $tn goes null between the controller debug statement and
the forward to the .vm.
Just some ideas of the kinds of things that this has been for me in the
past - I hope you can figure it out!
Tim
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org