> Oops, more below.
Oops.
>
> I saw Template.java in the commits *after* I write this
> recommendation,
> but I *saw* it also does not have a finally block... So it should be
> added there too (grep for popCurrentTemplateName to be sure we got 'em
> all).
Thats true.
> >
> > Because the template name stack *isn't* really in the ica -
> it's in the
> > baseclass InternalContextBase of VelocityContext... (via
> > AbstractContext), so this would have accumulated...
> probably no harm,
> > but not right either.
>
> I still see no accumulation, since the
> VelocityContext/AbstractContext/
> InternalContextBase is instantiated newly on every Template.init()
> and Template.merge(). This instace (including template name stack) is
> discarded after the call.
No it's not. Why do you say that? Nothing says the app has to instantiate a new VelocityContext on every template init() / merge().
> Am I missing some magic?
Not magic at all...
> Somehow I havn't figured out where
> InternalContextBase is beeing instantiated (I never get the "Woo! no
> ICB" message). The Template.merger() seems to me its getting a plain
> VelocityContext (w/o a icb).
AbstractContext extends ICB
We want people to extend AC so that the internal stuff could be kept from use to use (say, you store it in the servlet session...)
but as people are free to do what they wish WRT Context impl, we need to make sure we take care of it also in the event they don't extend AC.
geir
>
> >
> > Good one.
>
> But yet need to analyze some more the overall mechanics of Vel.
>
> :) Christoph
>
