On Fri, 2006-06-16 at 19:26 +0200, Roland Weber wrote: > Hi folks, > > I have spent some time over the last weeks thinking about how > to implement logging in HttpAsync. The approach to do all > logging through loggers based on class names has significant > limitations when you have multiple users of HttpClient in the > JVM and want to configure logging independently. We've discussed > that a few years back and came up with a workaround based on > thread-local settings. (I'm glad I haven't had to implement > that yet :-) With HttpAsync using background threads, that > workaround is no longer an option.
Roland, 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. 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. > After that, I've thought about passing a request and/or > dispatcher specific loggers through HttpContext, and using the > class based logger names only as a fallback. Some reading of > the commons-logging documentation, including this wiki page: > http://wiki.apache.org/jakarta-commons/Logging/StaticLog > and more thinking convinced me that class based logger names > are just pointless for our purposes. > In my experience, they are mostly used on package levels anyway, > to enable or disable logging from some parts of a large > application or framework. Although it is also possible to > reduce the logging noise by enabling logging only for some > classes, that feature was never actually used for HttpClient > on the mailing list. So I doubt we'll miss it in the future. > > In summary, here is my suggestion for implementing logging > in the HttpAsync component: > > - HttpAsync uses o.a.c.l.Log objects, but *never* creates > them. It does not use o.a.c.l.LogFactory. > - o.a.c.l.Log objects are passed through HttpContext from > the application to HttpAsync. > - There will be a small choice of logging types, for which > different (or identical) loggers can be passed. This allows > for logging to different targets (files) for each type. > - Type A: request specific information. Like preprocessing, > starting to send the request, waiting for the response, > receiving the response header, and so on. > - Type B: cross-request information from dispatchers. Like > the number of requests/handles in queues, connection use, > thread state changes, and so on. > - No other types for now. > - The lookup names for logger types in the HttpContext can > be parameterized. This allows applications to either set > loggers in the HttpContext with the default names, or to > put the loggers in the default context with application > specific names and activate them per request through params. > > With this approach, we're not going to have any classloader > or other logging configuration issues within HttpAsync, or > other components that adopt the same approach. On the down > side, it requires a little more effort from application > developers to activate logging than just setting a property > or two. > 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. Oleg > > This approach should be equally suitable for HttpClient 4.0. > The suitability ends where the HttpContext is no longer > available: at the connection. Which makes me wonder whether > we should pass the HttpContext down to the connection and > transmitter as well. If we did that, we could replace the > header parsing currently done for the transfer encoding > with a lookup in the HttpContext. But that's just an idea > in it's early stages and still needs to be thought through. > > Please let me know what you think. > > cheers, > Roland > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
