velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve O'Hara" <>
Subject Aut-reloading Velocity when properties change
Date Sat, 06 Dec 2008 09:30:19 GMT
Hi Nathan,

Thanks for that.

In answer to your request for help, I can tell how we do it in our
extended VelocityViewServlet:-

protected void requestCleanup(HttpServletRequest objRequest,
HttpServletResponse objResponse, Context objContext) {

    // Check to see if we have been requested to reload the engine

    if (objContext.containsKey("ReloadVelocityEngine")) {
        VelocityEngine objNew = new VelocityEngine();
        try {
t(), objNew));
  "Velocity engine reloaded");
        catch (Exception e) {
            mobjLogger.warn("Problem reloading a new Velocity engine - "
+ getErrorMessage(e));

The Z_getApplicationProperties call is a private method that fills up
all the configuration settings.  As you can see, it's triggered by some
part of the application adding a flag to the context.

I guess parts of this would be replaced by getVelocityView but it's the
triggering of the code that would need to be a bit more generic.
We load our settings programmatically but I imagine most people use a
properties file, so you could have an optional "watch" feature that
checks the timestamp of the properties file and if changed, reloads the
engine.  The watch doesn't need to be a separate monitor thread, just do
the check every time a request is made.

To be honest, I'm happy to be doing this manually given that nobody else
seems to have a need for auto-reloading so don't spend too long thinking
about this.


-----Original Message-----
.org] On Behalf Of Nathan Bubna
Sent: 05 December 2008 20:22
To: Velocity Users List
Cc: Velocity Developers List;
Subject: Re: [ANNOUNCE] VelocityTools 2.0-beta3 release

On Fri, Dec 5, 2008 at 11:54 AM, Steve O'Hara
<> wrote:
> Hi Nathan
> Excellent work as always, very much appreciated.
> However, a method that appears to have been dropped from
> VelocityViewServlet is setVelocityEngine.  I had hoped that this would
> be superseded by setVelocityView but alas not and I'm guessing it's
> because you didn't think anyone was/should be using it?

yeah, early in 2.0 development, i went through a stage of making
things more "opinionated".  i've since reneged on that and merely
haven't bothered to add a setVelocityView to VVS since then.  i'll add
it, no prob.

> In our environment we allow the web administrator to change some of
> fundamental Velocity configuration parameters whilst the app is
> e.g. Template Caching etc.  When they do this, we use our extended
> VelocityViewServlet class to unload the current VelocityEngine and
> reload it with a new one that has been configured with the new values.

thanks, the use-case totally helps me understand why this is handy.

> Without a way of setting the new VelocityView I don't have any way of
> doing this in 2.0.
> Is there another way of telling the shared VelocityView to reload
> perhaps?

no, but that's an interesting idea.  if you think that would be more
useful, let me know and perhaps you can help me figure out how that
might/should work. :)

> Cheers,
> Steve
> -----Original Message-----
> From:
> .org] On Behalf Of Nathan Bubna
> Sent: 03 December 2008 06:02
> To: Velocity Users List; Velocity Developers List;
> Subject: [ANNOUNCE] VelocityTools 2.0-beta3 release
> The Velocity developers are pleased to make the third (and probably
> final) beta release of
> VelocityTools 2.0 available for download.
> Downloads are available here:
> This should be useable as a drop in replacement for Tools 1.4 or Tools
> 2.0-beta2, with a few minor exceptions. The 2.x series of
> VelocityTools also requires both Velocity 1.5+ and JDK 1.5+.
> Since the last beta release, there have been a number of small fixes,
> additional features (like caching for VelocityViewTag), and especially
> improvements in the extensibility of VelocityView.
> The Velocity developers are very interested in all feedback regarding
> Tools 2.0, especially regarding backwards compatibility with apps
> designed for Tools 1.4 or earlier. We aim to enable a smooth,
> incremental transition for developers and their applications.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message