Re: Macros interfering with each other when caching turned on

Exactly right.

WILL

On Thu, Jun 7, 2012 at 9:22 AM, Steve O'Hara <[email protected]
> wrote:

> After looking through the code and following how macros are managed, I
> think I can answer my own question.
>
> It seems I need to set the following;
>
> velocimacro.permissions.allow.inline.local.scope=true
>
> Otherwise, the macros do indeed overwrite each other in a global namespace
> object.
>
>
>
> -----Original Message-----
> From: Steve O'Hara [mailto:[email protected]]
> Sent: 07 June 2012 16:22
> To: Velocity Users List
> Subject: RE: Macros interfering with each other when caching turned on
>
> Whoops, some more clarity......
>
> We use a custom resource loader that reads templates from a database.  It
> uses a database column to determine the last updated date so it can tell
> Velocity if the template needs reloading or not.
> We also use a pool of Velocity engines.
>
> The problem we have is to do with macros that are contained within an
> included template.
> For example, we have a template called x_dataservice.vm as follows;
>
> #parse("/database/x/lib_macros")
> #myMacro()
>
> The server is multi-tenancy where x is the customer name so we will have
> the following template y_dataservice.vm also;
>
> #parse("/database/y/lib_macros")
> #myMacro()
>
> Each lib_macros template is particular to each customer and will contain
> the same named macros but with different macro bodies.
>
> When caching is turned on, we get some sort of crossover between all the
> macros that share the same name, despite the fact that are loaded from
> different parents.
> To help eliminate our resource loader, I created a custom cache provider
> so that I could see that we are definitely hitting the correct templates.
>  I even changed the isSourceModified to always return true, to no avail.
> As soon as I turn caching off, it all works fine.
>
> I'm wondering if there is some sort of global macro cache because it
> doesn't seem to be caused at the template cache level.
>
> Any ideas?
>
> Thanks
> Steve
>
> ---------------------------------------------------------------------
> 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]
>
>