Hi Oleg, thanks for your feedback. Valuable indeed.
> There is no need for workarounds. In my experience a combination of the > tread name and the class name are perfectly adequate for debugging the > most heavy duty multithreaded applications. One can simply grep for a > thread name and get a linear event flow for the given thread. 1. We'll have different threads working on the same request/response. We would need at least some kind of request identifier to grep for. 2. I want to reduce the size of the log output. Consider one of those server applications that perform requests of some kind on behalf of different clients. I want to be able to enable logging only for specific requests/sessions/dispatchers. > SimpleLog of Commons Logging does not support thread names but full > fledged logging toolkits like Log4J usually do. I suspect you are > tailoring your solution toward SimpleLog way too much. I've never used SimpleLog at all, so I doubt I'm tailoring for it :-) But I am indeed trying to avoid generating unwanted log output at all. My background is RAS (WebSphere) and JLog 2.x, since these are what I use at work. For example, I am maintaining a code base where the same servlet code is instantiated with different configuration settings multiple times (say 20+) in a JVM. When the customer reports a problem with one of those instances, I don't want combined log output from all of them. And the customer doesn't want all instances to slow down because logging is required for one of them. Unlike other ideas I occasionally have, I believe this is a very real requirement we need to address. > I am afraid you are going a little overboard with this. Unless I am > missing something that implies a context lookup operation per class, > which sort of goes counter to the idea of logging having zero (or next > to zero) impact on application performance when logging is off (or set > to ERROR priority). I remain skeptical for now but do feel free to take > a stab at it and see how it turns out in code. It implies context lookups per request, that is true. I'll think it over again with performance in mind. Thanks for pointing it out. Storing the request specific log object in the handle should avoid most of the overhead for request specific logging. Dispatchers can also do a single lookup when they're created, or when they are told that the context settings might have changed. thanks, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
