Hi, looking at some problems I am wondering if it is "legal" to use the ThreadLocal class. I see some use cases for it: Use Case 1: Marcus Crafter recently asked if it is possible to have the SourceResolver available in components which are not SitemapComponents and/or if it is possible to have it available at earlier stages than the setup() method, e.g. in the configure() method. Use Case 2: Logging. The current information logged contains only the thread id and time information. If the logger (or formatter) has access to the current environment or objectModel it could print out more information ,e.g. the request uri or the ip address etc. As it is not possible to pass the SourceResolver or the objectModel to the components via the methods called, there has to be another way. (E.g. we can't change the signature of the configure() method to include the SourceResolver as it is a standardized Avalon interface - which is very good). So I though of creating a defined ThreadLocal variable which contains either the environment or the objectModel or the SourceResolver or whatever needed. We could either make this variable available via a static variable of some class, e.g. the Cocoon class or we could hide the existence of the ThreadLocal instance and create an avalon component which accesses this ThreadLocal variable, so the avalon component must be looked up and offers some get methods to retrieve the information. What are your thoughts? Comments? Ideas? Carsten Open Source Group sunShine - b:Integrated ================================================================ Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn www.sundn.de mailto: [EMAIL PROTECTED] ================================================================ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
