2009/2/25 Nathan Bubna <[email protected]>: > 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. > 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. Thank you Antonio --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
