Raymond Auge wrote:
Thanks, Ray. Further comments and questions inline
Hey Steve,
I just re-purposed our entire Velocity usage to use StringResourceLoader
where before we were calling "evaluate()" ALL THE TIME... it was killer
on resources as you might imagine.
Hmm. I haven't noticed resource problems yet. I'm not calling
evaluate() now; I am using the VelocityEngine.mergeTemplate() approach.
Does mergeTemplate() have a greater or lesser resource-consumption
footprint than evaluate()?
So, this is the core code, it's very simple. So, we have a wrapper class
that is a Singleton that setups up a non-singleton VelocityEngine
instance
Exactly my setup.
(so that other apps can use their own version, all good). This
wrapper handles all the setup and configuration of Velocity. It also
provides these methods:
public boolean mergeTemplate(
String templateId, VelocityContext velocityContext, Writer
writer)
throws SystemException, IOException {
return mergeTemplate(templateId, null, velocityContext, writer);
}
public boolean mergeTemplate(
String templateId, String template, VelocityContext
velocityContext,
Writer writer)
throws SystemException, IOException {
try {
what's Validator()?
if (Validator.isNotNull(template) &&
!resourceExists(templateId)) {
StringResourceLoader.getRepository().putStringResource(
templateId, template);
if (_log.isDebugEnabled()) {
_log.debug(
"Added " + templateId + " to the Velocity
repository");
}
}
VelocityContextImpl velocityContextImpl =
(VelocityContextImpl)velocityContext;
return _velocityEngine.mergeTemplate(
templateId, StringPool.UTF8,
velocityContextImpl.getWrappedVelocityContext(),
writer);
}
catch (IOException ioe) {
throw ioe;
}
catch (Exception e) {
throw new SystemException(e);
}
}
So, as you can see, where we would have normally passed a string to
velocity's evaluate method, now we call
VelocityEngineUtil.mergeTemplate(scriptId, script, velocityContext, output);
and if the script is not in the repo, then add it. If it already got
added to the repo, then it will be found by name (scriptId) and
retrieved as a ready Template, which means you saved all the AST
re-parsing overhead.
I do have a question of my own. How many strings in the repository is
too many? Or an overall size. Can they have a time-to-live?
Ray
so I guess my question now boils down to what the tradeoffs are in
resource consumption between evaluate() and mergeTemplate(). I was
looking at StringResourceLoader more as a tool of development
convenience than as a tool of resource maximization, but it looks like
that may not be not its primary purpose.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
