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 16:52:33 GMT
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?  I can't think of a way to do that
without requiring users to take an extra step such as use a custom
VelocityView class or do something manual like
$mytool.set($context.this) before using other functions.
VelocityTools isn't in the business of setting request values into
threadlocals for application-scoped tools, at least not yet.

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?

On Wed, Feb 25, 2009 at 7:32 AM, Antonio Petrelli
<> wrote:
> I think that I've been pretty cryptic if you understood exactly the
> opposite that I wished to say, so I am sorry and thanks for the
> patience :-D
> First of all I wish to have an application scoped tool.
> This tool needs request, response and Velocity context, all things
> that, presumably, are bound to the request.
> So, at a first glance, it seems impossible to have an application-wide
> tool that uses request-scoped objects.
> But what if I use ThreadLocal to store request, response, Velocity
> context? Will it work?
> Thanks
> Antonio
> 2009/2/25 Nathan Bubna <>:
>> I'm not sure i understand.  So, you want the tool to be
>> request-scoped, but have the instance (or things it creates) live for
>> the length of the application?  If that's it, then i don't think
>> ThreadLocal will help.   Or is it simply that you expect there to be a
>> lot of instances of *the tool* created for every request and wish to
>> share things between those instances.  If that's it, then why not just
>> store them as request attributes?  I'm not sure i see why ThreadLocal
>> is needed, though yeah, that should work too.  I'm also not sure why
>> you expect there to be a lot of instances of your tool created for
>> every request.  Have you seen this happening?  The tool management
>> code for Tools 2.0 stores the request-scoped tools in the request to
>> allow them to be shared.  The intention is that request scoped tools
>> would only need to be created once per-request, even when request
>> includes and forwards are involved.  I'll admit i haven't tested that
>> carefully though, so i'd like to know if i've misunderstood how
>> RequestDispatcher handles request attributes for forwards and
>> includes.
>> On Wed, Feb 25, 2009 at 3:28 AM, Antonio Petrelli
>> <> wrote:
>>> Hi all
>>> I need to create a tool that is based on HTTP requests for Tiles 2. I
>>> succesfully did it through extending "ImportSupport" class, so I can
>>> access the request protected field.
>>> However, I don't feel comfortable with this solution, because this
>>> tool needs to be request-scoped and I need to create, at every
>>> request, a lot of objects that are potentially reusable.
>>> Is there a way to make this tool application-wide? Or is there a way
>>> (a repository?) to access a registered application-wide object,
>>> instead of creating it over and over?
>>> Thanks a lot in advance
>>> Antonio
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message