On Oct 21, 2006, at 10:02 PM, David H. DeWolf wrote:
The one negative to this approach is that it will eliminate the ability to support multiple contexts (when tiles is packaged in a common classloader). The TilesUtil currently appears to be implemented in a way which suggests that the original intent was to support multiple contexts. That said, the support is already only partial since Tiles utilizes several static accessors and instances such as TilesUtilImpl will be shared across applications.
I don't personally want to go to great lengths to support running Tiles in a common classloader. If it happens to work then fine. But I would not call it a best practice. Maybe there's situations where it is warranted, but I haven't personally encountered those.
The second approach that would solve this issue would be to refactor the codebase to eliminate the prevalent use of static methods. Instead, all tiles functionality could be configured and encapsulated into a self contained "container" which would be cached and retrieved when needed.
I'm definitely in favor of this approach. I have no problem with static methods but, as Antonio has pointed out, it makes things more difficult to configure. I'm having a similar issue with MyFaces Tomahawk components where I'd like to modify a renderer but the modification is in a non-configurable static utility class. Also, caching objects as static members of utility classes in a multi- threaded environment is problematic at best. So, I'm definitely in favor of this aspect.
In this scenario, the configuration servlet, filter, or listener, would create the container and provide access to it from a publicly available place (perhaps the underlying context). Whenever tiles were needed, the client would retrieve the container and invoke it. Services like the TilesUtil would be provided by the container, not statically accessed.
I like this approach. Since this is the place where other frameworks will have the most interaction with Tiles we should try to make it as straightforward as possible. This kinda goes along with SB-56 [1] that you opened doesn't it?
Greg [1] https://issues.apache.org/struts/browse/SB-56 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
