velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Bubna <>
Subject Re: [tools-2.0] How to create HTTP-request-based application-wide tool
Date Wed, 25 Feb 2009 17:24:42 GMT
On Wed, Feb 25, 2009 at 9:10 AM, Antonio Petrelli
<> wrote:
> 2009/2/25 Nathan Bubna <>:
>> Ok, i think i've got it now.  Storing things in a ThreadLocal should
>> allow an application scoped tool to have separate copies for each
>> request, however, i don't see how you are going to automate setting
>> those things into the ThreadLocal at each request. Perhaps you already
>> have a plan for this, though?
> Almost a plan. In case of a request-scoped tool, if "setRequest",
> "setResponse", "setVelocityContext" methods are present, they are
> invoked at each request, am I right?
> In case of an application-scoped tool, are these methods being called?
> If yes, then the implementation will use a ThreadLocal instead of a
> plain object.

No.  Sorry, an application scoped tool will only have such properties
set once; when it is first requested from the context.  After that
initial creation and configuration, it is left entirely to its own

>> My inclination would be to avoid trying to keep this all in one class.
>>  Split your concerns.  The simplest would probably be to put anything
>> application scoped into a ServletContext attribute(s) and have a
>> request-scoped tool pull that out when needed.  For instance, you
>> might have a MyToolAPI object that can live at the application level
>> and a MyTool that is request-scoped.   MyTool would look for the
>> MyToolAPI in the servletContext attributes during configure(Map).  If
>> none is found, then it creates it and sets it in there for later ones
>> to find.   Then MyTool merely forwards a getFoo() request to
>> myToolAPI.getFoo(request).   This setup would keep creation of the
>> request-scoped MyTool very cheap and limit any heavy lifting in
>> MyToolAPI to once-per application.  Does that make sense?
> A delegate, then. Thanks, it is a good suggestion!
> However, if the answer to the question above is "yes" I think that I
> will need to develop less code.

Ah, but if they answer were "yes", then i would have had to develop
more, have slightly slower running tool management, and also have a
lot more concerns about thread safety when writing such tools or
helping users to do so.  :)

> Thank you
> Antonio
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message