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:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
.org] On Behalf Of Nathan Bubna
Sent: 05 December 2008 20:22
To: Velocity Users List
Cc: Velocity Developers List; [EMAIL PROTECTED]
Subject: Re: [ANNOUNCE] VelocityTools 2.0-beta3 release
On Fri, Dec 5, 2008 at 11:54 AM, Steve O'Hara
<[EMAIL PROTECTED]> 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:
> [EMAIL PROTECTED]
>
[mailto:[EMAIL PROTECTED]
> .org] On Behalf Of Nathan Bubna
> Sent: 03 December 2008 06:02
> To: Velocity Users List; Velocity Developers List;
> [EMAIL PROTECTED]
> 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: [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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
