You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by David P <ch...@yahoo.com> on 2006/04/07 23:17:47 UTC
How to make #for thread-safe?
Some archive msgs like this one point out that
VelocityContext is not thread-safe:
http://servlets.com/archive/servlet/ReadMsg?msgId=148259&listName=velocity-user
I have put some objects in my context that could be
modified by other threads. I can make these accesses
thread-safe when using #set and #if, but I can't think
of a way to protect containers when used by #for. For
example, another thread might remove an element from a
container in the context while #for is iterating over
it. Synchronizing the iterator method of the container
wouldn't provide any protection. And putting a big
synchronize block inside every servlet in the app,
blocking on a shared object, wouldn't work because
there's no way to get the Velocity template to wait on
the same lock...right?
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: UTF8-Enconding in Macros
Posted by Will Glass-Husain <wg...@forio.com>.
Hi,
A quick look at the source suggests this isn't currently possible.
Anyone else have any ideas on this?
If you'd care to file a JIRA issue on this we'll probably add this
capability. It seems an obvious miss.
http://issues.apache.org/JIRA
Best, WILL
On 4/8/06, Dominik Bruhn <do...@dbruhn.de> wrote:
> Hy,
> I encode all my templates in UTF-8, and I load them via
> getTemplate("frame.vm","UTF-8");
>
> I also use some macros, all of them are written in the "VM_global_library.vm"
> which Velocity loads at startup. The Problem is: This library isn't loaded
> with UTF8 encoding. How can I change this?
>
> Thanks
> TO
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Forio Business Simulations
Will Glass-Husain
wglass@forio.com
www.forio.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
UTF8-Enconding in Macros
Posted by Dominik Bruhn <do...@dbruhn.de>.
Hy,
I encode all my templates in UTF-8, and I load them via
getTemplate("frame.vm","UTF-8");
I also use some macros, all of them are written in the "VM_global_library.vm"
which Velocity loads at startup. The Problem is: This library isn't loaded
with UTF8 encoding. How can I change this?
Thanks
TO
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: VelocityServlet depreaced
Posted by Nathan Bubna <nb...@gmail.com>.
Yep, it's true. It's actually been true for several years now. The
VelocityViewServlet has been superior and more actively maintained for
a number of years. We are also slowly shifting the Velocity project
to focus on the core engine, so we're planning to pull out some of the
extras, beginning with the servlet. The VelocityTools project is much
more web-oriented and a better home for that stuff.
On 4/8/06, Dominik Bruhn <do...@dbruhn.de> wrote:
> Hy,
> I read here:
> >>just in case you didn't know, the VelocityServlet has been deprecated
> >>in favor of the VelocityViewServlet in the VelocityTools subproject.
>
> Is this really true? Why this?
>
> Thanks
> Dominik
>
> ---------------------------------------------------------------------
> 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
VelocityServlet depreaced
Posted by Dominik Bruhn <do...@dbruhn.de>.
Hy,
I read here:
>>just in case you didn't know, the VelocityServlet has been deprecated
>>in favor of the VelocityViewServlet in the VelocityTools subproject.
Is this really true? Why this?
Thanks
Dominik
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: How to make #for thread-safe?
Posted by Nathan Bubna <nb...@gmail.com>.
On 4/9/06, Claude Brisson <cl...@renegat.net> wrote:
> Le vendredi 07 avril 2006 à 21:27 -0700, Nathan Bubna a écrit :
> > > It would also preclude putting any singletons into the context.
> >
> > it precludes putting any *mutable* singletons in the context, and
> > that's a good thing! i don't think mutable singletons are ever a good
> > idea, especially in a threaded application like a webapp. they have
> > big thread-safety issues. this will be true whether you use ASP, JSP,
> > Velocity, or any other view technology.
> >
> > immutable singletons, on the other hand, are always thread safe in any
> > application. some people still don't like them, but they won't have
> > thread-safety issues.
>
> Isn't "mutable singleton" just a nice name for an ugly hack where you
> want a singleton to not anymore be a singleton ?
depends on who you ask. some say even "singleton" is just a nice name
for an ugly hack. :) http://en.wikipedia.org/wiki/Singleton_pattern
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: How to make #for thread-safe?
Posted by Claude Brisson <cl...@renegat.net>.
Le vendredi 07 avril 2006 à 21:27 -0700, Nathan Bubna a écrit :
> > It would also preclude putting any singletons into the context.
>
> it precludes putting any *mutable* singletons in the context, and
> that's a good thing! i don't think mutable singletons are ever a good
> idea, especially in a threaded application like a webapp. they have
> big thread-safety issues. this will be true whether you use ASP, JSP,
> Velocity, or any other view technology.
>
> immutable singletons, on the other hand, are always thread safe in any
> application. some people still don't like them, but they won't have
> thread-safety issues.
Isn't "mutable singleton" just a nice name for an ugly hack where you
want a singleton to not anymore be a singleton ?
--
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: How to make #for thread-safe?
Posted by Nathan Bubna <nb...@gmail.com>.
On 4/7/06, David P <ch...@yahoo.com> wrote:
>
>
> --- Nathan Bubna <nb...@gmail.com> wrote:
>
> > In a web application, thread-safety is only a
> > concern if your context
> > objects are used in the session or application
> > scopes.
>
> I'm using VelocityServlet,
just in case you didn't know, the VelocityServlet has been deprecated
in favor of the VelocityViewServlet in the VelocityTools subproject.
> which provides a context
> object when its handleRequest() method is invoked. I
> use Context::put() to add containers to the data model
> used by the template. Some containers are static in
> order to maintain state.
>
> I don't see a way to indicate scope via put().
in your case, scope isn't something you indicate; it is something you do.
anything static is implicitly application scope because it is shared
by all instances and therefore all threads.
anything created for a servlet request is request scope.
to have something be session scoped, you must put it in the HttpSession.
> > Each servlet request is just one thread in a normal
> > web application. So for each request, you
> > should probably be creating a new VelocityContext
> > and new/different instances of any mutable classes
> > into that context. This is the standard practice
> > for any view technology
> > (JSP/Velocity/Freemarker/etc).
>
> I suppose I could make a copy of every static
> container before putting that copy into the context,
> but it seems pretty wasteful.
if the container is static, i'm not sure i understand what the point
of copying it is.
> It would also preclude putting any singletons into the context.
it precludes putting any *mutable* singletons in the context, and
that's a good thing! i don't think mutable singletons are ever a good
idea, especially in a threaded application like a webapp. they have
big thread-safety issues. this will be true whether you use ASP, JSP,
Velocity, or any other view technology.
immutable singletons, on the other hand, are always thread safe in any
application. some people still don't like them, but they won't have
thread-safety issues.
> > On 4/7/06, David P <ch...@yahoo.com> wrote:
> > > Some archive msgs like this one point out that
> > > VelocityContext is not thread-safe:
> > >
> > >
> >
> http://servlets.com/archive/servlet/ReadMsg?msgId=148259&listName=velocity-user
> > >
> > > I have put some objects in my context that could
> > be
> > > modified by other threads. I can make these
> > accesses
> > > thread-safe when using #set and #if, but I can't
> > think
> > > of a way to protect containers when used by #for.
> > For
> > > example, another thread might remove an element
> > from a
> > > container in the context while #for is iterating
> > over
> > > it. Synchronizing the iterator method of the
> > container
> > > wouldn't provide any protection. And putting a big
> > > synchronize block inside every servlet in the app,
> > > blocking on a shared object, wouldn't work because
> > > there's no way to get the Velocity template to
> > wait on
> > > the same lock...right?
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam
> > protection around
> > > http://mail.yahoo.com
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > 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
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> 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
Re: How to make #for thread-safe?
Posted by David P <ch...@yahoo.com>.
--- Nathan Bubna <nb...@gmail.com> wrote:
> In a web application, thread-safety is only a
> concern if your context
> objects are used in the session or application
> scopes.
I'm using VelocityServlet, which provides a context
object when its handleRequest() method is invoked. I
use Context::put() to add containers to the data model
used by the template. Some containers are static in
order to maintain state.
I don't see a way to indicate scope via put().
> Each servlet request is just one thread in a normal
> web application. So for each request, you
> should probably be creating a new VelocityContext
> and new/different instances of any mutable classes
> into that context. This is the standard practice
> for any view technology
> (JSP/Velocity/Freemarker/etc).
I suppose I could make a copy of every static
container before putting that copy into the context,
but it seems pretty wasteful. It would also preclude
putting any singletons into the context.
> On 4/7/06, David P <ch...@yahoo.com> wrote:
> > Some archive msgs like this one point out that
> > VelocityContext is not thread-safe:
> >
> >
>
http://servlets.com/archive/servlet/ReadMsg?msgId=148259&listName=velocity-user
> >
> > I have put some objects in my context that could
> be
> > modified by other threads. I can make these
> accesses
> > thread-safe when using #set and #if, but I can't
> think
> > of a way to protect containers when used by #for.
> For
> > example, another thread might remove an element
> from a
> > container in the context while #for is iterating
> over
> > it. Synchronizing the iterator method of the
> container
> > wouldn't provide any protection. And putting a big
> > synchronize block inside every servlet in the app,
> > blocking on a shared object, wouldn't work because
> > there's no way to get the Velocity template to
> wait on
> > the same lock...right?
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> >
> >
>
---------------------------------------------------------------------
> > 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
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: How to make #for thread-safe?
Posted by Nathan Bubna <nb...@gmail.com>.
In a web application, thread-safety is only a concern if your context
objects are used in the session or application scopes.
If you are concerned about thread safety with the context, then i
would suspect that either you are trying to use a context or context
object in an inappropriate scope or else are needlessly worrying.
Each servlet request is just one thread in a normal web application.
So for each request, you should probably be creating a new
VelocityContext and new/different instances of any mutable classes
into that context. This is the standard practice for any view
technology (JSP/Velocity/Freemarker/etc).
On 4/7/06, David P <ch...@yahoo.com> wrote:
> Some archive msgs like this one point out that
> VelocityContext is not thread-safe:
>
> http://servlets.com/archive/servlet/ReadMsg?msgId=148259&listName=velocity-user
>
> I have put some objects in my context that could be
> modified by other threads. I can make these accesses
> thread-safe when using #set and #if, but I can't think
> of a way to protect containers when used by #for. For
> example, another thread might remove an element from a
> container in the context while #for is iterating over
> it. Synchronizing the iterator method of the container
> wouldn't provide any protection. And putting a big
> synchronize block inside every servlet in the app,
> blocking on a shared object, wouldn't work because
> there's no way to get the Velocity template to wait on
> the same lock...right?
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> 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