velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve O'Hara" <soh...@pivotal-solutions.co.uk>
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 {
 
objNew.setExtendedProperties(Z_getApplicationProperties(getServletContex
t(), objNew));
            objNew.init();
            setVelocityEngine(objNew);
            mobjLogger.info("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.

Steve


 
-----Original Message-----
From:
user-return-20330-sohara=pivotal-solutions.co.uk@velocity.apache.org
[mailto:user-return-20330-sohara=pivotal-solutions.co.uk@velocity.apache
.org] On Behalf Of Nathan Bubna
Sent: 05 December 2008 20:22
To: Velocity Users List
Cc: Velocity Developers List; private@velocity.apache.org
Subject: Re: [ANNOUNCE] VelocityTools 2.0-beta3 release

On Fri, Dec 5, 2008 at 11:54 AM, Steve O'Hara
<sohara@pivotal-solutions.co.uk> 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
the
> fundamental Velocity configuration parameters whilst the app is
running
> 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
itself
> 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:
> user-return-20291-sohara=pivotal-solutions.co.uk@velocity.apache.org
>
[mailto:user-return-20291-sohara=pivotal-solutions.co.uk@velocity.apache
> .org] On Behalf Of Nathan Bubna
> Sent: 03 December 2008 06:02
> To: Velocity Users List; Velocity Developers List;
> private@velocity.apache.org
> 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:
>  http://velocity.apache.org/download.cgi
>
> 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: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org


Mime
View raw message