Gabriel Sidler <[EMAIL PROTECTED]> writes: > Every context tool class that is not thread-safe must be > instantantiated on every template request. We are talking about > hundreds of instances a second.
Hello caching, hello destroy()/shutdown()/clear() method for resource reclamation. Have you looked at Turbine's PullService? <http://cvs.apache.org/viewcvs/jakarta-turbine-3/src/java/org/apache/turbine/services/pull/TurbinePullService.java?rev=1&content-type=text/vnd.viewcvs-markup> Note that the pull service refers to context tools as pull tools, and uses an ApplicationTool interface for them. It's been working very well for me since it was added to Turbine CVS. > I agree that your versions of the tools are a little more user- > friendly. I would use them in a non-auto-loading environment. Maybe > we should keep them in the library with a note that they are more > user-friendly but not thread-safe. Good interface is an extremely important consideration when dealing with context tools. Consider your target auidence often includes UI developers and designers which are not comfortable with complex APIs. If you can't use context tool caching for some reason, why not provide a wrapper around the thread-safe version of the context tool which presents a simplified API for single-threaded use (like the old API)? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
