On Sun, 2006-03-05 at 18:36 +0100, Roland Weber wrote: > Hi Oleg, > > > Low level components such as http-core, http-nio, http-auth and, imo, > > http-async must throw exceptions and never log messages either directly > > to stdout or via a logging toolkit. > > In http-async, I have background threads switching states and (beginning > in March) performing callbacks to application code. The operations of > these threads can not be logged appropriately by http-client. Throwing > exceptions is also pointless in background threads.
I respectfully disagree. There are very simple but effective mechanisms to propagate exceptions from background threads to the controller thread. > Besides, I can't > throw an exception in case of a deadlock or similar misbehavior. > Why not? > Connection management is another example where I would hope for logging > information about the internal state of the managed data. Though that can > probably be addressed by providing specific toString() or similar methods, > to be called from http-client and/or http-async. Or else not, considering > that the thread supposed to log can be blocked when allocating a connection. > I'm not sure about http-auth for stateful or connection based authentication. > I am not saying logging is not useful. I just see very little reason to insert log traces manually. There are bytecode enhancers that can do that for you. > > We must not impose a specific > > logging toolkit on the users of these components. > > commons-logging is a wrapper for an arbitrary logging toolkit. The one > time I had to integrate HttpClient into an application, I was quite happy > with it. No big problem to write an adapter, to JLog 2.x in that case. > This issue has been beaten to death on numerous occasions. To some the glass will always be half-empty rather than half-full. > > Logging per ce does not solve any problem. I regularly spend quite a bit > > of my time analyzing huge log files when trying to help people > > troubleshoot their problems with HttpClient. I usually find 99% of the > > context log entries completely useless. Usually only HTTP headers are of > > any use. Moreover, 90% of problems are caused by cookie or > > authentication headers. A tiny fraction of the time I have spent these > > years on grepping through all those wire logs could have been spent on > > writing a tutorial on how to enhance HttpClient bytecode to log just > > specific type of information. > > Fair concern. I agree that the overwhelming share of the problems we > see can be handled with a wire log and/or information about the headers. > But I have to prepare for a different kind of problems in http-async. > > Bytecode fuddling is something I don't want to get into. I haven't > written assembler code since my diploma thesis, and bytecode manipulation > is close to that level :-) Neither do I. There are enough tools that can take care of all the dirty work for us. > The advantage of log statements in the code is > that you don't have to put them there when problems show up. But given > the interactive nature of the support we're giving, that may indeed be > the better options. > I'm used to a different kind of troubleshooting at work. When I am sent > to a customer, they usually have a huge chunk of complex products > installed, and I need to track down something without knowing where > exactly the problem comes from. Playing with the bytecode is out of the > question, and even adding debug code to the systems is usually a problem. > So I enable logging of some components about which I am suspicious, and > hope that the developers didn't forget to put in the one log statement > that would help me. > What if they did? ;-) > > I think we should eat our own dog food. Besides, there is a lot of > > activity going out around commons [logging] these days. There are > > indications many sound concepts originating from UGLI will get > > incorporated into commons [logging] > > OK, commons-logging it is. That's my preference too. > I am afraid the final decision will still have to settled by a formal vote. My preference is to stay away from the logging wars ... by not using logging at all (whenever feasible) > >>I intend to have another programming stint on http-async next weekend and > >>a few days of the week after. I hope for feedback on the logging questions > >>until then. If we come to a common understanding, and if time permits, > >>I would like to make http-async the pilot for all our components that are > >>going to use logging. But considering the effort it would take, I don't > >>want to rush ahead and implement something that will not be accepted as > >>the basis for other HTTP components. > > Assuming that only http-client and http-async will use logging, > I'll forget about preprocessing and compiling different versions. > By no means I want to impose any design constraints on http-async. Oleg > 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]
