Hi Oleg, > Why do not you simply use Log4J or similar logging toolkit to output the > name of the thread that generated the logging event?
The environment has several hundred threads. You don't want to enable output from several hundred threads and figure out later which of these is the relevant one. The performance of the server would collapse immediately. Furthermore, the requests for a single user will be served by different threads over time. What you need for this scenario is a way to enable logging selectively, based on some attribute in the user session. This cannot be handled by simply configuring a logging toolkit. > In my opinion this kind of functionality falls into the responsibility > of the underlying logging toolkit, not HttpClient It's the responsibility of the application and the logging framework, yes. But if HttpClient can offer a simple way to achieve the result without ThreadLocal hacks, then why not? Getting a logger name from the parameters instead of using a hardcoded one in certain situations is not an unreasonable change. "Certain situations" are cases where a long-living object with a logger is created, such as an instance of the Wire class. The situation will be simplified when we get rid of static logger instances (HTTPCLIENT-668). Then, a custom log factory can supply a thread-specific logger instance. Still, getting the logger name from parameters is even simpler. Or would be, if connection pooling didn't interfere with per-thread settings. That's something to be considered for timeouts and buffer sizes, too. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
