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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > >>> On 3/21/06, Will Glass-Husain <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:
> [EMAIL PROTECTED]
> > >>>>> For additional commands, e-mail:
> [EMAIL PROTECTED]
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> --
> > >>>> Forio Business Simulations
> > >>>>
> > >>>> Will Glass-Husain
> > >>>> [EMAIL PROTECTED]
> > >>>> www.forio.com
> > >>>>
> > >>>>
> > >>>
> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >>> For additional commands, e-mail:
> [EMAIL PROTECTED]
> > >>>
> > >>>
> > >>
> > >> --
> > >> Forio Business Simulations
> > >>
> > >> Will Glass-Husain
> > >> [EMAIL PROTECTED]
> > >> www.forio.com
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
