On Wed, Feb 25, 2009 at 9:10 AM, Antonio Petrelli <antonio.petre...@gmail.com> wrote: > 2009/2/25 Nathan Bubna <nbu...@gmail.com>: >> 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 devices. >> 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: user-unsubscr...@velocity.apache.org > For additional commands, e-mail: user-h...@velocity.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org For additional commands, e-mail: user-h...@velocity.apache.org
