velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Bubna" <nbu...@gmail.com>
Subject Re: using Velocity in an untrusted environment
Date Fri, 07 Apr 2006 18:08:10 GMT
On 4/7/06, Ben <benjamin@pcguy.org> wrote:
> I just don't want to have to create a new thread every time a request comes
> in, since that would double the number of threads on the server from 1 per
> page access to 2. If i were to create a new thread it would be easy to
> interrupt it, by doing thread.join(number of milliseconds); and then
> thread.interrupt();
>
> Thanks about pointing out foreach.maxloops property, is there a list
> somewhere of all properties i can set for velocity? I browsed through the
> docs, but didn't find them.

unfortunately, the config properties are not all documented well. 
it's something on my long wish-i-had-time-to-do-this list, but with a
new house, pregnant wife, and pressure from my main paying job, i
haven't had time. :)

however, the latest version of the RuntimeConstants class will give a
pretty good of the properties available, as it has deprecated the
meaningless ones and include most of the newer ones.

> ----- Original Message -----
> From: "Nathan Bubna" <nbubna@gmail.com>
> To: "Velocity Users List" <velocity-user@jakarta.apache.org>
> Sent: Friday, April 07, 2006 12:18 PM
> Subject: Re: using Velocity in an untrusted environment
>
>
>
>
> i don't see why there should be any problem with using a separate
> thread.  servlet requests are all about threads.
>
> if it is just #foreach looping that you are concerned about, then
> there is already a directive.foreach.maxloops property that you can
> set.
>
> > If people are interested I can paste the results of my experiment when I
> > am
> > done, as well as any modifications I make.
> >
> >
> >
> > Hmm.  To be honest, I'm not interested in having this be an
> > out-of-the-box piece of Velocity.  Adding this "maximum cost" option
> > for "every operation it does" would mean a performance hit, a big rise
> > in complexity, or both.  I would want to see a lot of interest in this
> > from others before i would let this change go through without vetoing
> > it.  I really don't think this is something most of our users want or
> > need.  No one else has asked for it (to my memory) in the five years
> > i've been around.
> >
> > For you, however, it ought to be fairly easy straightforward to create
> > a VelocityRunnable that you can start in a new Thread to do the
> > template merge/render and then have the request thread check up on it
> > (sleeping in between checks, of course) periodically.
> >
> > The tricky part is stopping the rendering thread when it goes over
> > time.  It's not really safe to use the deprecated Thread.stop()
> > method.  The recommended replacement
> > (http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html)
> > is to create velocityRunnable.stop() method that can flip a flag to
> > interrupt the rendering.  But Velocity doesn't have any built in way
> > to *interrupt* the rendering.  The only thing i'm aware of is the
> > #stop directives ability to make Velocity stop sending output to the
> > writer.  So far as i know, it doesn't actually stop the template
> > processing (personally, i think it'd be better if it did).
> >
> > To actually stop template processing, you will probably have to alter
> > some of the internals yourself.  The driver of the rendering process
> > is a simple for() loop in the render(context, writer) method of the
> > SimpleNode class.  all the nodes extend this class, so this method is
> > how the AST is traversed.  I would imagine that the "real way" to do
> > this would be to somehow put the flag in that for() loop's conditional
> > that would be shared by all nodes in that template.  That probably
> > means you need a flag that resides in the context that's being passed
> > around.  When the flag is tripped, no further nodes should be
> > rendered.
> >
> > Of course, i'm not 100% sure that that is all you'll need to change,
> > and it also might not catch all possible problems.  For instance, if
> > it is the rendering of a particular leaf on the AST that is taking
> > forever, then this won't stop that node's rendering; it would only
> > stop further traversal of the tree.  Still, that is hopefully enough
> > info to get you started...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>

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


Mime
View raw message