You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Nathan Bubna <nb...@apache.org> on 2008/12/03 07:01:30 UTC
[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
Aut-reloading Velocity when properties change
Posted by Steve O'Hara <so...@pivotal-solutions.co.uk>.
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
<so...@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
Aut-reloading Velocity when properties change
Posted by Steve O'Hara <so...@pivotal-solutions.co.uk>.
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
<so...@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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [ANNOUNCE] VelocityTools 2.0-beta3 release
Posted by Nathan Bubna <nb...@gmail.com>.
On Fri, Dec 5, 2008 at 11:54 AM, Steve O'Hara
<so...@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
Re: [ANNOUNCE] VelocityTools 2.0-beta3 release
Posted by Nathan Bubna <nb...@gmail.com>.
On Fri, Dec 5, 2008 at 11:54 AM, Steve O'Hara
<so...@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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
RE: [ANNOUNCE] VelocityTools 2.0-beta3 release
Posted by Steve O'Hara <so...@pivotal-solutions.co.uk>.
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?
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.
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?
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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [ANNOUNCE] VelocityTools 2.0-beta3 release
Posted by Nathan Bubna <nb...@gmail.com>.
On Fri, Dec 12, 2008 at 9:55 AM, Claude Brisson <cl...@renegat.net> wrote:
> Apparently, there's only one binary jar published in
> http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/velocity/velocity-tools/2.0-beta3/
> (i.e. no way to find velocity-tools-view-2.0-beta3.jar and
> velocity-tools-generic-2.0-beta3.jar).
I'm open to solutions... i'm just not maven-savvy enough to feel
confident of the best way to do this.
> It's maybe not a so big deal since velocity-tools contains anything. We
> could consider that the ones wishing to use dedicated jars can build
> them themselves. After all, deploying only one jar is much more easier.
Or download them themselves. They shouldn't have to build them.
> And the beta3 is not in the maven-1 repository.
Should we still be putting stuff in the maven-1 repo? I'm not aware
of having done anything to put beta2 or even Engine 1.6 into the
maven-1 repo. Perhaps some Maven maven has been doing this?
>
> Claude
>
> On mar, 2008-12-02 at 22:01 -0800, Nathan Bubna wrote:
>> 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: dev-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: dev-help@velocity.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [ANNOUNCE] VelocityTools 2.0-beta3 release
Posted by Claude Brisson <cl...@renegat.net>.
Apparently, there's only one binary jar published in
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/velocity/velocity-tools/2.0-beta3/
(i.e. no way to find velocity-tools-view-2.0-beta3.jar and
velocity-tools-generic-2.0-beta3.jar).
It's maybe not a so big deal since velocity-tools contains anything. We
could consider that the ones wishing to use dedicated jars can build
them themselves. After all, deploying only one jar is much more easier.
And the beta3 is not in the maven-1 repository.
Claude
On mar, 2008-12-02 at 22:01 -0800, Nathan Bubna wrote:
> 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: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
RE: [ANNOUNCE] VelocityTools 2.0-beta3 release
Posted by Steve O'Hara <so...@pivotal-solutions.co.uk>.
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?
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.
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?
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