Velocity properties are not visible per se from templates, but could
easily be by means of a tool that would expose them to the context. Some
pointers:
- a generic java tool will automagically have the following methods
called at init, if they do exist:
public void setVelocityEngine(VelocityEngine engine)
public void setVelocityContext(Context context) // would typically
require request scope
- you can then call engine.getProperty(...) and context.put(...) as needed
You could also have a generic properties file parser tool that would
parse again velocity.properties for its own needs - anyhow, a generic
context populating tool is not a bad idea.
Claude
On 2011-03-22 18:32, Doug Carter wrote:
In my original quest to know if I'm in a development environment,
it occurred to me that we use different velocity properties between
production and development. For example, in development mode we set:
velocimacro.permissions.allow.inline.to.replace.global = true
If I could read this value from a template, then I would know if I'm
in development mode or not. Then based on this, I could enable/disable
other characteristics of the app, like if I'm in development mode,
don't authenticate.
Doug
On Tue, Mar 22, 2011 at 06:03:30PM +0100, Claude Brisson wrote:
Do you mean: to populate a Velocity context with a Java properties file
from within a context?
If so, I guess that you could write a small tool to achieve this.
Otherwise, please clarify a bit what you want to do.
Claude
On 2011-03-22 17:18, Doug Carter wrote:
Claude,
I forgot about a related question. Is there any way to read velocity
properties from a template? I've tried getting the session and calling
$session.getAttribute("xxx"), but I'm not having much success. I've
Googled this quite a bit and haven't found any good examples.
Thanks,
Doug
On Mon, Mar 21, 2011 at 04:21:12PM -0700, Doug Carter wrote:
I was hoping I could piggy-back on an existing velocity/tomcat mechanism
instead writing some code to read a property file. Looks like I won't
be reinventing the wheel. That's what I wanted to know.
Thanks for info,
Doug
On Mon, Mar 21, 2011 at 09:00:10PM +0100, Claude Brisson wrote:
Hi Doug,
this question is far from being specific to Velocity. I'm not aware of
any standard on the subject. You could simply read an unversioned flat
properties file at the time the webapp is launched, or use versioned
branches for development and production.
Claude
On 2011-03-15 19:35, Doug Carter wrote:
Hi All,
I know of a few ways of solving this problem, but I thought I'd check
with you all, in the likely case I'm reinventing the wheel.
Recently we implemented Single-Sign-On for a velocity app in our
production environment, which I would like to disable in a development
environment. I was thinking about setting a property to control
application authentication. Something like a property file that doesn't
get checked into SCM, that contains settings based on the running
application environment.
Is there a "preferred" way of doing this with Velocity? If not, do any
of
you use or are you aware of an easy way to control run-time properties,
where you can easily disable functionality like authentication during
development?
TIA,
Doug
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
