Hi,
We recently made some changes to our software to use just a single
VelocityEngine as per recommendations on this group.
We ran into an issue where macros were all of the sudden being shared
across template renders because we had not
specified: velocimacro.permissions.allow.inline.local.scope
I think that Velocity has one global hash table for macros from the *.vm
libraries and that is more or less static for the life time of the Velocity
engine.
I wish there there was a mechanism to control the list of the *.vm files
and their order of lookup for each individual merge (thread). This w
Thanks for the input.
What we're seeing is that Velocity seems to be holding on to a lot
of org.apache.velocity.runtime.parser.Token objects (around 5 million). We
allow people to write arbitrary Velocity templates in our system and are
evaluating them with:
VelocityEngine.evaluate(Context contex
On Mon, Jul 30, 2012 at 1:30 PM, Bradley Wagner
wrote:
> Thanks for the input.
>
> What we're seeing is that Velocity seems to be holding on to a lot
> of org.apache.velocity.runtime.parser.Token objects (around 5 million). We
> allow people to write arbitrary Velocity templates in our system and
Nathan,
Tokens are referenced by org.apache.velocity.runtime.parser.node.ASTReference
which seem to be referenced by arrays of
org.apache.velocity.runtime.parser.node.Nodes.
Most of the classes referencing these things are AST classes in the
org.apache.velocity.runtime.parser.node package.
Here'
And you're sure you're only using VelocityEngine.evaluate? Not
loading templates through the resource loader? Or are you doing both?
On Mon, Jul 30, 2012 at 2:51 PM, Bradley Wagner
wrote:
> Nathan,
>
> Tokens are referenced by
> org.apache.velocity.runtime.parser.node.ASTReference which seem to
Doing both. In the other case we're using a classpath resource loader to
evaluate templates like this:
VelocityContext = ... a context that we're building each time ...
VelocityEngine engine = ... our single engine ...
Template template = engine.getTemplate(templatePath);
StringWriter writer = new
What do you use for logTag (template name) when you are using evaluate()?
On Tue, Jul 31, 2012 at 8:01 AM, Bradley Wagner
wrote:
> Doing both. In the other case we're using a classpath resource loader to
> evaluate templates like this:
>
> VelocityContext = ... a context that we're building each
A StringWriter:
String template = ... the string containing the dynamic template to
generate ...
// Get a template as stream.
StringWriter writer = new StringWriter();
StringReader reader = new StringReader(template);
// create a temporary template name
String tempTemplateName = "velocityTransform
Whoops, was misreading the API. It's actually that tempTemplateName
variable.
On Tue, Jul 31, 2012 at 11:21 AM, Bradley Wagner <
bradley.wag...@hannonhill.com> wrote:
> A StringWriter:
>
> String template = ... the string containing the dynamic template to
> generate ...
> // Get a template as st
I dunno. I keep casting about for possible explanations, but my
current rusty-ness with the Velocity codebase (haven't hacked on it
much in a couple years) is hampering me. At this point, all i can say
is that i'm not sure where the cached nodes are from, but i suspect
either your few ClasspathRe
It's not really a Velocity specific suggestion - I would just dump the heap
and trace the instances to the garbage collection roots. Eclipse MAT or
YourKit can do it as probably can a lot of other Java tools.
On Tue, Jul 31, 2012 at 11:37 AM, Bradley Wagner <
bradley.wag...@hannonhill.com> wrote:
Yea, we're starting to figure that out. It seems like it's the macro cache
that's growing and we have no way of clearing that cache or disabling it
altogether.
Any ideas there?
On Tue, Jul 31, 2012 at 1:39 PM, Alex Fedotov wrote:
> It's not really a Velocity specific suggestion - I would just d
On Tue, Jul 31, 2012 at 10:48 AM, Bradley Wagner
wrote:
> Yea, we're starting to figure that out. It seems like it's the macro cache
> that's growing and we have no way of clearing that cache or disabling it
> altogether.
>
> Any ideas there?
hmm. i haven't confirmed this and am rusty on the cod
14 matches
Mail list logo
