You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Will Glass-Husain <wg...@forio.com> on 2006/03/20 22:33:09 UTC
handling macro argument errors
Hi,
Wanted to ask for some quick feedback on VELOCITY-435. One of the
directions for Velocity 1.5 that's emerged is better error handling. Most
stuff that used to be logged can now be trapped and reported. One exception
is macro callswith an invalid numbers of arguments. Error messages are
buried in a log, there's no way to trap them and make them more visible.
Example error:
#macro(foo $a) $a #end
#foo("test1" "test2")
Ideally, this would throw a ParseErrorException, but it can't due to
backwards compatibility. (lots of existing templates with this problem would
break). This would enable functionality like this (courtesy of Malcolm
Edgars)
http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink#
Some solutions - any feedback?
(1) yet another configuration option
runtime.macros.strict = true
(2) yet another event handler. I've already got an
"InvalidReferenceEventHandler" in progress, this could be a new method for
that.
(3) something more creative?
Thanks, WILL
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
Re: handling macro argument errors
Posted by Gonzalo Diethelm <go...@diethelm.org>.
*Plonk*
On Fri, 2006-03-24 at 18:05 +0100, Jonathan Revusky wrote:
> Daniel Dekany wrote:
> > Thursday, March 23, 2006, 5:43:32 AM, Gonzalo Diethelm wrote:
> >
> >
> >>On Thu, 2006-03-23 at 01:16 +0100, Jonathan Revusky wrote:
> >>
> >>>I mean to say basically.... be men, grow some balls.... :-)
> >>
> >>This post proves (to me) that you not only lack the common sense to
> >>refrain from posting where you have been repeatedly told "we don't care
> >>for your opinions", but also that you are a rude, insulting, vulgar,
> >>ill-mannered person.
> >
> >
> > Well I don't agree with Jonathan on this topic, because I think that
> > doing a new behavior optional allows people to review the templates
> > when they want to, while they still can use the other improvements...
>
> Well, the basic thing is that if it makes sense to fix this definitively
> for 2.0 (i.e. make the correct behavior the default) then it would make
> sense moving from 1.4-> 1.5. It's still quite a major version upgrade.
>
> The same transitional pain gets imposed either way. It's better for it
> to be sooner rather than later.
>
> >
> > But, your reaction doesn't make sense either, or rather it looks
> > pretended... You see, if you are really this sensible, you could not
> > survive in this world too long, as you would die be seeing all the
> > horror around you (I mean, real bad and disgusting things, not just
> > hearing bit strong language)... So what this meant to be, please?
>
>
> Well, yeah, of course he's pretending to be soooo offended. :-) It's
> quite comical.
>
> Regards,
>
> Jonathan Revusky
> --
> lead developer, FreeMarker project, http://freemarker.org/
>
> >
> >
> >>If I ever had any curiosity for your product(s), I
> >>can assure you that, from now on, I will make sure I never go anywhere
> >>near them.
> >>
> >>
> >>>Regards,
> >>>
> >>>Jonathan Revusky
> >>
> >>Trying to sugar coat? I won't buy it, no sir.
> >>
> >>
> >>>lead developer, FreeMarker project, http://freemarker.org/
> >>
> >>I truly hope you do really well with your project(s) and product(s). I
> >>won't touch them with a flag pole if I have any say in the matter.
> >
> >
> > The question is, who do you cause harm by that... Anyway, if you hate
> > Jonathan, then why do you "truly" hope that things are going well for
> > him??? (Well sorry for being this OT, but this pretence that most
> > people do, this "oooh I'm a sooo sensitive and liberal and nice guy",
> > and then you look around the world what they do in reality... Slowly I
> > go toward that I don't trust people who never says anything vulgar.
> > Real saints are rare.)
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Gonzalo Diethelm
gonzalo.diethelm@aditiva.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: handling macro argument errors
Posted by Jonathan Revusky <re...@wanadoo.es>.
Daniel Dekany wrote:
> Thursday, March 23, 2006, 5:43:32 AM, Gonzalo Diethelm wrote:
>
>
>>On Thu, 2006-03-23 at 01:16 +0100, Jonathan Revusky wrote:
>>
>>>I mean to say basically.... be men, grow some balls.... :-)
>>
>>This post proves (to me) that you not only lack the common sense to
>>refrain from posting where you have been repeatedly told "we don't care
>>for your opinions", but also that you are a rude, insulting, vulgar,
>>ill-mannered person.
>
>
> Well I don't agree with Jonathan on this topic, because I think that
> doing a new behavior optional allows people to review the templates
> when they want to, while they still can use the other improvements...
Well, the basic thing is that if it makes sense to fix this definitively
for 2.0 (i.e. make the correct behavior the default) then it would make
sense moving from 1.4-> 1.5. It's still quite a major version upgrade.
The same transitional pain gets imposed either way. It's better for it
to be sooner rather than later.
>
> But, your reaction doesn't make sense either, or rather it looks
> pretended... You see, if you are really this sensible, you could not
> survive in this world too long, as you would die be seeing all the
> horror around you (I mean, real bad and disgusting things, not just
> hearing bit strong language)... So what this meant to be, please?
Well, yeah, of course he's pretending to be soooo offended. :-) It's
quite comical.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
>
>>If I ever had any curiosity for your product(s), I
>>can assure you that, from now on, I will make sure I never go anywhere
>>near them.
>>
>>
>>>Regards,
>>>
>>>Jonathan Revusky
>>
>>Trying to sugar coat? I won't buy it, no sir.
>>
>>
>>>lead developer, FreeMarker project, http://freemarker.org/
>>
>>I truly hope you do really well with your project(s) and product(s). I
>>won't touch them with a flag pole if I have any say in the matter.
>
>
> The question is, who do you cause harm by that... Anyway, if you hate
> Jonathan, then why do you "truly" hope that things are going well for
> him??? (Well sorry for being this OT, but this pretence that most
> people do, this "oooh I'm a sooo sensitive and liberal and nice guy",
> and then you look around the world what they do in reality... Slowly I
> go toward that I don't trust people who never says anything vulgar.
> Real saints are rare.)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: handling macro argument errors
Posted by Daniel Dekany <dd...@freemail.hu>.
Thursday, March 23, 2006, 5:43:32 AM, Gonzalo Diethelm wrote:
> On Thu, 2006-03-23 at 01:16 +0100, Jonathan Revusky wrote:
>> I mean to say basically.... be men, grow some balls.... :-)
>
> This post proves (to me) that you not only lack the common sense to
> refrain from posting where you have been repeatedly told "we don't care
> for your opinions", but also that you are a rude, insulting, vulgar,
> ill-mannered person.
Well I don't agree with Jonathan on this topic, because I think that
doing a new behavior optional allows people to review the templates
when they want to, while they still can use the other improvements...
But, your reaction doesn't make sense either, or rather it looks
pretended... You see, if you are really this sensible, you could not
survive in this world too long, as you would die be seeing all the
horror around you (I mean, real bad and disgusting things, not just
hearing bit strong language)... So what this meant to be, please?
> If I ever had any curiosity for your product(s), I
> can assure you that, from now on, I will make sure I never go anywhere
> near them.
>
>> Regards,
>>
>> Jonathan Revusky
>
> Trying to sugar coat? I won't buy it, no sir.
>
>> lead developer, FreeMarker project, http://freemarker.org/
>
> I truly hope you do really well with your project(s) and product(s). I
> won't touch them with a flag pole if I have any say in the matter.
The question is, who do you cause harm by that... Anyway, if you hate
Jonathan, then why do you "truly" hope that things are going well for
him??? (Well sorry for being this OT, but this pretence that most
people do, this "oooh I'm a sooo sensitive and liberal and nice guy",
and then you look around the world what they do in reality... Slowly I
go toward that I don't trust people who never says anything vulgar.
Real saints are rare.)
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: handling macro argument errors
Posted by Gonzalo Diethelm <go...@diethelm.org>.
On Thu, 2006-03-23 at 01:16 +0100, Jonathan Revusky wrote:
> I mean to say basically.... be men, grow some balls.... :-)
This post proves (to me) that you not only lack the common sense to
refrain from posting where you have been repeatedly told "we don't care
for your opinions", but also that you are a rude, insulting, vulgar,
ill-mannered person. If I ever had any curiosity for your product(s), I
can assure you that, from now on, I will make sure I never go anywhere
near them.
> Regards,
>
> Jonathan Revusky
Trying to sugar coat? I won't buy it, no sir.
> lead developer, FreeMarker project, http://freemarker.org/
I truly hope you do really well with your project(s) and product(s). I
won't touch them with a flag pole if I have any say in the matter.
--
Gonzalo Diethelm
gonzalo.diethelm@aditiva.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: handling macro argument errors
Posted by Jonathan Revusky <re...@wanadoo.es>.
Geir Magnusson Jr wrote:
>
>
> Nathan Bubna wrote:
>
>> If i may be forgiven one last push... :)
>>
>> Let's keep the story straight--you wouldn't have to edit the old apps
>> to make them work with 1.5. You just have to set the config property,
>> not really a great burden. We could even make the message with the
>> thrown exception point out the new config property, so that those who
>> don't read change logs or release notes will have no problem figuring
>> out what's going on.
>
>
> That means you can't just upgrade and have things work. You have to
> upgrade and reconfigure.
>
> I'd make it work like 1.4 by default, turn on new behavior w/ a switch,
> and fix it in 2.0
I don't understand this mentality, frankly.
If you are going to fix this, then just fix it. The transitional cost
will, if anything, be greater by fixing something like this later rather
than sooner.
Basically, it seems to me that you have two choices:
(a) Say you are never going to fix this for BWC reasons
(b) Fix it.
If the choice is (b) then fix it immediately and incur the cost
immediately, since the transitional pain has to be incurred eventually
anyway.
I mean to say basically.... be men, grow some balls.... :-)
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> geir
>
>>
>> On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
>>
>>> I feel strongly about this.
>>>
>>> I've personally got hundreds of templates in production and support
>>> users
>>> with hundreds more. Say 5% of those templates have this error.
>>> (It's not
>>> hard to make -- note that the Velocity test suite for Anakia contains
>>> this
>>> error). All of a sudden I have tens of templates, scattered all over
>>> the
>>> place that suddenly cause errors. All of those apps work right now-
>>> why do
>>> I want them to fail? Anything that requires me to edit old apps to make
>>> Velocity 1.5 work is not backwards compatible. (and will retard
>>> adoption of
>>> 1.5).
>>>
>>> It would have been nicer if this had always generated an error. For new
>>> apps this is better. But for old apps it is actively harmful to change
>>> this. So let's make this a config option and turn it on by default
>>> for 2.0
>>> .
>>>
>>> WILL
>>>
>>> On 3/21/06, Nathan Bubna <nb...@gmail.com> wrote:
>>>
>>>> On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
>>>>
>>>>> I'm starting to agree with you, Llwellyn. Though I don't think we
>>>>
>>>> should
>>>>
>>>>> change the behavior of the templates for existing users.
>>>>
>>>> even if the behavior is buggy/broken? it's not like the extra or
>>>> missing arguments were doing anything functionally. throwing an
>>>> exception, however, will add functionality (as Malcom demonstrated.
>>>> we already warned that their macro call was broken in the logs, i
>>>> think it is fair to escalate that to an exception, especially if we
>>>> provide a config option to log instead of throw an exception.
>>>>
>>>> of course, if you feel strongly about this, i won't -1 a log-only
>>>> default, and i'll let them that do the work implement it the way they
>>>> want :). it's just my opinion; i won't be dogmatic on it. :)
>>>>
>>>>> WILL
>>>>>
>>>>> On 3/21/06, Llewellyn Falco <is...@setgame.com> wrote:
>>>>>
>>>>>>
>>>>>>> Personally, i feel that templates whose macro calls don't match up
>>>>
>>>> to
>>>>
>>>>>>> the macro definitions are *already* broken.
>>>>>>
>>>>>> this is my general thought on the whole thing too.
>>>>>>
>>>>>> and as we deal in financial transactions, I take a general view of
>>>>>> it is better not to show something than to show something wrong.
>>>>>>
>>>>>> however, I can understand that in an entertainment situation you
>>>>>> might
>>>>>> have
>>>>>> the exact opposite view.
>>>>>> again though, I think this goes back to a 2 modes of running.
>>>>>>
>>>>>> development - always halt on errors - someone's there to fix them.
>>>>>> deployment - do the best you can - log what goes wrong
>>>>>>
>>>>>> and see a setting much more in this idea.
>>>>>>
>>>>>>
>>>>>>
>>>>>> btw: this is also why I always develop with the UberspectTestImpl and
>>>>>> rather
>>>>>> think that it should be default Uberspect, while currently it is only
>>>>
>>>> in
>>>>
>>>>>> the
>>>>>> test classes.
>>>>>>
>>>>>> Llewellyn.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>>>>>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Forio Business Simulations
>>>>>
>>>>> Will Glass-Husain
>>>>> wglass@forio.com
>>>>> www.forio.com
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>> --
>>> Forio Business Simulations
>>>
>>> Will Glass-Husain
>>> wglass@forio.com
>>> www.forio.com
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: handling macro argument errors
Posted by Will Glass-Husain <wg...@forio.com>.
I've got code to address this issue (invalid references) in progress. it's
an optional event handler, with a default implementation.
On 3/22/06, Malcolm Edgar <ma...@gmail.com> wrote:
>
> Hi All,
>
> couple of comments on this issue.
>
> I think the default error handling behaviour in V1.4 is not good for
> development. I am seeing this currently in a project where developers
> are using V1.4 in a pipeline to generate XML which in turn will
> generate PDFs, when markup errors are made no PDF's come out the other
> end, and its time to trawl through the logs to find out what happened.
>
> Now I think the error logging is much improved in V1.5 with detailed
> information on the error location, and less debug messages in the log
> output.
>
> However the current V1.5 will still happily log errors such as making
> calling methods which do not exist on objects, e.g.
>
> [Velocity] [warn ]
> org.apache.velocity.runtime.exception.ReferenceException: reference :
> template = /action-demo.htm [line 14,column 1] : $link.noSuchMethod()
> is not a valid reference.
>
> This error handling behaviour should be configurable, i.e. flip the
> switch and it will throw an exception (ReferenceException should be
> made unchecked if we use this class). We ("the royal we") should make
> this very easy to configure.
>
> I am probably +1 on the 1.4 support by default, but it would be very
> good to document the error handling behaviour and how to configure
> this easily.
>
> I think all the points raised by Max is his blog are very relevant:
>
>
> http://blog.hibernate.org/cgi-bin/blosxom.cgi/2006/02/03#a_story_about_freemarker_and_velocity
>
> I think many of these issues have been addressed, but there is still
> opportunity to improve Velocity with more descriptive error messages
> and easier configuration API.
>
> regards Malcolm Edgar
>
> On 3/22/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >
> >
> > Nathan Bubna wrote:
> > > If i may be forgiven one last push... :)
> > >
> > > Let's keep the story straight--you wouldn't have to edit the old apps
> > > to make them work with 1.5. You just have to set the config property,
> > > not really a great burden. We could even make the message with the
> > > thrown exception point out the new config property, so that those who
> > > don't read change logs or release notes will have no problem figuring
> > > out what's going on.
> >
> > That means you can't just upgrade and have things work. You have to
> > upgrade and reconfigure.
> >
> > I'd make it work like 1.4 by default, turn on new behavior w/ a switch,
> > and fix it in 2.0
> >
> > geir
> >
> > >
> > > On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> > >> I feel strongly about this.
> > >>
> > >> I've personally got hundreds of templates in production and support
> users
> > >> with hundreds more. Say 5% of those templates have this
> error. (It's not
> > >> hard to make -- note that the Velocity test suite for Anakia contains
> this
> > >> error). All of a sudden I have tens of templates, scattered all over
> the
> > >> place that suddenly cause errors. All of those apps work right now-
> why do
> > >> I want them to fail? Anything that requires me to edit old apps to
> make
> > >> Velocity 1.5 work is not backwards compatible. (and will retard
> adoption of
> > >> 1.5).
> > >>
> > >> It would have been nicer if this had always generated an error. For
> new
> > >> apps this is better. But for old apps it is actively harmful to
> change
> > >> this. So let's make this a config option and turn it on by default
> for 2.0
> > >> .
> > >>
> > >> WILL
> > >>
> > >> On 3/21/06, Nathan Bubna <nb...@gmail.com> wrote:
> > >>> On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> > >>>> I'm starting to agree with you, Llwellyn. Though I don't think we
> > >>> should
> > >>>> change the behavior of the templates for existing users.
> > >>> even if the behavior is buggy/broken? it's not like the extra or
> > >>> missing arguments were doing anything functionally. throwing an
> > >>> exception, however, will add functionality (as Malcom demonstrated.
> > >>> we already warned that their macro call was broken in the logs, i
> > >>> think it is fair to escalate that to an exception, especially if we
> > >>> provide a config option to log instead of throw an exception.
> > >>>
> > >>> of course, if you feel strongly about this, i won't -1 a log-only
> > >>> default, and i'll let them that do the work implement it the way
> they
> > >>> want :). it's just my opinion; i won't be dogmatic on it. :)
> > >>>
> > >>>> WILL
> > >>>>
> > >>>> On 3/21/06, Llewellyn Falco <is...@setgame.com> wrote:
> > >>>>>
> > >>>>>> Personally, i feel that templates whose macro calls don't match
> up
> > >>> to
> > >>>>>> the macro definitions are *already* broken.
> > >>>>> this is my general thought on the whole thing too.
> > >>>>>
> > >>>>> and as we deal in financial transactions, I take a general view of
> > >>>>> it is better not to show something than to show something wrong.
> > >>>>>
> > >>>>> however, I can understand that in an entertainment situation you
> might
> > >>>>> have
> > >>>>> the exact opposite view.
> > >>>>> again though, I think this goes back to a 2 modes of running.
> > >>>>>
> > >>>>> development - always halt on errors - someone's there to fix them.
> > >>>>> deployment - do the best you can - log what goes wrong
> > >>>>>
> > >>>>> and see a setting much more in this idea.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> btw: this is also why I always develop with the UberspectTestImpl
> and
> > >>>>> rather
> > >>>>> think that it should be default Uberspect, while currently it is
> only
> > >>> in
> > >>>>> the
> > >>>>> test classes.
> > >>>>>
> > >>>>> Llewellyn.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail:
> velocity-dev-unsubscribe@jakarta.apache.org
> > >>>>> For additional commands, e-mail:
> velocity-dev-help@jakarta.apache.org
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> --
> > >>>> Forio Business Simulations
> > >>>>
> > >>>> Will Glass-Husain
> > >>>> wglass@forio.com
> > >>>> www.forio.com
> > >>>>
> > >>>>
> > >>>
> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > >>> For additional commands, e-mail:
> velocity-dev-help@jakarta.apache.org
> > >>>
> > >>>
> > >>
> > >> --
> > >> Forio Business Simulations
> > >>
> > >> Will Glass-Husain
> > >> wglass@forio.com
> > >> www.forio.com
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
Re: handling macro argument errors
Posted by Malcolm Edgar <ma...@gmail.com>.
Hi All,
couple of comments on this issue.
I think the default error handling behaviour in V1.4 is not good for
development. I am seeing this currently in a project where developers
are using V1.4 in a pipeline to generate XML which in turn will
generate PDFs, when markup errors are made no PDF's come out the other
end, and its time to trawl through the logs to find out what happened.
Now I think the error logging is much improved in V1.5 with detailed
information on the error location, and less debug messages in the log
output.
However the current V1.5 will still happily log errors such as making
calling methods which do not exist on objects, e.g.
[Velocity] [warn ]
org.apache.velocity.runtime.exception.ReferenceException: reference :
template = /action-demo.htm [line 14,column 1] : $link.noSuchMethod()
is not a valid reference.
This error handling behaviour should be configurable, i.e. flip the
switch and it will throw an exception (ReferenceException should be
made unchecked if we use this class). We ("the royal we") should make
this very easy to configure.
I am probably +1 on the 1.4 support by default, but it would be very
good to document the error handling behaviour and how to configure
this easily.
I think all the points raised by Max is his blog are very relevant:
http://blog.hibernate.org/cgi-bin/blosxom.cgi/2006/02/03#a_story_about_freemarker_and_velocity
I think many of these issues have been addressed, but there is still
opportunity to improve Velocity with more descriptive error messages
and easier configuration API.
regards Malcolm Edgar
On 3/22/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Nathan Bubna wrote:
> > If i may be forgiven one last push... :)
> >
> > Let's keep the story straight--you wouldn't have to edit the old apps
> > to make them work with 1.5. You just have to set the config property,
> > not really a great burden. We could even make the message with the
> > thrown exception point out the new config property, so that those who
> > don't read change logs or release notes will have no problem figuring
> > out what's going on.
>
> That means you can't just upgrade and have things work. You have to
> upgrade and reconfigure.
>
> I'd make it work like 1.4 by default, turn on new behavior w/ a switch,
> and fix it in 2.0
>
> geir
>
> >
> > On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> >> I feel strongly about this.
> >>
> >> I've personally got hundreds of templates in production and support users
> >> with hundreds more. Say 5% of those templates have this error. (It's not
> >> hard to make -- note that the Velocity test suite for Anakia contains this
> >> error). All of a sudden I have tens of templates, scattered all over the
> >> place that suddenly cause errors. All of those apps work right now- why do
> >> I want them to fail? Anything that requires me to edit old apps to make
> >> Velocity 1.5 work is not backwards compatible. (and will retard adoption of
> >> 1.5).
> >>
> >> It would have been nicer if this had always generated an error. For new
> >> apps this is better. But for old apps it is actively harmful to change
> >> this. So let's make this a config option and turn it on by default for 2.0
> >> .
> >>
> >> WILL
> >>
> >> On 3/21/06, Nathan Bubna <nb...@gmail.com> wrote:
> >>> On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> >>>> I'm starting to agree with you, Llwellyn. Though I don't think we
> >>> should
> >>>> change the behavior of the templates for existing users.
> >>> even if the behavior is buggy/broken? it's not like the extra or
> >>> missing arguments were doing anything functionally. throwing an
> >>> exception, however, will add functionality (as Malcom demonstrated.
> >>> we already warned that their macro call was broken in the logs, i
> >>> think it is fair to escalate that to an exception, especially if we
> >>> provide a config option to log instead of throw an exception.
> >>>
> >>> of course, if you feel strongly about this, i won't -1 a log-only
> >>> default, and i'll let them that do the work implement it the way they
> >>> want :). it's just my opinion; i won't be dogmatic on it. :)
> >>>
> >>>> WILL
> >>>>
> >>>> On 3/21/06, Llewellyn Falco <is...@setgame.com> wrote:
> >>>>>
> >>>>>> Personally, i feel that templates whose macro calls don't match up
> >>> to
> >>>>>> the macro definitions are *already* broken.
> >>>>> this is my general thought on the whole thing too.
> >>>>>
> >>>>> and as we deal in financial transactions, I take a general view of
> >>>>> it is better not to show something than to show something wrong.
> >>>>>
> >>>>> however, I can understand that in an entertainment situation you might
> >>>>> have
> >>>>> the exact opposite view.
> >>>>> again though, I think this goes back to a 2 modes of running.
> >>>>>
> >>>>> development - always halt on errors - someone's there to fix them.
> >>>>> deployment - do the best you can - log what goes wrong
> >>>>>
> >>>>> and see a setting much more in this idea.
> >>>>>
> >>>>>
> >>>>>
> >>>>> btw: this is also why I always develop with the UberspectTestImpl and
> >>>>> rather
> >>>>> think that it should be default Uberspect, while currently it is only
> >>> in
> >>>>> the
> >>>>> test classes.
> >>>>>
> >>>>> Llewellyn.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> >>>>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Forio Business Simulations
> >>>>
> >>>> Will Glass-Husain
> >>>> wglass@forio.com
> >>>> www.forio.com
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >>>
> >>>
> >>
> >> --
> >> Forio Business Simulations
> >>
> >> Will Glass-Husain
> >> wglass@forio.com
> >> www.forio.com
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: handling macro argument errors
Posted by Will Glass-Husain <wg...@forio.com>.
Hi Llewellyn,
Great ideas - I agree with much of what you say.
We should start a bug or a Wiki page to list out all the cases for
better error messages.
I worry about having lots of silly config messages "ignore this
error". We almost need one "ignore backwards compatible errors" that
covers VelociMacro arguments, bad #includes, etc.
WILL
On 3/22/06, Llewellyn Falco <is...@setgame.com> wrote:
> 1) I think it's a GREAT idea to explain options for avoiding an exception in
> the exception.
>
> 2)
> I agree that there are 2 paradigms, the current (work as best as you can,
> even if it is wrong) and what we are looking at as the new (fail loudly if
> it isn't right).
>
> and I understand the desire for backwards compatibility. and agree that
> there should be a way to achieve it.
> however, I would like to look this statement I bit closer.
>
> >I've personally got hundreds of templates in production and support users
> >with hundreds more. Say 5% of those templates have this error. (It's not
> >hard to make -- note that the Velocity test suite for Anakia contains this
> >error). All of a sudden I have tens of templates, scattered all over the
> >place that suddenly cause errors
>
> In my mind this is a lot of proof the log files don't really work.
> because if they did, the error's would go away. and without knowing how the
> macro's work, it's hard to tell if the breaking is important, but I tend to
> put parameters in a function because they are to be used, and therefore
> would assume it would be important at least in some situations.
>
> -------------------------------------------------------------------------------------
>
> My point is this. As the Velocity community continues to grow, I would like
> to avoid these things. I would like to make it easier to configure Velocity,
> easier to make it work, easier to debug, so future code does not suffer the
> same as the past. to this end, I once again push for the default settings
> (because new users don't usually change those for a while) to throw errors
> when you do something wrong. Error's that tell you
> 1) what went wrong
> 2) where it went wrong
> 3) what you tried.
> 4) what was possible ?
> 5) suggestions on how to fix it?
>
> for example.
> (not sure if this is still true in the latest version, as my working version
> is a couple of versions behind)
> if a template is not found in a #parse("template2") call, it is ignored.
> so
> 123#parse("unknownTemplate.vm")567
> will output -> 123567
>
> better would be it throws and error ("unknownTemplate").
>
> better still
> unknow template line 1, col 4 in yourTemplate.vm
>
> better still
> unknow template 'unknownTemplate.vm'
> line 1, col 4 in yourTemplate.vm
>
> better still
> couldn't find template 'unknownTemplate.vm'
> at line 1, col 4 in yourTemplate.vm
> from resource loaders:
> file resource load [path = c:\code]
> file resource load [path = c:\templatesss]
>
>
> best
> couldn't find template 'unknownTemplate.vm'
> at line 1, col 4 in yourTemplate.vm
> from resource loaders:
> file resource load [path = c:\code]
> file resource load [path = c:\templatesss]
>
> To ignore this error set the parameter
> 'velocity.errors.ignoreUnknownTemplate' to false
>
>
> -------------------------------------------------------------------------------------
> These type of errors really help to make debugging easy (for example, i
> would see here that i misspelled templates)
> which makes the life a bit easier for us experienced users.
> but can make a world of difference to a newbie, and that difference can be
> the difference between continuing with the product, or just being
> frustrated.
>
> also the parameter being written lines away from the checking of the
> parameter helps to ensure that it is correct (as opposed to documents
> away in the manual or code example)
>
> so anyways, that concludes my rant :-)
>
> Llewellyn.
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: handling macro argument errors
Posted by Llewellyn Falco <is...@setgame.com>.
1) I think it's a GREAT idea to explain options for avoiding an exception in
the exception.
2)
I agree that there are 2 paradigms, the current (work as best as you can,
even if it is wrong) and what we are looking at as the new (fail loudly if
it isn't right).
and I understand the desire for backwards compatibility. and agree that
there should be a way to achieve it.
however, I would like to look this statement I bit closer.
>I've personally got hundreds of templates in production and support users
>with hundreds more. Say 5% of those templates have this error. (It's not
>hard to make -- note that the Velocity test suite for Anakia contains this
>error). All of a sudden I have tens of templates, scattered all over the
>place that suddenly cause errors
In my mind this is a lot of proof the log files don't really work.
because if they did, the error's would go away. and without knowing how the
macro's work, it's hard to tell if the breaking is important, but I tend to
put parameters in a function because they are to be used, and therefore
would assume it would be important at least in some situations.
-------------------------------------------------------------------------------------
My point is this. As the Velocity community continues to grow, I would like
to avoid these things. I would like to make it easier to configure Velocity,
easier to make it work, easier to debug, so future code does not suffer the
same as the past. to this end, I once again push for the default settings
(because new users don't usually change those for a while) to throw errors
when you do something wrong. Error's that tell you
1) what went wrong
2) where it went wrong
3) what you tried.
4) what was possible ?
5) suggestions on how to fix it?
for example.
(not sure if this is still true in the latest version, as my working version
is a couple of versions behind)
if a template is not found in a #parse("template2") call, it is ignored.
so
123#parse("unknownTemplate.vm")567
will output -> 123567
better would be it throws and error ("unknownTemplate").
better still
unknow template line 1, col 4 in yourTemplate.vm
better still
unknow template 'unknownTemplate.vm'
line 1, col 4 in yourTemplate.vm
better still
couldn't find template 'unknownTemplate.vm'
at line 1, col 4 in yourTemplate.vm
from resource loaders:
file resource load [path = c:\code]
file resource load [path = c:\templatesss]
best
couldn't find template 'unknownTemplate.vm'
at line 1, col 4 in yourTemplate.vm
from resource loaders:
file resource load [path = c:\code]
file resource load [path = c:\templatesss]
To ignore this error set the parameter
'velocity.errors.ignoreUnknownTemplate' to false
-------------------------------------------------------------------------------------
These type of errors really help to make debugging easy (for example, i
would see here that i misspelled templates)
which makes the life a bit easier for us experienced users.
but can make a world of difference to a newbie, and that difference can be
the difference between continuing with the product, or just being
frustrated.
also the parameter being written lines away from the checking of the
parameter helps to ensure that it is correct (as opposed to documents
away in the manual or code example)
so anyways, that concludes my rant :-)
Llewellyn.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: handling macro argument errors
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Nathan Bubna wrote:
> If i may be forgiven one last push... :)
>
> Let's keep the story straight--you wouldn't have to edit the old apps
> to make them work with 1.5. You just have to set the config property,
> not really a great burden. We could even make the message with the
> thrown exception point out the new config property, so that those who
> don't read change logs or release notes will have no problem figuring
> out what's going on.
That means you can't just upgrade and have things work. You have to
upgrade and reconfigure.
I'd make it work like 1.4 by default, turn on new behavior w/ a switch,
and fix it in 2.0
geir
>
> On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
>> I feel strongly about this.
>>
>> I've personally got hundreds of templates in production and support users
>> with hundreds more. Say 5% of those templates have this error. (It's not
>> hard to make -- note that the Velocity test suite for Anakia contains this
>> error). All of a sudden I have tens of templates, scattered all over the
>> place that suddenly cause errors. All of those apps work right now- why do
>> I want them to fail? Anything that requires me to edit old apps to make
>> Velocity 1.5 work is not backwards compatible. (and will retard adoption of
>> 1.5).
>>
>> It would have been nicer if this had always generated an error. For new
>> apps this is better. But for old apps it is actively harmful to change
>> this. So let's make this a config option and turn it on by default for 2.0
>> .
>>
>> WILL
>>
>> On 3/21/06, Nathan Bubna <nb...@gmail.com> wrote:
>>> On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
>>>> I'm starting to agree with you, Llwellyn. Though I don't think we
>>> should
>>>> change the behavior of the templates for existing users.
>>> even if the behavior is buggy/broken? it's not like the extra or
>>> missing arguments were doing anything functionally. throwing an
>>> exception, however, will add functionality (as Malcom demonstrated.
>>> we already warned that their macro call was broken in the logs, i
>>> think it is fair to escalate that to an exception, especially if we
>>> provide a config option to log instead of throw an exception.
>>>
>>> of course, if you feel strongly about this, i won't -1 a log-only
>>> default, and i'll let them that do the work implement it the way they
>>> want :). it's just my opinion; i won't be dogmatic on it. :)
>>>
>>>> WILL
>>>>
>>>> On 3/21/06, Llewellyn Falco <is...@setgame.com> wrote:
>>>>>
>>>>>> Personally, i feel that templates whose macro calls don't match up
>>> to
>>>>>> the macro definitions are *already* broken.
>>>>> this is my general thought on the whole thing too.
>>>>>
>>>>> and as we deal in financial transactions, I take a general view of
>>>>> it is better not to show something than to show something wrong.
>>>>>
>>>>> however, I can understand that in an entertainment situation you might
>>>>> have
>>>>> the exact opposite view.
>>>>> again though, I think this goes back to a 2 modes of running.
>>>>>
>>>>> development - always halt on errors - someone's there to fix them.
>>>>> deployment - do the best you can - log what goes wrong
>>>>>
>>>>> and see a setting much more in this idea.
>>>>>
>>>>>
>>>>>
>>>>> btw: this is also why I always develop with the UberspectTestImpl and
>>>>> rather
>>>>> think that it should be default Uberspect, while currently it is only
>>> in
>>>>> the
>>>>> test classes.
>>>>>
>>>>> Llewellyn.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>>>>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>
>>>> --
>>>> Forio Business Simulations
>>>>
>>>> Will Glass-Husain
>>>> wglass@forio.com
>>>> www.forio.com
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>>
>>>
>>
>> --
>> Forio Business Simulations
>>
>> Will Glass-Husain
>> wglass@forio.com
>> www.forio.com
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: handling macro argument errors
Posted by Will Glass-Husain <wg...@forio.com>.
hmm... if it's in the documentation, log AND exception message, that doesn't
seem so bad...
I'll pause here for a day to see if anyone else wants to defend my side.
WILL
On 3/21/06, Nathan Bubna <nb...@gmail.com> wrote:
>
> On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> > Thanks, Nathan, that's a good way to put it. All people need to do is
> set
> > a config option to make existing apps work.
> >
> > The challenge is getting 100% of upgrading users to find this
> info. We'd
> > need to highlight this in a README, in the docs, and answer tech support
> > questions on this. And there may still users who miss it. Yes, it
> might be
> > their own fault, but that's still a dent in our rep for those users.
>
> Put the info right into the exception message, as i suggested. Then
> the users who need can't miss it! Something like the following should
> do the trick:
>
> ParseErrorException: Your macro call contained the wrong number of
> arguments. To allow this behavior, set
> 'velocimacro.break.on.wrong.argument.count = false' in your
> velocity.properties.
>
> i can have some sympathy for those who don't read the manual, change
> logs, readmes, or release notes. i have no sympathy for those who
> don't read exception messages and then whine about the exception.
> part of that is because i've never heard of such a person. :)
>
> > (we can balance this against tech support for new users who should see
> macro
> > errors but don't. pretty minimal to date).
> >
> > For other similar issues (e.g. allowing set's to set null's) we've made
> the
> > config default to old behavior. Minor though this seems, it's enough of
> an
> > exception I'd like to hear from other committers before giving up our
> goal
> > of 100% "drop-in" replacement.
>
> Just for the record, i have never understood that goal to include
> buggy behavior. :) so i don't think we'd be dropping the goal at all.
>
> > WILL
> >
> > On 3/21/06, Nathan Bubna <nb...@gmail.com> wrote:
> > >
> > > If i may be forgiven one last push... :)
> > >
> > > Let's keep the story straight--you wouldn't have to edit the old apps
> > > to make them work with 1.5. You just have to set the config property,
> > > not really a great burden. We could even make the message with the
> > > thrown exception point out the new config property, so that those who
> > > don't read change logs or release notes will have no problem figuring
> > > out what's going on.
> > >
> > > On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> > > > I feel strongly about this.
> > > >
> > > > I've personally got hundreds of templates in production and support
> > > users
> > > > with hundreds more. Say 5% of those templates have this
> error. (It's
> > > not
> > > > hard to make -- note that the Velocity test suite for Anakia
> contains
> > > this
> > > > error). All of a sudden I have tens of templates, scattered all
> over
> > > the
> > > > place that suddenly cause errors. All of those apps work right now-
> why
> > > do
> > > > I want them to fail? Anything that requires me to edit old apps to
> make
> > > > Velocity 1.5 work is not backwards compatible. (and will retard
> > > adoption of
> > > > 1.5).
> > > >
> > > > It would have been nicer if this had always generated an error. For
> new
> > > > apps this is better. But for old apps it is actively harmful to
> change
> > > > this. So let's make this a config option and turn it on by default
> for
> > > 2.0
> > > > .
> > > >
> > > > WILL
> > > >
> > > > On 3/21/06, Nathan Bubna <nb...@gmail.com> wrote:
> > > > >
> > > > > On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> > > > > > I'm starting to agree with you, Llwellyn. Though I don't think
> we
> > > > > should
> > > > > > change the behavior of the templates for existing users.
> > > > >
> > > > > even if the behavior is buggy/broken? it's not like the extra or
> > > > > missing arguments were doing anything functionally. throwing an
> > > > > exception, however, will add functionality (as Malcom
> demonstrated.
> > > > > we already warned that their macro call was broken in the logs, i
> > > > > think it is fair to escalate that to an exception, especially if
> we
> > > > > provide a config option to log instead of throw an exception.
> > > > >
> > > > > of course, if you feel strongly about this, i won't -1 a log-only
> > > > > default, and i'll let them that do the work implement it the way
> they
> > > > > want :). it's just my opinion; i won't be dogmatic on it. :)
> > > > >
> > > > > >
> > > > > > WILL
> > > > > >
> > > > > > On 3/21/06, Llewellyn Falco <is...@setgame.com> wrote:
> > > > > > >
> > > > > > >
> > > > > > > > Personally, i feel that templates whose macro calls don't
> match
> > > up
> > > > > to
> > > > > > > > the macro definitions are *already* broken.
> > > > > > >
> > > > > > > this is my general thought on the whole thing too.
> > > > > > >
> > > > > > > and as we deal in financial transactions, I take a general
> view of
> > > > > > > it is better not to show something than to show something
> wrong.
> > > > > > >
> > > > > > > however, I can understand that in an entertainment situation
> you
> > > might
> > > > > > > have
> > > > > > > the exact opposite view.
> > > > > > > again though, I think this goes back to a 2 modes of running.
> > > > > > >
> > > > > > > development - always halt on errors - someone's there to fix
> them.
> > > > > > > deployment - do the best you can - log what goes wrong
> > > > > > >
> > > > > > > and see a setting much more in this idea.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > btw: this is also why I always develop with the
> UberspectTestImpl
> > > and
> > > > > > > rather
> > > > > > > think that it should be default Uberspect, while currently it
> is
> > > only
> > > > > in
> > > > > > > the
> > > > > > > test classes.
> > > > > > >
> > > > > > > Llewellyn.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
> > > velocity-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail:
> > > velocity-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Forio Business Simulations
> > > > > >
> > > > > > Will Glass-Husain
> > > > > > wglass@forio.com
> > > > > > www.forio.com
> > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> velocity-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> velocity-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Forio Business Simulations
> > > >
> > > > Will Glass-Husain
> > > > wglass@forio.com
> > > > www.forio.com
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > --
> > Forio Business Simulations
> >
> > Will Glass-Husain
> > wglass@forio.com
> > www.forio.com
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
Re: handling macro argument errors
Posted by Nathan Bubna <nb...@gmail.com>.
On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> Thanks, Nathan, that's a good way to put it. All people need to do is set
> a config option to make existing apps work.
>
> The challenge is getting 100% of upgrading users to find this info. We'd
> need to highlight this in a README, in the docs, and answer tech support
> questions on this. And there may still users who miss it. Yes, it might be
> their own fault, but that's still a dent in our rep for those users.
Put the info right into the exception message, as i suggested. Then
the users who need can't miss it! Something like the following should
do the trick:
ParseErrorException: Your macro call contained the wrong number of
arguments. To allow this behavior, set
'velocimacro.break.on.wrong.argument.count = false' in your
velocity.properties.
i can have some sympathy for those who don't read the manual, change
logs, readmes, or release notes. i have no sympathy for those who
don't read exception messages and then whine about the exception.
part of that is because i've never heard of such a person. :)
> (we can balance this against tech support for new users who should see macro
> errors but don't. pretty minimal to date).
>
> For other similar issues (e.g. allowing set's to set null's) we've made the
> config default to old behavior. Minor though this seems, it's enough of an
> exception I'd like to hear from other committers before giving up our goal
> of 100% "drop-in" replacement.
Just for the record, i have never understood that goal to include
buggy behavior. :) so i don't think we'd be dropping the goal at all.
> WILL
>
> On 3/21/06, Nathan Bubna <nb...@gmail.com> wrote:
> >
> > If i may be forgiven one last push... :)
> >
> > Let's keep the story straight--you wouldn't have to edit the old apps
> > to make them work with 1.5. You just have to set the config property,
> > not really a great burden. We could even make the message with the
> > thrown exception point out the new config property, so that those who
> > don't read change logs or release notes will have no problem figuring
> > out what's going on.
> >
> > On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> > > I feel strongly about this.
> > >
> > > I've personally got hundreds of templates in production and support
> > users
> > > with hundreds more. Say 5% of those templates have this error. (It's
> > not
> > > hard to make -- note that the Velocity test suite for Anakia contains
> > this
> > > error). All of a sudden I have tens of templates, scattered all over
> > the
> > > place that suddenly cause errors. All of those apps work right now- why
> > do
> > > I want them to fail? Anything that requires me to edit old apps to make
> > > Velocity 1.5 work is not backwards compatible. (and will retard
> > adoption of
> > > 1.5).
> > >
> > > It would have been nicer if this had always generated an error. For new
> > > apps this is better. But for old apps it is actively harmful to change
> > > this. So let's make this a config option and turn it on by default for
> > 2.0
> > > .
> > >
> > > WILL
> > >
> > > On 3/21/06, Nathan Bubna <nb...@gmail.com> wrote:
> > > >
> > > > On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> > > > > I'm starting to agree with you, Llwellyn. Though I don't think we
> > > > should
> > > > > change the behavior of the templates for existing users.
> > > >
> > > > even if the behavior is buggy/broken? it's not like the extra or
> > > > missing arguments were doing anything functionally. throwing an
> > > > exception, however, will add functionality (as Malcom demonstrated.
> > > > we already warned that their macro call was broken in the logs, i
> > > > think it is fair to escalate that to an exception, especially if we
> > > > provide a config option to log instead of throw an exception.
> > > >
> > > > of course, if you feel strongly about this, i won't -1 a log-only
> > > > default, and i'll let them that do the work implement it the way they
> > > > want :). it's just my opinion; i won't be dogmatic on it. :)
> > > >
> > > > >
> > > > > WILL
> > > > >
> > > > > On 3/21/06, Llewellyn Falco <is...@setgame.com> wrote:
> > > > > >
> > > > > >
> > > > > > > Personally, i feel that templates whose macro calls don't match
> > up
> > > > to
> > > > > > > the macro definitions are *already* broken.
> > > > > >
> > > > > > this is my general thought on the whole thing too.
> > > > > >
> > > > > > and as we deal in financial transactions, I take a general view of
> > > > > > it is better not to show something than to show something wrong.
> > > > > >
> > > > > > however, I can understand that in an entertainment situation you
> > might
> > > > > > have
> > > > > > the exact opposite view.
> > > > > > again though, I think this goes back to a 2 modes of running.
> > > > > >
> > > > > > development - always halt on errors - someone's there to fix them.
> > > > > > deployment - do the best you can - log what goes wrong
> > > > > >
> > > > > > and see a setting much more in this idea.
> > > > > >
> > > > > >
> > > > > >
> > > > > > btw: this is also why I always develop with the UberspectTestImpl
> > and
> > > > > > rather
> > > > > > think that it should be default Uberspect, while currently it is
> > only
> > > > in
> > > > > > the
> > > > > > test classes.
> > > > > >
> > > > > > Llewellyn.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > velocity-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail:
> > velocity-dev-help@jakarta.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Forio Business Simulations
> > > > >
> > > > > Will Glass-Husain
> > > > > wglass@forio.com
> > > > > www.forio.com
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Forio Business Simulations
> > >
> > > Will Glass-Husain
> > > wglass@forio.com
> > > www.forio.com
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> Forio Business Simulations
>
> Will Glass-Husain
> wglass@forio.com
> www.forio.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: handling macro argument errors
Posted by Will Glass-Husain <wg...@forio.com>.
Thanks, Nathan, that's a good way to put it. All people need to do is set
a config option to make existing apps work.
The challenge is getting 100% of upgrading users to find this info. We'd
need to highlight this in a README, in the docs, and answer tech support
questions on this. And there may still users who miss it. Yes, it might be
their own fault, but that's still a dent in our rep for those users.
(we can balance this against tech support for new users who should see macro
errors but don't. pretty minimal to date).
For other similar issues (e.g. allowing set's to set null's) we've made the
config default to old behavior. Minor though this seems, it's enough of an
exception I'd like to hear from other committers before giving up our goal
of 100% "drop-in" replacement.
WILL
On 3/21/06, Nathan Bubna <nb...@gmail.com> wrote:
>
> If i may be forgiven one last push... :)
>
> Let's keep the story straight--you wouldn't have to edit the old apps
> to make them work with 1.5. You just have to set the config property,
> not really a great burden. We could even make the message with the
> thrown exception point out the new config property, so that those who
> don't read change logs or release notes will have no problem figuring
> out what's going on.
>
> On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> > I feel strongly about this.
> >
> > I've personally got hundreds of templates in production and support
> users
> > with hundreds more. Say 5% of those templates have this error. (It's
> not
> > hard to make -- note that the Velocity test suite for Anakia contains
> this
> > error). All of a sudden I have tens of templates, scattered all over
> the
> > place that suddenly cause errors. All of those apps work right now- why
> do
> > I want them to fail? Anything that requires me to edit old apps to make
> > Velocity 1.5 work is not backwards compatible. (and will retard
> adoption of
> > 1.5).
> >
> > It would have been nicer if this had always generated an error. For new
> > apps this is better. But for old apps it is actively harmful to change
> > this. So let's make this a config option and turn it on by default for
> 2.0
> > .
> >
> > WILL
> >
> > On 3/21/06, Nathan Bubna <nb...@gmail.com> wrote:
> > >
> > > On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> > > > I'm starting to agree with you, Llwellyn. Though I don't think we
> > > should
> > > > change the behavior of the templates for existing users.
> > >
> > > even if the behavior is buggy/broken? it's not like the extra or
> > > missing arguments were doing anything functionally. throwing an
> > > exception, however, will add functionality (as Malcom demonstrated.
> > > we already warned that their macro call was broken in the logs, i
> > > think it is fair to escalate that to an exception, especially if we
> > > provide a config option to log instead of throw an exception.
> > >
> > > of course, if you feel strongly about this, i won't -1 a log-only
> > > default, and i'll let them that do the work implement it the way they
> > > want :). it's just my opinion; i won't be dogmatic on it. :)
> > >
> > > >
> > > > WILL
> > > >
> > > > On 3/21/06, Llewellyn Falco <is...@setgame.com> wrote:
> > > > >
> > > > >
> > > > > > Personally, i feel that templates whose macro calls don't match
> up
> > > to
> > > > > > the macro definitions are *already* broken.
> > > > >
> > > > > this is my general thought on the whole thing too.
> > > > >
> > > > > and as we deal in financial transactions, I take a general view of
> > > > > it is better not to show something than to show something wrong.
> > > > >
> > > > > however, I can understand that in an entertainment situation you
> might
> > > > > have
> > > > > the exact opposite view.
> > > > > again though, I think this goes back to a 2 modes of running.
> > > > >
> > > > > development - always halt on errors - someone's there to fix them.
> > > > > deployment - do the best you can - log what goes wrong
> > > > >
> > > > > and see a setting much more in this idea.
> > > > >
> > > > >
> > > > >
> > > > > btw: this is also why I always develop with the UberspectTestImpl
> and
> > > > > rather
> > > > > think that it should be default Uberspect, while currently it is
> only
> > > in
> > > > > the
> > > > > test classes.
> > > > >
> > > > > Llewellyn.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> velocity-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> velocity-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Forio Business Simulations
> > > >
> > > > Will Glass-Husain
> > > > wglass@forio.com
> > > > www.forio.com
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > --
> > Forio Business Simulations
> >
> > Will Glass-Husain
> > wglass@forio.com
> > www.forio.com
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
Re: handling macro argument errors
Posted by Nathan Bubna <nb...@gmail.com>.
If i may be forgiven one last push... :)
Let's keep the story straight--you wouldn't have to edit the old apps
to make them work with 1.5. You just have to set the config property,
not really a great burden. We could even make the message with the
thrown exception point out the new config property, so that those who
don't read change logs or release notes will have no problem figuring
out what's going on.
On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> I feel strongly about this.
>
> I've personally got hundreds of templates in production and support users
> with hundreds more. Say 5% of those templates have this error. (It's not
> hard to make -- note that the Velocity test suite for Anakia contains this
> error). All of a sudden I have tens of templates, scattered all over the
> place that suddenly cause errors. All of those apps work right now- why do
> I want them to fail? Anything that requires me to edit old apps to make
> Velocity 1.5 work is not backwards compatible. (and will retard adoption of
> 1.5).
>
> It would have been nicer if this had always generated an error. For new
> apps this is better. But for old apps it is actively harmful to change
> this. So let's make this a config option and turn it on by default for 2.0
> .
>
> WILL
>
> On 3/21/06, Nathan Bubna <nb...@gmail.com> wrote:
> >
> > On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> > > I'm starting to agree with you, Llwellyn. Though I don't think we
> > should
> > > change the behavior of the templates for existing users.
> >
> > even if the behavior is buggy/broken? it's not like the extra or
> > missing arguments were doing anything functionally. throwing an
> > exception, however, will add functionality (as Malcom demonstrated.
> > we already warned that their macro call was broken in the logs, i
> > think it is fair to escalate that to an exception, especially if we
> > provide a config option to log instead of throw an exception.
> >
> > of course, if you feel strongly about this, i won't -1 a log-only
> > default, and i'll let them that do the work implement it the way they
> > want :). it's just my opinion; i won't be dogmatic on it. :)
> >
> > >
> > > WILL
> > >
> > > On 3/21/06, Llewellyn Falco <is...@setgame.com> wrote:
> > > >
> > > >
> > > > > Personally, i feel that templates whose macro calls don't match up
> > to
> > > > > the macro definitions are *already* broken.
> > > >
> > > > this is my general thought on the whole thing too.
> > > >
> > > > and as we deal in financial transactions, I take a general view of
> > > > it is better not to show something than to show something wrong.
> > > >
> > > > however, I can understand that in an entertainment situation you might
> > > > have
> > > > the exact opposite view.
> > > > again though, I think this goes back to a 2 modes of running.
> > > >
> > > > development - always halt on errors - someone's there to fix them.
> > > > deployment - do the best you can - log what goes wrong
> > > >
> > > > and see a setting much more in this idea.
> > > >
> > > >
> > > >
> > > > btw: this is also why I always develop with the UberspectTestImpl and
> > > > rather
> > > > think that it should be default Uberspect, while currently it is only
> > in
> > > > the
> > > > test classes.
> > > >
> > > > Llewellyn.
> > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Forio Business Simulations
> > >
> > > Will Glass-Husain
> > > wglass@forio.com
> > > www.forio.com
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> Forio Business Simulations
>
> Will Glass-Husain
> wglass@forio.com
> www.forio.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: handling macro argument errors
Posted by Will Glass-Husain <wg...@forio.com>.
I feel strongly about this.
I've personally got hundreds of templates in production and support users
with hundreds more. Say 5% of those templates have this error. (It's not
hard to make -- note that the Velocity test suite for Anakia contains this
error). All of a sudden I have tens of templates, scattered all over the
place that suddenly cause errors. All of those apps work right now- why do
I want them to fail? Anything that requires me to edit old apps to make
Velocity 1.5 work is not backwards compatible. (and will retard adoption of
1.5).
It would have been nicer if this had always generated an error. For new
apps this is better. But for old apps it is actively harmful to change
this. So let's make this a config option and turn it on by default for 2.0
.
WILL
On 3/21/06, Nathan Bubna <nb...@gmail.com> wrote:
>
> On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> > I'm starting to agree with you, Llwellyn. Though I don't think we
> should
> > change the behavior of the templates for existing users.
>
> even if the behavior is buggy/broken? it's not like the extra or
> missing arguments were doing anything functionally. throwing an
> exception, however, will add functionality (as Malcom demonstrated.
> we already warned that their macro call was broken in the logs, i
> think it is fair to escalate that to an exception, especially if we
> provide a config option to log instead of throw an exception.
>
> of course, if you feel strongly about this, i won't -1 a log-only
> default, and i'll let them that do the work implement it the way they
> want :). it's just my opinion; i won't be dogmatic on it. :)
>
> >
> > WILL
> >
> > On 3/21/06, Llewellyn Falco <is...@setgame.com> wrote:
> > >
> > >
> > > > Personally, i feel that templates whose macro calls don't match up
> to
> > > > the macro definitions are *already* broken.
> > >
> > > this is my general thought on the whole thing too.
> > >
> > > and as we deal in financial transactions, I take a general view of
> > > it is better not to show something than to show something wrong.
> > >
> > > however, I can understand that in an entertainment situation you might
> > > have
> > > the exact opposite view.
> > > again though, I think this goes back to a 2 modes of running.
> > >
> > > development - always halt on errors - someone's there to fix them.
> > > deployment - do the best you can - log what goes wrong
> > >
> > > and see a setting much more in this idea.
> > >
> > >
> > >
> > > btw: this is also why I always develop with the UberspectTestImpl and
> > > rather
> > > think that it should be default Uberspect, while currently it is only
> in
> > > the
> > > test classes.
> > >
> > > Llewellyn.
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > --
> > Forio Business Simulations
> >
> > Will Glass-Husain
> > wglass@forio.com
> > www.forio.com
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
Re: handling macro argument errors
Posted by Nathan Bubna <nb...@gmail.com>.
On 3/21/06, Will Glass-Husain <wg...@forio.com> wrote:
> I'm starting to agree with you, Llwellyn. Though I don't think we should
> change the behavior of the templates for existing users.
even if the behavior is buggy/broken? it's not like the extra or
missing arguments were doing anything functionally. throwing an
exception, however, will add functionality (as Malcom demonstrated.
we already warned that their macro call was broken in the logs, i
think it is fair to escalate that to an exception, especially if we
provide a config option to log instead of throw an exception.
of course, if you feel strongly about this, i won't -1 a log-only
default, and i'll let them that do the work implement it the way they
want :). it's just my opinion; i won't be dogmatic on it. :)
>
> WILL
>
> On 3/21/06, Llewellyn Falco <is...@setgame.com> wrote:
> >
> >
> > > Personally, i feel that templates whose macro calls don't match up to
> > > the macro definitions are *already* broken.
> >
> > this is my general thought on the whole thing too.
> >
> > and as we deal in financial transactions, I take a general view of
> > it is better not to show something than to show something wrong.
> >
> > however, I can understand that in an entertainment situation you might
> > have
> > the exact opposite view.
> > again though, I think this goes back to a 2 modes of running.
> >
> > development - always halt on errors - someone's there to fix them.
> > deployment - do the best you can - log what goes wrong
> >
> > and see a setting much more in this idea.
> >
> >
> >
> > btw: this is also why I always develop with the UberspectTestImpl and
> > rather
> > think that it should be default Uberspect, while currently it is only in
> > the
> > test classes.
> >
> > Llewellyn.
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> Forio Business Simulations
>
> Will Glass-Husain
> wglass@forio.com
> www.forio.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: handling macro argument errors
Posted by Will Glass-Husain <wg...@forio.com>.
I'm starting to agree with you, Llwellyn. Though I don't think we should
change the behavior of the templates for existing users.
WILL
On 3/21/06, Llewellyn Falco <is...@setgame.com> wrote:
>
>
> > Personally, i feel that templates whose macro calls don't match up to
> > the macro definitions are *already* broken.
>
> this is my general thought on the whole thing too.
>
> and as we deal in financial transactions, I take a general view of
> it is better not to show something than to show something wrong.
>
> however, I can understand that in an entertainment situation you might
> have
> the exact opposite view.
> again though, I think this goes back to a 2 modes of running.
>
> development - always halt on errors - someone's there to fix them.
> deployment - do the best you can - log what goes wrong
>
> and see a setting much more in this idea.
>
>
>
> btw: this is also why I always develop with the UberspectTestImpl and
> rather
> think that it should be default Uberspect, while currently it is only in
> the
> test classes.
>
> Llewellyn.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
Re: handling macro argument errors
Posted by Llewellyn Falco <is...@setgame.com>.
> Personally, i feel that templates whose macro calls don't match up to
> the macro definitions are *already* broken.
this is my general thought on the whole thing too.
and as we deal in financial transactions, I take a general view of
it is better not to show something than to show something wrong.
however, I can understand that in an entertainment situation you might have
the exact opposite view.
again though, I think this goes back to a 2 modes of running.
development - always halt on errors - someone's there to fix them.
deployment - do the best you can - log what goes wrong
and see a setting much more in this idea.
btw: this is also why I always develop with the UberspectTestImpl and rather
think that it should be default Uberspect, while currently it is only in the
test classes.
Llewellyn.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: handling macro argument errors
Posted by Nathan Bubna <nb...@gmail.com>.
Personally, i feel that templates whose macro calls don't match up to
the macro definitions are *already* broken. The fact that we are
escalating the response to that brokenness doesn't feel wrong to me.
Previously they were warned in the logs (think of it as deprecation)
and now the flexibility should by default be removed.
In other words, i think it should throw an exception by default in
1.5. But if you really want to provide a work-around for those with
broken templates to leave them broken, then a runtime config property
is fine with me. i would suggest a property key that fits the pattern
of the other velocimacro config options and, of course, a default
setting of "true".
velocimacro.break.on.invalid.argument.count = true
i like the idea of having a "strict" mode property for unresolvable
references, but i don't see invalid velocimacro calls as parallel to
that. the former is a issue with interaction between Model and View,
the latter is a strictly View rendering issue (and therefore a syntax
problem IMHO).
On 3/20/06, Will Glass-Husain <wg...@forio.com> wrote:
> Hi,
>
> Wanted to ask for some quick feedback on VELOCITY-435. One of the
> directions for Velocity 1.5 that's emerged is better error handling. Most
> stuff that used to be logged can now be trapped and reported. One exception
> is macro callswith an invalid numbers of arguments. Error messages are
> buried in a log, there's no way to trap them and make them more visible.
> Example error:
>
> #macro(foo $a) $a #end
> #foo("test1" "test2")
>
> Ideally, this would throw a ParseErrorException, but it can't due to
> backwards compatibility. (lots of existing templates with this problem would
> break). This would enable functionality like this (courtesy of Malcolm
> Edgars)
> http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink#
>
> Some solutions - any feedback?
>
> (1) yet another configuration option
> runtime.macros.strict = true
>
> (2) yet another event handler. I've already got an
> "InvalidReferenceEventHandler" in progress, this could be a new method for
> that.
>
> (3) something more creative?
>
> Thanks, WILL
>
> --
> Forio Business Simulations
>
> Will Glass-Husain
> wglass@forio.com
> www.forio.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: handling macro argument errors
Posted by Malcolm Edgar <ma...@gmail.com>.
I am not feeling all that creative at the moment, so I am +1 on option 1.
In fact i think there should be a strict all mode config option which
covers all the errors: invalid references, invalid macros, null #set
strict.all.mode = true
I think a lot of people would use this option, would be simple to
configure, and I think is a more Java centric way of working. If you
stuff something up in your template, it breaks and you work through
your errors.
regards Malcolm Edgar
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org